Simulating a Real-World Attack: The Logs Don't Lie

This is the final part in the Breach and Containment series that I have worked on this weekend.

In the first part, we played the role of an attacker, created a payload, identified a target, gained initial access, established persistence, performed discovery, dumped hashes, and exfiltrated data. Now in this part of the series, we take on the role of an Incident Responder, working through the IR cycle to drive this to resolution with a goal of creating 3 custom detections at the end.

On the Defensive

We receive a ticket from Jimmy that his PC is moving slow. He downloaded a file linked in an email he received John his colleague at Dexter's Lab. It's a plugin for the CAD application we use here at JvHomelabs. However, it never worked so he fears it was a virus.

We are tasked with investigating whether this is a legitimate security incident, determining initial access, and confirming scope and impact.

To begin the investigation, we will start with a hypothesis-driven approach.

Hypothesis: We suspect that the email was spoofed or sent by an unauthorized actor impersonating John Smith and the file Jimmy received was malicious, and was likely used as a delivery vector for initial access.

To test this, we’ll start by verifying the sender’s identity and examining the downloaded file for indicators of compromise.

We will begin by checking the email gateway for the email that supposedly came from John Smith at Dexter's Labs in Defender for Officer 365 (MDO).

A quick glance across email authentication details show that it is suspicious.

A quick pivot on the sender IP shows us that this email was sent using a known email sender spoofing tool and the file Jimmy opened is therefore very likely to be malicious.

For this case, we are going to assume that we navigated to the URL in our sandbox and the WeTransfer download link has already expired. However, best practice in a case like this would be to delegate someone to open that link in a sandbox and try to download and detonate the file so that we can gather as much IoCs as possible to advance our hunt using the MITRE ATT&CK framework as a reference.

Based on the information gathered thus far though, we were able to confirm the first part of our hypothesis as True.

• The email was a spoofed email and not from John Smith at Dexter's lab.

  
  

The last part of the hypothesis required us to confirm that it is being used as a delivery vector for initial access.

To confirm whether the file was truly used for initial access, we can ask:

Does execution of the plugin result in a suspicious process chain on the endpoint?

Pressed for time we pivoted to Sysmon Event ID 11 which logs File Creation Events to first obtain a timestamp and file path for when the file was downloaded. We focus on Jimmy's machine TECHPC2. And finally, we filter the results for any file with "cad-plugin" in its name, narrowing the time window to when Jimmy reported accessing the email.

The user used Edge to download the file which we now know is called CAD-plugin.exe

Now we know when the file was created we want to confirm if the file was being used for initial access by checking for suspicious process execution. Let's take a look at process executions from the CAD-Plugin.exe file using the below query.

There's a lot to unpack here. We see the malicious file executing PowerShell commands in a hidden window. Then that is followed by some enumeration. We also see two CMD.exe processes spawned from the CAD-plugin.exe file.

Drilling down into cmd.exe process id 3812, shows that whoami /groups was ran.

Drilling down into the other cmd.exe process by listing the cmd process id as the ParentProcessId shows us that additional enumeration was also performed using commands such as net user and also a follow up PowerShell child process was spawned too.

All of this enumeration confirms that the file is malicious and was used for initial access. However, that opens the question. Having established access and performed some enumeration, is there some connection out to a C2 to drive the attack forward.

In our logs, we will now pivot to see if there were any network connections from the malicious binary.

Pivoting on Sysmon ID 3 which logs network connections we see that there appears to be a C2 at IP address 192.168.1.11.

With this additional IoC, we can quickly scope our environment for additional malicious payloads and connections to other machines. Were there any other files that are associated with this C2?

To identify this we look for Sysmon ID 3 (Network Connections) but rather than narrowing down on the CAD-plugin.exe, we look for all images connected to the C2.

We noticed two files called AdobeSync and AdobeSyncUpdater.exe in the Startup folder. This is likely an attempt to persist on Jimmy's machine and maintain the shell.

We will add all the files listed to our know list of IoCs.

We can also use the Known Indicators to sweep across our environment for other potentially compromised machines. The query below looks for network connections to the C2.

Fortunately, connections from the malicious IP is only to TECHPC2. The fact that it is an outgoing connection also heavily indicates that this is a reverse shell.

So thus far, we know the attacker has a reverse shell in our environment. The attacker also tried to maintain their foothold by dropping a file in the startup folder called AdobeSync.exe

In the logs, we exhausted the child processes from cad-plugin.exe. So we can begin the look at the child processes for Adobesync.exe and AdobeSyncUpdater.exe which were the other malicious files identified.

Looking at the child processes, one quickly stands out. If you're familiar with metasploit or even a quick google search would show that fodhelper is often used to bypass UAC.

https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-Analytics-Alert-Reference-by-Alert-name/Fodhelper.exe-UAC-bypass

The attacker makes registry changes to ms-settings. We observed that powershell.exe was spawned by fodhelper.exe, a known auto-elevated binary used in UAC bypass. While Windows doesn’t explicitly log whether the spawned PowerShell was elevated, the process chain makes this highly likely.

Jimmy is a local admin, so the adversary here is probably trying to gain system privileges.

So we now have tracked the attacker doing the following:

Enumerating groups that Jimmy has access to.

Maintains his foothold by dropping a malicious payload in Startup folder.

Using Fodhelper for Defense evasion and likely to escalate privileges.

My hypothesis at this point is if the attack has come this far, he likely transition to credential access.

To verify this, I will pivot on Sysmon Id 10 to hunt for Process access of lsass.exe by any of these malicious processes.

In the logs, we see powershell.exe accessing lsass.exe. Here's the kicker, look at the Process Id 5324. Does it look familiar? Check two screenshots above. It is the elevated UAC bypass PowerShell child process that was spawned by fodhelper.exe

