Introduction Link to heading

Advanced Persistent Threat (APT) groups continuously evolve their tactics to infiltrate high-value targets. One of the most significant cyber-espionage campaigns in recent years, Operation Cloud Hopper, demonstrated the dangers of supply chain attacks by targeting Managed Service Providers (MSPs). Conducted by APT10 (also known as MenuPass, Red Apollo, Stone Panda), this operation granted attackers deep access to the networks of multiple global organizations.

This write-up presents an APT emulation lab designed to replicate key attack techniques used in Operation Cloud Hopper. By recreating initial access, credential theft, lateral movement, and data exfiltration.

The group’s tactics, techniques, and procedures (TTPs) are well documented in the PwC UK Operation Cloud Hopper report.

Lab overview Link to heading

Here is an overview of the lab’s scoping notes:

SyntheticPartners (SP) is an AI romance chat bot company specialising in the production of Synthetic Partners™. They rely on an MSSP 
company called VirusVipers (VV) for all their security managed services where access is handled through a VPN. Around October 2023, 
SyntheticPartners was alerted by VirusVipers that the MSSP had suffered an internal breach by APT10 leading to access of several 
of their clients networks.

SyntheticPartners performed some initial triage and threat hunting and reported they suspect someone was using their 
CFO's ("Andy Sanders") account to access one of their workstations from the internal VPN range that VirusVipers use. 
They noted a strange RDP connection to one of their workstations (SP-PC-01) late on 2023-10-14. When asked, 
the user confirmed that they were unaware of the activity.

Some additional information collected on the scoping note:

Access from VirusVipers into the SyntheticPartners network is done through a VPN
All event logs are sent to an Elastic stack managed in the VirusVipers' network
Default defender was used and run on the hosts
This investigation is under legal privilege and the client has allowed us partial access to some of VirusVipers
hosts for analysis

As a part of the incident response coverage, XINTRA has been given access to hosts and data across 6 hosts 
associated with the intrusion along with access to their SIEM (ELK).

Additionally, we have the network diagram of the infected part of the network that we can see across both organizations :

Chain of events Link to heading

The attack consisted of four main phases:

Phase 1 - Initial Access and Foothold : The threat actor gained initial access through a successful phishing campaign, the victim was tricked to executing a malicious script, which established a foothold for the attacker within the network.

Phase 2 - Credential Theft and Reconnaissance : Once inside, the threat actor performed reconnaissance, identifying the network topology and critical assets. The threat actor also targeted credential stores by registering critical registry hives and dumping lsass.exe, enabling them to harvest authentication data for further exploitation.

Phase 3 - Lateral movement and network hopping : The threat actor leveraged harvested credentials to pivot within the VirusVipers’ network, escalating their access then they used an RDP connection to access a machine with a VPN connection to the SyntheticPartners’ internal network targeting the domain controller, further expanding their foothold and enabling deeper compromise of the environment.

Phase 4 - Timestomping and Data Exfiltration : To evade detection, the attacker timestomped multiple files, altering their creation and modification timestamps to hide forensic traces. Following this, the threat actor moved data from SyntheticPartners’ network to VirusVipers’ network for further exfiltration.

Phase 1 - Initial Access and Foothold Link to heading

Triaging the scoping notes Link to heading

The scoping note above mention a strange RDP connection from the user account of the CFO Any Sanders late on 2023-10-14 which he is not aware of

Looking trough the logs, this RDP connection happens at 22:49:20 and the source IP of this connection is 10.0.3.2

Patient Zero Link to heading

To start this investigation, we are gonna find out first how the attacker managed to break into the VV network.

Searching through Sysmon 1 : Process creation with cmd.exe as parent process to retrieve the history of command lines used reveals something interesting

These commands will save a targeted registry hive to a text file.

But the three hives that are targeted here (SAM, SECURITY and SYSTEM) are well-known for allowing attackers to dump hashes from them and possibly crack them, feel free to check out this article to get more details.

Delivering the payload Link to heading

In the previous section, we saw some suspicious commands, and it seems likely that the account of the user w.stanley was compromised. The most common way to get into a network is trough social engineering and phishing, for this reason i will check the Exchange OWA HTTP proxy logs.

