With the store audited in 04-02, we turn toward TechNova's internal infrastructure: the 10.10.10.0/24 network, with its Linux server, the network controller, the workstations, and the services that Module 3 left on the prioritized list. Here the surface isn't a web application but network services and the transport medium itself: a service with an exploitable CVE, a null SMB session on the internal server, traffic that may travel unencrypted, and weak configurations (SNMP public, misconfigured DNS).

The framing becomes even more delicate than on the web, because several network techniques can affect third parties or availability: a badly done ARP spoofing cuts off an office's network; an exploit module against a fragile service brings it down. So, more than ever: only TechNova's authorized lab, within scope and the agreed window, with impact control (no unagreed denial of service) and every action documented. And one clear limit: here we achieve execution or access to a service; escalating privileges and moving through the network (pivoting) is Module 5, we don't touch it.

1. The network as an attack surface
2. Exploiting a service with a CVE (responsible Metasploit)
3. MITM: ARP spoofing and sniffing
4. Attacks on SMB and NTLM relay
5. Misconfigured network settings (SNMP, DNS)
6. Detection: what the IDS sees
7. Network hardening (the counterpart)
8. Common mistakes and tips
9. Exercises
10. Conclusion

A network service is a program listening on a port (03-01/03-02). It can be attacked along two complementary paths:

• Attack the service: leverage a flaw in the listening software (a CVE, a misconfiguration, weak credentials) to gain access or execution.
• Attack the medium: intercept or manipulate the traffic traveling across the network (MITM), leveraging protocols without authentication (ARP) or without encryption (HTTP, FTP, Telnet).

When a service runs a version with a confirmed exploitable CVE (a candidate validated in 03-03), Metasploit offers ready-made modules. Responsible use in the lab: verify first, pick the most reliable module (remember the Rank from 04-01) and the lowest-impact payload.

Analysis: check validates the vulnerability without launching the exploit, use it whenever it exists. And instead of directly opening an interactive shell, we run a simple id: the output uid=1000(devapp) proves command execution and confirms we've obtained a foothold with limited privileges. That's all the report needs; consolidating that shell and escalating is Module 5. The full walkthrough of Metasploit is in 07-02.

Counterpart (remediation): apply the patch or retire the end-of-life software, disable Werkzeug's debug mode in any reachable environment, and don't expose development services to the network. Segment so that dev isn't reachable from where it shouldn't be.

Mechanism. On a LAN, the ARP protocol has no authentication: any host can claim "I am the gateway." With ARP spoofing, the pentester tricks a victim and the gateway so that traffic passes through their machine (man-in-the-middle), where it can be read (sniffing) if it's unencrypted.

Framing: LAB ONLY. This technique intercepts third parties' communications; outside an authorized environment it's illegal. And you must forward the traffic (ip_forward) so as not to cause an unagreed network outage.

Low-impact PoC. Demonstrate that you capture a credential traveling unencrypted from a test service (for example an HTTP or FTP login in the lab), capturing one fictitious username/password pair as evidence. No real users are intercepted and no mass traffic is accumulated.

Counterpart: encryption everywhere (HTTPS, SSH, signed SMB) renders sniffing useless; on the network, Dynamic ARP Inspection and DHCP snooping on the switches, port security, and VLAN segmentation. If everything is encrypted, the attacker sees unreadable bytes.

Module 3 confirmed a null SMB session on the internal server (10.10.10.55) with an accessible RRHH share: a configuration finding, solid because it doesn't depend on a version.

Low-impact PoC (validate the null session):

Listing the share and confirming that RRHH is accessible without credentials proves the flaw. We do not download all the documents: the evidence of access is enough.

NTLM relay (mechanism, high level). On Windows networks, if SMB doesn't require signing, an attacker who captures an NTLM authentication can relay it to another service and authenticate as the victim without knowing their password. It's a powerful technique; at this level it's enough to recognize the pattern: authentication captured → relayed → access. Tools like responder and impacket-ntlmrelayx implement it.

Counterpart: requiring SMB signing neutralizes the relay; disable SMBv1, close null and anonymous sessions, and apply least privilege on the shares. Remove credentials and sensitive data from open shares.

Many accesses don't come from a CVE, but from a misconfigured service (confirmed and highly reliable findings):

Reading only the SNMP system branch or checking whether the AXFR responds demonstrates the leak without abusing it: we don't dump the whole MIB or walk the entire tree. Each with its fix in the table.

