Network Attacks

Before launching the attack, I examined the victim workstation's ARP table using the arp -a command. The output shows normal IP-to-MAC address mappings, providing a baseline that will later be compared against the poisoned ARP cache.

I configured Ettercap to use the primary network interface and started packet capture. This prepares the application to discover hosts and initiate the ARP poisoning attack.

The Ettercap log output confirms that the capture engine has started successfully and the application is ready to enumerate hosts on the local network.

Ettercap scanned the local subnet and identified reachable hosts. The victim workstation was then selected as the attack target.

From the MITM menu, I selected ARP Poisoning, which instructs Ettercap to begin sending forged ARP responses to the selected hosts.

I enabled Sniff remote connections and started the attack. Ettercap immediately began sending forged ARP replies to manipulate the victim's ARP cache and position the attacker between communicating devices.

Using Wireshark, I captured the resulting ARP traffic generated by the attack. The repeated ARP replies advertise the attacker's MAC address for multiple IP addresses, illustrating how ARP poisoning modifies the victim's address resolution process.

Returning to the victim workstation, I ran arp -a again to inspect the updated ARP table. Multiple IP addresses now resolve to the attacker's MAC address, confirming that the ARP cache has been successfully poisoned and that traffic can now be intercepted by the attacker.

On corp-svr, Docker is used to start the dns-svr and web-svr containers, and then the BIND service inside the DNS container is checked to confirm that named is running correctly before any zone changes are made. This step ensures the attacker DNS and web infrastructure are online and ready for later poisoning.

From the Kali attacker machine, an nmap -Pn 10.0.5.3 scan is run to enumerate open TCP ports, revealing that HTTP (80/tcp) and a non‑standard SSH port (2222/tcp) are accessible on the target host.

Using the nmap results, attacker connects with ssh -p 2222 root@10.0.5.3, accepts the host key, and successfully logs into Ubuntu 22.04.5 system as root.

On corp-svr, netstat -tuln is used to list active listening sockets, confirming that the server is listening for DNS on 10.0.5.3:53 as well as on 127.0.0.1:53, and that SSH is exposed on multiple ports including 22 and 2222.

The command grep " install " /var/log/dpkg.log shows package installation history, including entries for bind9 and dnsutils, proving that BIND and its DNS tools were installed recently on this Ubuntu system. This evidence ties the running DNS service back to a specific BIND deployment.

Inside the DNS container, the attacker changes into /etc/bind, lists the configuration and keys, and then moves into the zones/ directory where the forward zone file for projectzerocorp.com is stored. This step identifies exactly which file controls name resolution for the target domain.

The db.projectzerocorp.com zone file is displayed, showing the SOA record and multiple A/NS entries that map internal hostnames to IP addresses. Understanding this baseline zone content is critical before introducing any malicious changes for the poisoning attack.

In the db.projectzerocorp.com zone file, the A record for www is edited from the original server IP to 10.0.0.50, which is controlled by the attacker. This single change ensures that any DNS lookup for www.projectzerocorp.com will now resolve to the malicious host.

From the victims browser, navigating to the normal corporate URL now displays the attacker’s cloned “Verify Your Password” form, even though the user believes they are on a trusted site. This step shows how DNS poisoning turns a familiar URL into a credential‑harvesting page.

After the victim enters a username and password, the phishing page displays a friendly confirmation message instead of an error, reinforcing the illusion that the action was legitimate. Behind the scenes, those credentials have already been written to a log file on the attacker host.

On the attacker machine, cat creds.log reveals multiple entries with usernames and plaintext passwords collected from victims who interacted with the spoofed site.

On the Kali attacker machine, the git clone https://github.com/tastypepperoni/NetImpostor.git command is used to pull down the NetImpostor source code from GitHub. This provides the raw Go project that will be compiled into the IP spoofing tool used in the lab.

Inside the NetImpostor directory, Go module commands and the go build -o NetImpostor step install required dependencies and compile the project into a local binary. This turns the downloaded source into an executable attacker tool that can craft spoofed IP packets and maintain stateful connections.

Opened /etc/proxychains.confand added socks5 127.0.0.1 1080 line, configuring ProxyChains to send traffic through a local SOCKS5 proxy. This prepares the environment so that later, traffic generated through NetImpostor can be tunneled and inspected via the spoofed connection.

Ran proxychains curl https://google.com/, which forces the HTTP request through the SOCKS5 proxy at 127.0.0.1:1080 configured earlier. The HTML response from Google confirms that outbound web traffic is successfully being routed through NetImpostor’s spoofed tunnel instead of going out directly from Kali our attacker machine.

In the NetImpostor console, a [SPOOF] log entry reports “starting new tunnel 127.0.0.1:xxxxx <=> 64.233.177.138:443”, indicating that the SOCKS request has been turned into a spoofed TCP connection to Google over HTTPS. This proves that NetImpostor is actively handling the proxied traffic and building stateful tunnels for the impersonated IP.

A Wireshark capture on the network records outbound TLS traffic where the source IP is 10.0.0.101, the impersonated host, while the destination is Google’s IP on port 443. Seeing 10.0.0.101 in the source field instead of Kali’s real address is the key evidence that NetImpostor successfully spoofed the IP at the packet level while maintaining a working TLS session.

On project-zero-corp-svr, a Docker container named dos-web-svr is started using a pre‑built web image, and docker stats shows its baseline CPU and memory usage before any attack traffic. This establishes a “normal” operating state for the target web server so the effect of the DoS can be compared against it.

dockerrun-d --name=dos dos-web-svr --network=host --cpus="0.25" --memory="6m" projectzero-image-web

From the attacker machine, the command sudo hping3 -1 -i u10 -S -p 80 -c 250000 10.0.0.8 is executed to send a large volume of crafted packets to port 80 on the web server. This simulates a SYN flood style DoS by hammering the HTTP port with thousands of rapid connection attempts.

Once the run completes, the hping3 summary reports that out of 250,000 packets transmitted only 36,202 were received, corresponding to about 86% packet loss on replies. This high loss rate demonstrates how a sustained flood can degrade or even deny service to legitimate clients trying to reach the web server.

On project-zero-corp-svr, the ftp-svr Docker container is started and accessed with docker exec -it ftp-svr /bin/bash, placing the lab’s vulnerable FTP service on the network. Inside the container, the workspace directory contains the vsftpd-2.3.4 source and binaries used for this exploit.

From the container shell, the lab changes into vsftpd-2.3.4/ and runs the vsftpd binary, which starts the backdoored FTP daemon in the foreground. This step activates the intentionally vulnerable service that listens on port 21 and hides the CVE‑2011‑2523 backdoor.

From the attacker side, nmap 10.0.0.8 -Pn -sV is used to enumerate services, and the output shows port 21/tcp open ftp vsftpd 2.3.4. Detecting this specific version is the key reconnaissance step that signals the host is running a known backdoored FTP server.

Using the standard ftp client, the attacker connects to ftp 10.0.0.8 and logs in with a username that ends in :) plus any password. This crafted username quietly triggers the hidden vsftpd backdoor, which causes the server to open a root shell listener on TCP port 6200.

In a separate terminal, on my attacker machine I ran nc 10.0.0.8 6200 and is dropped into a shell where whoami returns root, proving full system compromise. This confirms successful exploitation of CVE‑2011‑2523 and shows how a single outdated service can hand over root access.