During the previous search about command line execution, we notice execution of suspicious binary

The execution of this binary occurred on October 13th at 02:02:20.423, so there was likely some time between the receipt of the email and the execution of the binary. For this reason, we will check a bit earlier, and in the two files containing HTTP proxy logs between 00:00 and 01:59, we may find useful information.

The url stem field indicate the following address /owa/service.svc/s/GetPersonaPhoto which means it retrieves the profile of the email user we are communicating with. In the Query field, we can find the email address of the threat actor conducting phishing attempts: bricktop@securitydocs.awsapps.com. We also have the user’s agent and IP address

Another artifact that we can use for Exchange is the mail database, .edb file.

To open it, we will use a tool called Stellar Repair for Exchange Looking on the InBox emails of Walter Stanley (w.Stanley), we find the following emails

These email can confirm the successful phishing attempt ,as earlier we saw execution of suspicious binary (SecureDocs.ps1) and his parent process was the batch script SecureLauncher.bat which is directly referenced in the second mail.

The threat actor has send 2 different zip files because by looking at the Windows Defenders logs, we notice that the first one was blocked under the following threat name : : Trojan:Script/Wacatac.B!ml

We can also notice that this blocked file came from the following url : https://docs.technicalsupport.info/ImportantDocuments.zip

A WHOIS lookup reveal that the domain name technicalsupport.info was registered on 2023-10-06, few days before the incident.

Phase 2 - Credential Theft and Reconnaissance Link to heading

Infection Time Link to heading

Let’s now take a look on the payload send by the threat actor, as a reminder, the following scenario occurred:

• The treat actor sent a zip file containing a script named SecureLauncher.bat which was executed the 13th october at 02:02:20.423.
• The child process of this batch script is the SecureDocs.ps1 -key ImportantDocuments

That means the batch script is just a wrapper and the actual payload inside the code of SecureDocs.ps1 is obfuscated, meaning we cant launch it without having the right key but luckily this key is provided in cleartext in the command line shown just above ImportantDocuments.

Near the execution of the powershell script, we can notice a DNS request to viper.vpn-update.zip.

Filtering by processID confirm that this DNS Query came from the powershell script.

Let’s dig deeper and examine the source code which can be found under the folder C:\Users\Public\ on the host VV-PC-01 as expected from the mails. As seen earlier, the powershell script was placed here by the victim following the instruction written in the second mail and the threat actor did not came back there to delete it.

Here is the source code of the powershell script:

This script is fairly simple, it will decode the base64 encoded text ($e) with the key provided in parameters and will load the decoded content (.NET assembly) in memory.

To analyze it, let’s copy this script somewhere else then do few modifications:

Function xd {
param(
[string] $k,
[string] $c)

$b = [System.Convert]::FromBase64String($c)

$p = $(for ($i =0; $i -lt $b.Count) {
        for ($j = 0; $j -lt $k.Length; $j++) {
            $b[$i] -bxor $k[$j]
            $i++
            if ($i -ge $b.Length) {
                $j = $k.Length
            }
        }
    })

        return [System.Convert]::ToBase64String($p)
    }

$e= "BDfgb3F0YW5wRG9jipJlbsxzSW1wb3J0IW50RG9jdW1lbnRzSW..truncated.." #long base64
$key= "ImportantDocuments"
$d = xd $key $e
$a = [System.Convert]::FromBase64String($d)
[System.IO.File]::WriteAllBytes("$PWD\ImportantDocuments.dll",$a)

Instead of loading the assembly into the memory, this script will now save it into .dll file so we can perform a static analysis on it.

We will analyze it using DNSpy, a .NET debugger and assembly editor

We can retrieve the original name of the file:

source code of the main function given by DNSpy :

public static void Main()
{
	string ciphertext = "RAALGjwBIzVtOWl2RQU2PwB0FBB9EGoATTEIeT4MOydDcwY[...string is too long...]"
	string s = Program.XOR_Decrypt(ciphertext);
	byte[] array = Convert.FromBase64String(s);
	IntPtr intPtr = Program.VirtualAlloc(0U, (uint)array.Length, 12288U, 4U);
	Marshal.Copy(array, 0, intPtr, array.Length);
	IntPtr hHandle = IntPtr.Zero;
	uint num = 0U;
	IntPtr zero = IntPtr.Zero;
	uint num2;
	Program.VirtualProtect(intPtr, (uint)array.Length, 32U, out num2);
	hHandle = Program.CreateThread(0U, 0U, intPtr, zero, 0U, ref num);
	Program.WaitForSingleObject(hHandle, uint.MaxValue);
}

