Ravindra BagaleCourses & study guides

37. Enumeration: NetBIOS, SMB, SNMP, LDAP, SMTP, NFS and DNS

37.9 Red vs Blue, Project and Real Incidents

By Last updated:

Chala mitrano, NetBIOS/SMB, SNMP, LDAP, SMTP, NFS, DNS enum – aata Purple Team loop. Red side madhe null session/share list, public SNMP walk, LDAP anon bind, SMTP VRFY, NFS showmount, DNS AXFR dakhavto; Blue – no guest/SMBv1, SNMPv3+ACL, disable anon bind, disable VRFY, restrict exports, restrict AXFR + monitor NS. Tumhi Raja-Rani Traders style OWN Metasploitable/lab madhe build → hack → fix karun Purple report liha. Dusryacha office without permission – kadhi nahi. Samjla ka?

Red Team vs Blue Team – protocol enumeration

Red team (attacker) does Blue team (defender) detects / stops
SMB/NetBIOS null session / share + user enum (enum4linux, smbclient -L, NetExec) Disable guest/null; no SMBv1; require auth; signing; firewall 139/445; patch (EternalBlue class)
SNMP walk with default public/private (snmpwalk, snmp-check) SNMPv3 (auth+priv); ACL on management IPs; no default communities; monitor odd UDP/161
LDAP anonymous bind / base dump (ldapsearch -x) Disable anon bind; LDAPS; directory ACL (full AD hardening → Ch.38)
SMTP VRFY / EXPN / RCPT user probe disable_​vrfy_​command; rate-limit RCPT; no open relay; mail logs
NFS showmount -e + mount sensitive export /etc/exports specific IPs only; root_squash; prefer ro; firewall 111/2049
DNS AXFR / aggressive zone enum (dig … AXFR, dnsenum) allow-transfer only to secondaries (TSIG); split DNS; alert on AXFR + unexpected NS changes

Defender chi simple checklist: no guest/SMBv1 → SNMPv3/ACL → no anon LDAP → no VRFY → tight NFS → no public AXFR + NS monitoring. Red = enum map; Blue = harden + re-enum (fail = pass). Interview madhe laundry list tools peksha "I enumerated Raja-Rani OWN Metasploitable, then disabled guest, fixed SNMP community, blocked AXFR, and proved enum failed" jast strong.

# OWN lab only – Raja-Rani Traders (Kolhapur) – Metasploitable / lab at 192.168.56.20
mkdir -p ~/labs/raja-rani-enum
# 1) BUILD – enum checklist (what you will try, then fix):
cat > ~/labs/raja-rani-enum/checklist.md << 'EOF'
# Raja-Rani Traders – OWN lab enum checklist
Target: 192.168.56.20 (MY Metasploitable / lab only)
[ ] SMB: enum4linux / smbclient -L
[ ] SNMP: snmpwalk -v2c -c public …
[ ] LDAP: ldapsearch anon (if service up)
[ ] SMTP: VRFY test user
[ ] NFS: showmount -e
[ ] DNS: dig @… lab.local AXFR
Fix goals: no guest, SNMPv3/ACL or community gone, no VRFY, tight exports, no AXFR
EOF
# 2) HACK – OWN lab only (examples):
# enum4linux -a 192.168.56.20
# snmpwalk -v2c -c public 192.168.56.20 system
# showmount -e 192.168.56.20
# dig @192.168.56.20 lab.local AXFR
# 3) FIX on lab services you control – then re-run enum (expect refuse/fail)

Ravindra Bagale's Tip

Students enum4linux success baghun production IP try kartat – IT Act. Dusri chuk: AXFR fail zala ki "tool broken" mhantat – fail = defence working. Rule: OWN Metasploitable only → full enum table → harden one row at a time → re-enum. Finding without fix = half learning. Ghabru naka, checklist ne yetay.

Lab

~/labs/raja-rani-enum/checklist.md liha. OWN 192.168.56.20 var enum4linux + showmount -e + dig … AXFR (lab domain) chalaa. Findings table: protocol | finding | fix. Ek fix implement kara (example: document "disable guest / SMBv1" kiwa BIND allow-transfer { none; }; on YOUR DNS lab) ani punha enum – refuse expected.

Project: Build it, hack it, fix it

Build: For fictional Raja-Rani Traders (Kolhapur office learning lab):

  1. OWN Metasploitable 2 / lab VM on host-only (192.168.56.20) – services as shipped for learning
  2. Written enum checklist (SMB, SNMP, LDAP if present, SMTP, NFS, DNS) with columns: command, finding, fix
  3. Ethics card: IT Act – only YOUR lab IPs; no scanning neighbour networks