So we can also confirm that essentially all users who logged on to that machine should have their passwords changed.

Given that credential dumping from lsass.exe was confirmed, all accounts with recent successful logons to TECHPC2 — including Administrator, Jimmy.Caron, and service accounts — are considered compromised. As part of containment, we recommend immediate password resets for these users. To identify these we use the query below.

I think we have a pretty good coverage of the extent of the compromise on the endpoint. Some other things I would check for at this point though is anomalous logons from the other accounts as well as activities they performed.

However, we are going to take a different turn in our investigation and probably have someone else on our team perform confirm additional activities across the other accounts.

In the meanwhile, we want to answer this next question or confirm this new hypothesis. If an attacker comes this far it is likely he tries to pivot.

Pivoting again on Sysmon Id 3 ( network Connections), let's look for network connections associated with the AdobeSync.exe executable.

Here we observe the expected C2 connections, but also what appears to be a port scan of our DC.

The attacker did port scanning and port 445 was found open which means it is possible he tries to enumerate shares and see if any data of interest could be exfiltrated.

The port scanning was done at approximately 13:23 25 May, 2025.

To confirm if the attacker actually accessed any files we will hunt for event ID 5145 on the DC which tracks share access to shared folders on the system subsequent to the port scan.

At 13:34 we see files autorun[.]inf and desktop[.]ini which based on my research are system files that help Windows customize folder views and do not indicate intentional access by the user or attacker.

Following that the next and actual file access was at 13:38:19 and the access mask indicates that it could have been read and downloaded. At this time the adversary was still on the device so we could consider the file that passport.adml file as stolen.

At this point, we’ve contained what we know, addressed the confirmed activity, and taken action on the accounts and systems we identified during the investigation. But in a real-world incident, there’s always the chance that something slipped through. The IR process doesn’t stop here. After containment comes full eradication, recovery, and most importantly, a proper debrief. That’s where lessons are learned, gaps are closed, and teams get better. In this lab, we focused on what we could confirm, but in practice, we’d dig even deeper to make sure nothing gets left behind.

So to summarize the attacker activity that we were able to cover they are:

1. Delivery

The attack started with a user, Jimmy, receiving a WeTransfer link to a supposed CAD plugin. Although the link had expired by the time of analysis, we were able to confirm the file was malicious and intended for initial access.

MITRE Technique: T1204.002 – User Execution: Malicious File

2. Execution

The payload was executed using cmd.exe, which led to the launch of powershell.exe. This initial execution kicked off the rest of the attack chain and was confirmed using Sysmon Event ID 1.

MITRE Technique: T1059 – Command and Scripting Interpreter

3. Defense Evasion

To bypass User Account Control (UAC), the attacker used the Fodhelper UAC bypass technique. This allowed them to escalate privileges without triggering a UAC prompt. Registry manipulation was observed to redirect Fodhelper to the attacker's payload.

MITRE Technique: T1548.002 – Abuse Elevation Control Mechanism: Bypass User Account Control

4. Persistence

The attacker copied a malicious executable to the user’s Startup folder, ensuring it would execute on reboot. This action was performed via cmd.exe, and the file creation was confirmed with Sysmon Event ID 11.

MITRE Technique: T1547.001 – Boot or Logon Autostart Execution: Startup Folder

5. Credential Access

The attacker dumped credentials from memory using tools executed post-UAC bypass. Credential artifacts were consistent with standard Windows credential dumping behavior and LSASS access.

MITRE Technique: T1003.001 – OS Credential Dumping: LSASS Memory

6. Lateral Movement / Recon

We saw port scanning followed by SMB share browsing which was observed via Event ID 5145, where multiple files were queried. Most of this activity was background noise from Windows behavior (desktop.ini, autorun.inf), but it indicated the attacker was exploring the environment.

MITRE Technique: T1083 – File and Directory Discovery

7. Collection

At 13:38, the attacker accessed passport.adml, a sensitive file, using read-level permissions (AccessMask=0x120089). This suggests the file was likely exfiltrated or staged for exfiltration while the attacker still had access to the host.

MITRE Technique: T1005 – Data from Local System

lolol.. I'm tired now...

So this wraps up the second part of my hands-on lab series, where I explored both the offensive and defensive sides of a targeted file access scenario. In Part 1, I played the role of the attacker — delivering a malicious payload, executing it, dumping hashes, and navigating laterally to pull sensitive files. In this follow-up, I switched to the defender’s seat, diving into Windows logs and Splunk to retrace every step.

The real purpose of this series wasn’t just to showcase a cool attack. It was to help people breaking into the field understand what these actions actually look like in logs. It’s one thing to read about tactics in theory, and another to see the process creation, file access, and share enumeration events for yourself. That’s how things start to click.

I also wanted to show the noise. Not every log entry means something bad happened — sometimes it's just Windows being Windows. Learning to separate signal from noise is a skill every analyst needs, and this lab gave me a chance to practice that in a controlled environment. Additionally, and huge disclaimer here, I literally turned off all defenses to get this to work, so I am by no means a red teamer, I just made Defender turn a blind eye each time.

Next, I’ll be doing a follow-up where I take everything I learned here and build high-fidelity detections around it. We’re talking detection rules for suspicious file drops in Startup folders, reads of sensitive files over SMB, and process chains tied to common execution paths like PowerShell spawned from cmd. I'll probably call it,

Simulating a Real-World Attack: Detect them All!

If this gave you value or helped you understand offense and defense a bit more clearly, I’d love to hear about it. The goal is to learn, share, and grow together.

Stay sharp,

JvCyberguard