In Lesson 4, we started using Nmap to enumerate systems instead of blindly throwing tools at them. You learned an important workflow:

Host → Port → Service → Version → Configuration → Evidence

Now we're going one level deeper.

Finding an open port isn't the end of enumeration.

It's the beginning.

For this lesson, only work against systems you own, your own lab VMs/containers, or systems you have explicit permission to test.

1. What Does an Open Port Actually Tell You?

Suppose your scan gives you:

PORT STATE SERVICE 22/tcp open ssh 80/tcp open http 8080/tcp open http-proxy 

A beginner sees:

We want you to start seeing:

Take port 22.

22/tcp open ssh 

That doesn't mean:

It means:

Now we need more information.

What SSH implementation?

What version?

What authentication methods?

Is it actually SSH?

Is there a banner?

Is the service configured unusually?

The same reasoning applies to every service you encounter.

2. Build Something to Enumerate

Don't scan random internet systems.

We're going to create our own service.

Open a terminal and make a directory:

mkdir hacking-lab cd hacking-lab 

Create a simple file:

echo "DaemonCore Training Server" > index.html 

Now start Python's HTTP server:

python3 -m http.server 8080 

You should see something similar to:

Serving HTTP on 0.0.0.0 port 8080 

Leave that terminal open.

You've just created a network service.

Now open another terminal.

3. Confirm the Port

Run:

nmap -p 8080 127.0.0.1 

You should get something similar to:

PORT STATE SERVICE 8080/tcp open http-proxy 

Notice something interesting.

Nmap might call it:

http-proxy 

But you know that's not really what you created.

You created:

python3 -m http.server 8080 

This teaches an extremely important lesson:

Port numbers are clues, not proof.

Nmap initially makes educated guesses based partly on commonly associated port numbers.

Port 80 usually means HTTP.

Port 22 usually means SSH.

Port 443 usually means HTTPS.

But nobody forces applications to follow those conventions.

You could run SSH on 2222.

You could run HTTP on 9000.

That's why we enumerate further.

4. Ask Nmap to Identify the Service

Now run:

nmap -sV -p 8080 127.0.0.1 

The important option is:

-sV 

It means:

service/version detection

Instead of merely saying:

Nmap communicates with the service and attempts to determine what it actually is.

You may see something similar to:

PORT STATE SERVICE VERSION 8080/tcp open http SimpleHTTPServer 0.6 (Python 3.x) 

That's much more useful.

We've moved from:

8080 

to:

8080 ↓ HTTP ↓ Python HTTP server 

That is enumeration.

5. Don't Immediately Google "Exploit"

This is where beginners often screw up.

They see:

Apache 2.x 

or:

OpenSSH 

and immediately search:

Apache exploit 

Stop.

A service name or version does not automatically mean vulnerability.

Your job is first to understand what you're looking at.

Ask:

What service is this? What software appears to provide it? How confident am I in that identification? What does the service expose? How is it configured? What additional information can I safely obtain? 

Only after you understand the service should vulnerability research enter the picture.

6. Talk to the Service Yourself

Nmap isn't magic.

We can actually interact with our HTTP server ourselves.

Run:

curl http://127.0.0.1:8080 

You should receive:

DaemonCore Training Server 

Think about what just happened.

Nmap told us:

8080 → HTTP 

Then curl independently confirmed:

Yes, an HTTP server is responding. 

That's evidence.

7. Look at the HTTP Headers

Now run:

curl -I http://127.0.0.1:8080 

Instead of requesting the normal page content, you're examining the HTTP response headers.

You might see:

HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/3.x Date: ... Content-type: text/html Content-Length: ... Last-Modified: ... 

Look at this line:

Server: SimpleHTTP/0.6 Python/3.x 

That's information disclosure.

The server itself is telling you something about the software behind it.

We didn't exploit anything.

We simply asked the server a normal question and recorded its answer.

That's enumeration.

8. Banner Grabbing

You'll hear this term constantly:

banner grabbing

Some network services announce information when you connect.

For example, an SSH server might respond with something resembling:

SSH-2.0-OpenSSH_9.x 

That information is called a banner.

A banner can reveal things like:

Protocol Software Version Operating system clues Configuration details 

But remember:

Banners aren't guaranteed to be truthful.

Administrators can modify them.

Proxies can interfere.

Software can intentionally hide versions.

Treat banners as evidence—not absolute truth.

9. Netcat

Another extremely useful networking tool is:

nc 

or Netcat.

Think of Netcat as a very simple way to establish TCP or UDP connections and move data.

Try connecting to your server:

nc 127.0.0.1 8080 

The terminal may appear to just sit there.

That's because you're now connected to the HTTP server, but you haven't spoken HTTP yet.

Type:

GET / HTTP/1.1 Host: localhost 