This program is also quite simple, it perform shellcode injection and execution, the shellcode is stored inside ciphertext variable but its obfuscated however if we look at the code in the function XOR_Decrypt ,we are able to find the key to retrieve the shellcode.

unfortunately for the sake of this exercise, despite the string containing the shellcode is long in the c# code (a way longer that what i put in the main function code snippet), its truncated at the end and i will ot be able to reconstruct and executable from it to dig deeper.

But what we can see is inside the logs, by searching with Sysmon 8 : CreateRemoteThread, is the initial payload spawned a rundll32.exe process and injected itself onto

Attacking VirusVipers Link to heading

Looking at patient zero authentications on 13th october, we can see that the threat actor successfully authenticated on several hosts, including Domain Controller of VV network and RDP connection to the host VV-PC-02 at 18:15:42.207.

From the VV-PC-02 host, the treat actor was able to get network information by reading a png file related to network map.

Given the drive letter ‘R:’ in the path, it is likely that this file came from a network share.

Another process creation event can also be found referring to the same drive letter, some of them are on other host : VV-PC-01, the patient zero host.

Looking at RecentDocs registry hive for the patient zero user reveal that this network drive is related to the Domain controller (VV-DC-01)

Back on the threat actor activities, as seen before it saved critical registry hives related to authentication (SAM, SYSTEM AND SECURITY).

It also used a tool called procdump.exe , a sysinternals tool, to dump the memory of the lsass.exe process. The Local Security Authority Subsystem Service (LSASS) is responsible for handling authentication and storing credentials in memory.

In the download history of the web browser edge, we can see that the threat actor also downloaded a tool called ADExplorer.exe that allows users to browse, search, and edit Active Directory (AD) objects.

Phase 3 - Lateral movement and network hopping Link to heading

Attacking SyntheticPartners Link to heading

After dumping several assets related to credentials, the threat actor est an AV exclusion

Once it was on the SP’ network (more details later), the threat actor disabled winlogbeat service to impair windows defender’s visibility

Next, we get informed that the treat actor gained access to the SP’ network with the compromise of the user account SP-Admin (sid : S-1-5-21-2525899764-3259092811-2554837162-500).

First thing we look at is the activities of this user which was checking reachability with the VV’s network and then read confidential file. This authentication logs also indicate that SP-DC-01 is the first host in the SP’ network the threat actor accessed.

In order to see from when did the threat access has access to the SyntheticPartners’ network, we will take a look at authentication logs

Looking at the process creation logs led us to see a suspicious binary executed by the user C.Mckay

To get mre information about this binary, we can ge trough your evidences, in the exact same location that we have below within the file system of VV-PC-02, however this binary no longer exist at the time as the KAPE image was taken but instead we can find two Visual Basic script : CopyCat.vbs and CopyCatsV2.vbs, looking at the source code of the second script (V2)reveal the password of SP-admin in clear text.

Supply Chain Attack Link to heading

Let’s get more information about how did the threat actor established a connection to the SP’ network.

Still looking at the activities of the user C.Mckay on the host VV-PC-02, we can notice that the VPN agent used is OpenVPN

The child processes indicate that the IP assigned to this host by the VPN adapter is 10.0.3.2

According to the OpenVPN logs, the first VPN connection happens on October 14th at 14:01:55

The authentication with logon id 10 indicate that the threat actor used RDP to initiate a connection to SP-DC-01.

Exploring the New Network Link to heading

Later, the threat actor initiated a connection to the SP-PC-01 host and launched a binary on this host that came from the Domain Controller (IP 192.168.0.254 is linked to SP-DC-01, see network diagram provided at the lab overview part of this article)

Unfortunately searching for the hashes in a public database like virustotal dyields no additional information, as this binary was specifically crafted for this lab.

