Skip to main content
scanning: the noise before the storm
  1. mindsecset/

scanning: the noise before the storm

·863 words·5 mins·
Author
Virtue of Vague
Table of Contents
CEH Notes · post 2 of 8 series index →

enumeration, banners, and why your SOC is already blinking before the attack


After recon, you’ve got a list of open ports. 22, 80, 445, 3306, maybe 21. The exam screen sits there and your brain wants to start hacking immediately. But you can’t. Not yet. You have to know what you’re breaking into. Otherwise you’re just throwing exploits at the wall.

This is scanning—the phase between “what’s there” and “how do I get in.” For a SOC analyst, it’s also the phase where the noise starts.


From the attacker terminal
#

My sequence after nmap is usually: banner grabbing, then service-specific enumeration. CEH Practical loves services like SMB, FTP, HTTP, and occasionally RDP or MySQL. So I go straight for what the exam likely cares about.

Banner grabbing with netcat is quick: nc -nv <target> 22 nc -nv <target> 21 nc -nv <target> 80 HEAD request after connecting on port 80 to see server headers.

If I see SMB (445), I run: enum4linux -a <target> smbclient -L //<target> nmap --script smb-enum-shares,smb-os-discovery -p 445 <target>

If there’s FTP (21) with anonymous login, I check: ftp <target> Name: anonymous, Password: anything nmap --script ftp-anon -p 21 <target>

HTTP (80/443)? I run a quick nikto -h <target> and maybe gobuster dir -u http://<target> -w /usr/share/wordlists/dirb/common.txt. Not full-blown web app testing—just surface enumeration to find admin panels, backup files, exposed .git folders.

The trap I fell into during practice was trying to be too thorough. I’d run every nmap script against every port, wait 20 minutes, and burn time. The exam rewards efficient targeting, not exhaustive enumeration. You don’t need to fingerprint a print service on port 515 if it’s not in the lab scope. Recognise what’s likely and focus there.


From the SOC side
#

Now the defender’s view. This is where the attack stops being invisible.

When you run enum4linux, you’re using SMB RPC calls to query user lists, share names, password policies. On a Windows domain controller, that generates logs like:

  • Event ID 5140: A network share was accessed (if you connect to IPC$)
  • Event ID 5145: A network share object was checked for client access
  • Multiple SAMR or LSARPC queries, which some EDRs flag directly as “SMB Enumeration Detected”

In Splunk or Sentinel, a SOC analyst hunting for lateral movement might see a burst of these from a single workstation and think: that’s not normal sysadmin behaviour. That’s recon.

Banner grabbing with netcat doesn’t always trigger a signature unless the firewall is doing deep packet inspection. But a connection to port 21 immediately followed by USER anonymous and PASS anonymous? That’s a clear “FTP Anonymous Login Attempt” alert. If you succeed and list files, file access logs follow.

Nmap service scripts (-sV, or individual NSE scripts) are even noisier. They send specific probes (like an HTTP OPTIONS request, or a malformed SMB negotiation) that IDS signatures detect. Suricata rules like ET SCAN NMAP Service Probe or ET POLICY SMB2 NT LM 0.12 Dialect Negotiation Attempt will light up. If your SOC is tuned, you’ll see a cascade: a scanner detection alert, then specific service enumeration alerts, then maybe an authentication attempt. A good analyst can map the kill chain in real time.

The uncomfortable truth: scanning is where the attacker starts leaving footprints. They’re not exploits, but they’re enough for a mature SOC to start investigating. I know because I’ve triaged those exact alerts.

SCANNING — TWO SIDES OF THE WIREATTACKERbanner grab (nc)enum4linux, smbclientgobuster, niktoSOC SIGNALevent ID 5140 / 5145SMB enum alerts fireHTTP 404 floods, IDS hitsscanning is where the attacker starts leaving footprints.

How this played out in the exam
#

I had port 445 open on one target. Ran enum4linux, got a list of users and shares. Found a readable share with a text file. Flag. Simple, but only because I enumerated first instead of trying random exploits.

On another target, port 80 was open. Gobuster found /backup/. Inside: a .sql file with hardcoded credentials. Flag.

No panic moments. Just that quiet voice saying: don’t skip the step. Know the service before you touch it. It’s the same voice I use when I see an alert in the SIEM and decide not to jump to conclusions.


The two-sides takeaway
#

Scanning is where you build the bridge between what’s visible and what’s vulnerable. As an attacker, it’s your target selection. As a defender, it’s your early-warning system. If your SOC isn’t alerting on SMB enumeration or FTP anonymous logins, you’re giving attackers a free pass through phase two of their kill chain.

Next post: we start breaking things. Credential attacks—hydra, hashcat, and the login storms that scream louder than scans.


Tools used

  • nc -nv → banner grab (low noise, but odd protocol use may flag in NTA)
  • enum4linux → SMB enumeration (loud: Windows Event ID 5140/5145, SAMR queries)
  • smbclient -L → share listing (similar log profile to enum4linux)
  • gobuster dir → web directory brute-force (HTTP 404/200 floods; can trigger rate limits)
  • nikto → web server scanner (generates many malicious-looking requests, clear IDS signature)
  • ftp → anonymous login check (clear alert if successful)

Related