Network attacks are especially noisy and detectable, and the pentester should know it (and the client's SOC should train on it):

• ARP spoofing: generates anomalous ARP replies and duplicate MACs; an IDS (Snort/Suricata) and tools like arpwatch detect it instantly.
• Service exploitation: signatures of known exploits fire alerts; spikes of failed connections and suspicious payloads land in the logs.
• SMB/SNMP enumeration: bursts of anonymous queries or full snmpwalk runs are recognizable patterns.

TechNova's SOC seeing your activity is not a failure: it's a validation of its detection capability, and it's part of the report's value.

Consolidating the defenses from the whole lesson:

• Encryption by default: HTTPS, SSH, signed SMB, SNMPv3, SFTP. Kills sniffing.
• Secure switching: Dynamic ARP Inspection, DHCP snooping, port security, VLANs. Kills ARP spoofing and limits reach.
• Segmentation: keep dev, production, and office IT separate; so that a compromise in one doesn't hand over the whole network.
• Harden services: patch, retire EOL, close null/anonymous sessions, change default credentials and communities, restrict AXFR.
• Monitoring: IDS/IPS and log review to detect exactly what this module generates.

• Launching ARP spoofing without forwarding traffic. If you forget ip_forward, you cut the victim's communication: an unagreed denial of service. Set it up first.
• Using DoS modules or low-reliability exploits against fragile services. They can bring down the client's service. Prioritize a high Rank and use check before run.
• Exfiltrating a whole share or the entire SNMP MIB. It breaks impact control. List and extract one sample that proves access.
• Intercepting traffic outside the lab. MITM against real third-party communications is illegal. Authorized environments only.
• Confusing exploitation with post-exploitation. Getting the devapp shell is the end of this lesson; escalating to root or pivoting to another subnet is Module 5.
• Ignoring the counterpart. A network finding without its hardening (encryption, SMB signing, DAI, SNMPv3) is half a report. The goal is for TechNova to close the door.
• Tip: on the network, encryption and segmentation resolve most of these classes in one stroke. When you propose remediation, start there.

Exercise 1. On the internal server 10.10.10.55 with a null SMB session and an RRHH share, describe the low-impact PoC sequence to validate access without exfiltrating the documents, and give three hardening measures with which TechNova would close the flaw.

Exercise 2. You're going to demonstrate an ARP spoofing in the lab to prove that certain traffic travels unencrypted. Explain what you prepare in order not to cause a network outage, what minimal evidence you would capture, and what technical counterpart would render the attack useless.

Exercise 3. Module 3 flagged SNMP with the public community on 10.10.10.30. Explain how you would validate the information leak in a controlled way, why it's a reliable finding despite having no CVE, and how it's remediated.

Solution 1. PoC: (1) smbclient -N -L //10.10.10.55/ to list shares without credentials and see RRHH; (2) enum4linux -a 10.10.10.55 to confirm users/policy via the null session; (3) smbclient -N //10.10.10.55/RRHH -c 'ls' to list the content and demonstrate access, without downloading the documents. Evidence: the output showing the share accessible without authentication. Hardening: (a) close the null/anonymous session in the SMB configuration; (b) require SMB signing (which also mitigates NTLM relay) and disable SMBv1; (c) apply least privilege on the share and remove the sensitive HR data from an open share, with per-group permissions.

Solution 2. Preparation so as not to cut the network: enable IP forwarding (echo 1 > /proc/sys/net/ipv4/ip_forward) before poisoning, so that the intercepted traffic still reaches its destination; limit the attack to one test host and to the agreed window. Minimal evidence: one fictitious username/password pair captured from a cleartext service (a lab HTTP/FTP login), as proof that the traffic travels unencrypted. Counterpart: end-to-end encryption (HTTPS/SSH/signed SMB) makes intercepted traffic unreadable, and on the network Dynamic ARP Inspection + DHCP snooping prevent ARP poisoning.

Solution 3. Controlled validation: snmpwalk -v2c -c public 10.10.10.30 1.3.6.1.2.1.1 querying only the system branch to demonstrate that the default community responds and leaks information (system name, version), without walking the whole MIB. It's a reliable finding because it's a confirmed configuration, not a suspicion based on a version number: it doesn't depend on a CVE or a possible backport, the leak either exists or it doesn't, and here it does. Remediation: change the community to a strong one or, better, migrate to SNMPv3 (with authentication and encryption) and restrict by IP which hosts can query.

We've carried exploitation from the browser to the network. On TechNova's infrastructure we've validated a service with a CVE (obtaining low-privilege command execution with a simple id), confirmed the null SMB session on RRHH, understood the mechanism of MITM/ARP spoofing and NTLM relay, and verified leaks via misconfigured SNMP and DNS. Each technique, with its PoC that demonstrates without destroying, its detection (how noisy it is for an IDS), and its hardening counterpart: encryption, secure switching, SMB signing, SNMPv3, and segmentation.

Notice the limit we've respected: we've achieved access or execution on services, but we've stopped right there, consolidating, escalating, and moving through the network is Module 5. The next lesson, 04-04 System Vulnerability Exploitation, closes the technical trio: how to obtain execution on a host by leveraging operating-system flaws and local services, with the buffer overflow explained at a conceptual level, up to achieving a foothold with limited privileges. Escalating from that foothold remains Module 5.