Hack (OWN lab only):

  • Run enum4linux / smbclient -L – note null/guest/share findings
  • snmpwalk with lab community if SNMP is up – note device/info leak
  • SMTP VRFY (if mail service listens) – note user disclosure
  • showmount -e + careful read-only mount only if you need to prove export risk, then umount
  • dig @192.168.56.20 <lab.zone> AXFR – succeed or refuse?

Do not enum real company IPs, do not write to NFS exports, do not leave default public SNMP on anything facing a shared network.

Fix:

  • SMB: disable guest/null session ideas; note "no SMBv1" / patch posture for EternalBlue-class risk
  • SNMP: remove default communities or move to SNMPv3 + ACL (lab notes OK if full v3 not available)
  • SMTP: disable VRFY/EXPN on lab MTA config
  • NFS: tighten /etc/exports (specific IP, root_squash, ro)
  • DNS: restrict AXFR; note monitoring for unexpected NS changes

Re-verify: Peer-review with Salman / Ravina – re-run enum; shares/AXFR/VRFY should fail or shrink. Purple 1-page for owners Raja and Rani: map → harden → re-enum. IT Act: OWN / authorised only.

Real incident: WannaCry (2017)

In May 2017, the WannaCry ransomware worm spread worldwide, including high-profile hits such as parts of the UK NHS (widely reported). It abused the EternalBlue exploit against SMBv1 (Microsoft bulletin MS17-010, CVE family around CVE-2017-0145) – a patch had already been released in March 2017 for supported Windows versions, but many systems were unpatched; worm-like scanning of port 445 helped it move fast. Weakness: exposed/legacy SMBv1 and missing patches. What would have stopped or slowed it: apply MS17-010 promptly, disable SMBv1 where unused, block inbound SMB (445) from the internet, network segmentation. Lesson for this chapter: SMB enum finds the soft surface; Blue must patch and kill SMBv1, not only list shares. Source: Microsoft Security response on WannaCrypt/WannaCry and CERT advisories on EternalBlue/MS17-010; verify current summaries.

Real incident: Sea Turtle DNS hijacking campaign (~2017–2019)

Sea Turtle was a widely documented DNS hijacking campaign (Cisco Talos and others, with a related DHS alert in January 2019). Actors compromised or abused access at registrars, registries, and DNS providers, then changed victim NS (name server) records so lookups went to attacker-controlled name servers – enabling traffic redirection and credential theft against government and other targets across multiple countries (Talos reported dozens of organisations). Weakness: weak control of DNS/registrar credentials and insufficient monitoring of unexpected NS/delegation changes. What would have helped: registrar MFA and tight ACLs, DNSSEC where practical, continuous monitoring/alerting on NS and glue changes, least privilege on who can edit DNS. Lesson: DNS AXFR and enum are one risk; hijacked resolution is deeper – Blue must watch the DNS control plane, not only zone files. Source: Cisco Talos "Sea Turtle" reports and public DHS/alert coverage of DNS hijacking; verify current summaries.

Interview model (clean English): "I enumerate only my own lab. On Raja-Rani Metasploitable I used enum4linux, snmpwalk, showmount and dig AXFR, then hardened guest access, SNMP, VRFY, exports and zone transfer and re-checked until enum failed."

Thodkyaat: protocol enum olakha, pan guest/SNMPv3/VRFY/exports/AXFR+NS monitor shika. Aata pudhe Active Directory. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

  • Enumeration = open services madhun users, shares, zones, mounts – scan peksha deeper; lab only.
  • SMB/NetBIOS: nmblookup, smbclient, enum4linux, NetExec; defence – no guest/SMBv1, auth, firewall.
  • SNMP: snmpwalk / snmp-check; defence – SNMPv3, ACL, no default communities.
  • LDAP: ldapsearch basics; anonymous bind risk; full AD → Chapter 38.
  • SMTP: VRFY/EXPN/RCPT user enum; disable VRFY/EXPN.
  • NFS: showmount + careful mount; root_squash, IP-restricted exports.
  • DNS: dig AXFR / dnsenum; restrict zone transfer, split DNS.
  • Checklist table lakshat theva – attack shikla tar fix pan implement kara.

Samjla ka? Aata NetBIOS/SMB, SNMP, LDAP, SMTP, NFS ani DNS enumeration tumchya toolkit madhe aahet – pratyek sobat bachav. Pudhchya chapter madhe Active Directory (Impacket, BloodHound) – CEH modules pudhe. Chala pudhe, mitrano!