Next, we were informed that the threat actor ran another binary called ‘WinPost.exe.’ Unfortunately, we couldn’t find any references to the execution of this binary within the ELK SIEM. As a result, we turned to the raw logs and used the Chainsaw tool to gather more details about this binary.

The log file that we will check here is the Sysmon event 1 (Process creation) because it provide more information than using windows event code 4688.

The product name EDRChecker can help us to guess what this binary does but sadly searching with the hash i didn’t get evidence that this tool is related to a public tool.

Also on ths sysmon logs, we can also see the execution of yet, another binary SH.exe.

Further investigation indicate that this binary is Sharphound, a well-know C# Data Collector for BloodHound.

During the investigation of breached user sp-admin, we can also see that he had access to several other confidential files, revealing the name of the CEO and the facility location.

Phase 4 - Timestomping and Data Exfiltration Link to heading

Timestomping Link to heading

Sooner, we saw that the threat actor has executed a binary from the following path \192.168.0.254\c$\Users\Public\Temp\ImportantDocuments.exe and the IP is related to SP-DC-01 host.

Upon examining this location for residual traces, we unexpectedly discover another script.

This script is also a know public tool available on his github repository

Stompy.ps1 is a tool designed to modify the timestamp of a specified file, a technique known as timestomping which is often used by adversaries to evade detection by altering file metadata. For more details, see MITRE page for T1070.006 - Indicator Removal: Timestomp

We had access to several Powershell transcript files and inside of it, we can notice that the user modified the timestamp of several files including recycle bin as shown just below to January 1th, 2AM.

Searching trough MFT (Master File Table), obtained with EricZimmerman tool MFTECmd reveal that a total of 163 distinct files has their timestamp modified.

You may notice that i excluded files from the “Collection” folder. This is because these files are related to data acquisition rather than being actual files associated with the attack.

Exfiltration Link to heading

̣̣̣̣̣̣̣̣̣̣ In the step Attacking SyntheticPartners, we identified two Visual Basic scripts, in the latter part of one script (previously unseen), we observe the threat actor copying the file $R4FR549.zip probably generated by SharpHound, from the Recycle Bin of SP-DC-01 to VV-PC-02."

Fortunately, we can retrieve these files from our triage image evidence and confirm that a total of 11 files were exfiltrated.

In the Infection Time step, we saw that the initial payload (SecureDocs.ps1 ) spawned a rundll32.exe process and injected itself onto

Examining the SRUM database allows us to estimate exfiltration activity on October 14th by the rundll32.exe process. While this may not be the most accurate method, we are working with the resources available to us.

There is a total of 9626549 bytes sent on October 14th by rundll32.exe

Conclusion Link to heading

This was the second APT emulation lab that i took, and it was definitely a step up in difficulty from the first one. The challenge pushed me to go beyond standard SIEM investigations and dig deeper into key windows forensic artifacts like the MFT, Amcache, and raw logs. It also expanded my understanding of supply chain attacks and introduced me to event codes and search techniques i hadn’t encountered before—definitely a solid way to level up my investigative approach.

What really stood out was the balance between realism and complexity. Each stage of the lab required precise findings to progress, making it both structured and engaging. It wasn’t just about following a predefined path, it encouraged careful analysis and a methodical approach to uncover every detail. These kinds of labs are an incredible way to sharpen DFIR skills, and i highly recommend them to anyone looking for hands-on experience. Huge thanks to the creators for delivering such a well-designed and educational challenge!

References Link to heading

https://www.pwc.co.uk/cyber-security/pdf/pwc-uk-operation-cloud-hopper-report-april-2017.pdf https://www.orangecyberdefense.com/global/blog/cybersecurity/bypassing-edr-to-dump-lsa-secrets https://learn.microsoft.com/en-us/answers/questions/1590243/exchange-server-2019-security-related-logs https://dazzyddos.github.io/posts/Abusing_Exclusions_To_Evade_Detection/ https://serverfault.com/questions/855238/find-out-who-disabled-a-windows-service https://attack.mitre.org/techniques/T1070/006/ https://github.com/Psmths/windows-forensic-artifacts/blob/main/execution/srum-db.md