After the Host: line, press Enter twice.

You should receive something similar to:

HTTP/1.0 200 OK Server: SimpleHTTP/0.6 Python/3.x Content-type: text/html DaemonCore Training Server 

This is important.

You just communicated with a web server without a browser.

No Chrome.

No Firefox.

No graphical interface.

You manually opened a TCP connection and spoke enough HTTP for the server to understand you.

10. What HTTP Actually Looks Like

Your browser hides enormous amounts of networking from you.

When you visit:

http://example.com/ 

something conceptually similar to this gets sent:

GET / HTTP/1.1 Host: example.com User-Agent: ... Accept: ... 

And the server responds:

HTTP/1.1 200 OK Content-Type: text/html Content-Length: ... <html> ... </html> 

The browser turns that response into the webpage you see.

But underneath all the graphics, buttons and animations are protocols.

Understanding those protocols is what eventually separates someone who understands security from someone who merely memorizes security tools.

11. Nmap Default Scripts

Nmap also has something called the:

Nmap Scripting Engine — NSE

Scripts allow Nmap to perform additional checks against discovered services.

A common starting point in an authorized lab is:

nmap -sC -sV -p 8080 127.0.0.1 

Here:

-sC 

runs Nmap's default script set.

And:

-sV 

performs service/version detection.

So we're asking Nmap:

Depending on the service, NSE output can reveal additional metadata.

Don't obsess over every script yet.

For now, understand what NSE represents:

automated service interrogation.

12. Scan Your Whole Lab Machine

If you're working against your own lab VM, you can now combine what you've learned:

nmap -sC -sV <LAB-IP> 

Suppose you receive:

22/tcp open ssh OpenSSH 80/tcp open http Apache httpd 3306/tcp open mysql MySQL 

Don't think:

Think:

22 → SSH → OpenSSH → What information does SSH expose? 80 → HTTP → Apache → What application is being served? 3306 → MySQL → Database service → Why is the database reachable? 

You're creating branches of investigation.

13. Enumeration Is Service-Specific

There isn't one universal enumeration command.

If you discover:

HTTP 

you investigate HTTP.

If you discover:

SSH 

you investigate SSH.

If you discover:

DNS 

you investigate DNS.

If you discover:

SMB 

you investigate SMB.

If you discover:

MySQL 

you investigate MySQL.

This is why networking fundamentals matter so much.

Your scanner tells you where to look.

Your knowledge tells you what the result means.

14. Start Building a Service Map

Create notes that look something like this:

TARGET 192.168.56.10 PORT 22 Protocol: TCP Service: SSH Software: OpenSSH Version: Unknown Evidence: Nmap service detection PORT 80 Protocol: TCP Service: HTTP Software: Apache Version: 2.x Evidence: Nmap + HTTP headers PORT 8080 Protocol: TCP Service: HTTP Software: Python SimpleHTTPServer Evidence: Nmap + curl 

Don't write:

22 SSH 80 website 8080 website 

That's not enough.

Record what you actually know.

15. Separate Facts From Assumptions

This habit will make you dramatically better.

Suppose Nmap reports:

8080/tcp open http-proxy 

Your notes shouldn't say:

Proxy server discovered. 

You don't know that.

Instead:

FACT: TCP/8080 is accepting connections. OBSERVATION: Initial Nmap classification: http-proxy. EVIDENCE: HTTP response received with curl. ADDITIONAL EVIDENCE: Server header indicates Python HTTP server. CONCLUSION: Likely Python-based HTTP service rather than an HTTP proxy. 

That's how an investigator thinks.

16. The Enumeration Loop

From this point forward, burn this into your head:

Discover ↓ Identify ↓ Interact ↓ Observe ↓ Verify ↓ Document ↓ Investigate deeper 

Then repeat.

Don't rush toward exploitation.

The more you understand before attempting anything invasive, the less you're guessing.

Your Mission

Start your Python server:

python3 -m http.server 8080 

Then, from another terminal, perform these four checks:

nmap -p 8080 127.0.0.1 nmap -sV -p 8080 127.0.0.1 curl -I http://127.0.0.1:8080 nc 127.0.0.1 8080 

Inside Netcat manually send:

GET / HTTP/1.1 Host: localhost 

Then answer these questions without Googling:

1. What is the difference between a port and a service?
2. Why isn't the port number alone enough to identify what's running?
3. What does -sV add to an Nmap scan?
4. What information did the HTTP headers reveal?
5. Why should a banner be considered evidence rather than absolute truth?
6. What did Netcat demonstrate that your browser normally hides?
7. Why shouldn't finding a software version immediately lead to searching for an exploit?

If you can explain those in your own words, you've understood Lesson 5.

Im dead tired. That's 5 lessons done for ya'll. 99999 to go!! With me?

THORSKY OUT