y0sh1mitsu's blog

How are Prefetch created?

Wed, 17 Dec 2025 00:00:00 GMT

In the world of DFIR, the Prefetch file (.pf) is a long-time companion. It’s one of the first digital forensics artifacts we analyze on a Windows workstation to confirm program execution, obtain a timestamp, determine run counts and so on... During many trainings, we’re taught a simple rule of thumb:

:::note "An application needs to run for about 10 seconds to generate a valid Prefetch file." :::

I applied this rule without ever questioning it. I knew it worked, but I didn’t truly understand the reasoning behind it. Why 10 seconds? Why not instantly? What is the operating system actually doing during that delay? And where did this technology originally come from?

This article documents this small research project.

The Genesis: Solving the "Seek" Penalty

The Prefetch mechanism is a fundamental innovation within Microsoft Windows operating systems, first officially introduced with Windows XP. Its technical origin is rooted in the patent US 6,633,968 B2, filed by Arthur Zwiegincew and James E. Walsh of Microsoft in 2003.

The initial challenge was simple yet crucial for perceived user performance: how to reduce the latency time during the startup of applications and the operating system? This slowness stemmed from hard page faults, where the system had to interrupt its work and wait for the necessary data blocks (pages) to be transferred, slowly, from the hard drive to RAM. The patented solution involves detecting and analyzing "Scenarios" of disk access (such as launching a program) to create Scenario files (.pf files).

These files contain the ordered list of pages that will be requested. Thanks to this prefetching mechanism, the system proactively loads these pages into RAM before they are requested, thereby converting long disk access delays into fast soft page faults, ensuring significantly better system responsiveness.

This flowchart illustrates the iterative process of managing and prefetching memory pages: when the system detects a Scenario, it checks for the existence of a pre-existing Scenario file to either analyze and create a new file (the bottom path) or open the existing file and load the corresponding pages into RAM (the right path) to prevent hard page faults:

<p style="text-align:center;">Flowchart of the Memory Page Prefetching Method upon Detection of a Page Fault Scenario (U.S. Patent 6,633,968 B2)</p>

The Evolution of the prefetching mecanism in Windows

The Prefetching mechanism has evolved significantly since its introduction in Windows XP. The initial Prefetch feature focused on monitoring and logging hard page faults during system boot and application launch in order to create scenario files and improve startup performance.

This technology was renamed to SuperFetch with Windows Vista. SuperFetch did not replace the original Prefetcher service. Instead, it expanded it by adopting a more strategic and adaptive approach. Building on the existing mechanism, SuperFetch analyzes long-term usage patterns and proactively loads frequently used applications and data into RAM to improve responsiveness.

In newer versions of Windows 10 and in Windows 11, the SuperFetch service was renamed SysMain. The core functionality remains essentially the same, focusing on dynamic prefetching and intelligent memory management. Microsoft has not provided an official explanation for the name change, so it is reasonable to assume that it was done to align the service with the modern Windows system architecture.

How a Prefetch is Born

To understand the lifecycle of a Prefetch file, we must look beyond the disk. Windows Internals states that when an application launches, the kernel memory manager monitors page faults for the first 10 seconds. But how does this telemetry become a .pf file?

1. \KernelObjects\PrefetchTracesReady

Windows Internals explains that the svchost.exe instance responsible for the SysMain service will wait for a notification from the kernel, \KernelObjects\PrefetchTracesReady, to inform it that it can now request the data.

To observe this, I attached WinDbg to the relevant svchost instance. The stack trace reveals a call to ntdll!NtWaitForMultipleObjects (https://ntdoc.m417z.com/ntwaitformultipleobjects), indicating the thread is suspended until specific objects enter a signaled state:

0:001> k
 # Child-SP          RetAddr               Call Site
00 000000e1`bcf7d178 00007ffd`4ebfdf83     ntdll!NtWaitForMultipleObjects+0x14
01 000000e1`bcf7d180 00007ffd`398cd9ce     KERNELBASE!WaitForMultipleObjectsEx+0x123
02 000000e1`bcf7d470 00007ffd`398ed592     sysmain!PfSvcMainThreadWorker+0xf6a
03 000000e1`bcf7faa0 00007ffd`3990006f     sysmain!PfSvcMainThread+0x22
04 000000e1`bcf7fae0 00007ff7`36da259d     sysmain!SysMtServiceMain+0x10f
05 000000e1`bcf7fb20 00007ffd`4fb17627     svchost!ServiceStarter+0x3cd
06 000000e1`bcf7fc30 00007ffd`5053e8d7     sechost!ScSvcctrlThreadA+0x27
07 000000e1`bcf7fc60 00007ffd`5142c53c     KERNEL32!BaseThreadInitThunk+0x17
08 000000e1`bcf7fc90 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

By inspecting the thread's registers and resolving the handles in the wait array, I confirmed the presence of the kernel event \KernelObjects\PrefetchTracesReady:

0:001> r
rax=000000000000005b rbx=0000000000000007 rcx=0000000000000007
rdx=000000e1bcf7fa10 rsi=0000000000000000 rdi=0000000000000007
rip=00007ffd51502714 rsp=000000e1bcf7d178 rbp=000000e1bcf7d570
 r8=0000000000000001  r9=0000000000000000 r10=0000000000000007
r11=0000000000000007 r12=000000e1bcf7fa10 r13=000000e1bc813000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000244
ntdll!NtWaitForMultipleObjects+0x14:
00007ffd`51502714 c3              ret

0:001> dq rdx L7
000000e1`bcf7fa10  00000000`000001c8 00000000`000001c4
000000e1`bcf7fa20  00000000`00000150 00000000`000001e4
000000e1`bcf7fa30  00000000`000002b4 00000000`000002dc
000000e1`bcf7fa40  00000000`00000210

:001> !handle 2b4 7
Handle 2b4
  Type         	Event
  Attributes   	0x10
  GrantedAccess	0x120001:
         ReadControl,Synch
         QueryState
  HandleCount  	2
  PointerCount 	63826
  Name         	\KernelObjects\PrefetchTracesReady

Here, consider this event as the starter's pistol. Once the kernel's 10-second timer expires, it signals this event to the SysMain service to indicate: “The trace is ready, come and get it!”

2. NtQuerySystemInformation

Then, once the SysMain service knows that the data is available, we can read again in Windows Internals that it makes a call to the internal syscall NtQuerySystemInformation for requesting the trace data.

To observe the precise moment when trace data is exchanged, I established a kernel debugging session using VirtualKD-Redux and a Windows 11 VM on VMware Workstation Pro.

At the same time, thanks to my friend Adams, I stumbled upon Geoff Chappell's website, which is a gold mine of information on undocumented structures. I discovered that there was one for the Prefetch mechanism (SUPERFETCH_INFORMATION) which helped me a lot. To filter the noise, I focused on the first argument of NtQuerySystemInformation, which defines the information class requested. On x64 systems, this first parameter is passed via the RCX register so we need to check for the value 0x38 (SystemSuperfetchInformation).

After identifying the EPROCESS address for the right svchost.exe instance, I switched the debugger context and set a conditional breakpoint:

kd> .process /i /p <EPROCESS>
kd> bp /p <EPROCESS> nt!NtQuerySystemInformation ".if (@rcx == 0x38) {.echo '--- CLASS 0x38 DETECTED ---'; r rdx, r8} .else {gc}"

Upon launching MSPaint.exe to trigger a Prefetch scenario, the breakpoint was hit. To allow the kernel to populate the buffer with the trace data, I executed a gu command to step out of the function and return to the caller.

1: kd> gu
nt!KiSystemServiceCopyEnd+0x28:
fffff806`df4b5658 65ff0425b82e0000 inc     dword ptr gs:[2EB8h]

Once the call completed, I inspected the structure pointed to by RDX. The signature 43 68 75 6b ("Chuk") confirmed the presence of the SUPERFETCH_INFORMATION container and that the data transfer was successful:

kd> db 000000bad817d118 L20
000000ba`d817d118  01 00 00 00 43 68 75 6b-01 00 00 00 00 00 00 00  ....Chuk........

By dumping the memory buffer (the pointer found within the structure at offset +0x10), the raw "blueprint" of the Prefetch file was revealed. This data confirm the Windows Internals following statement:

:::note "The trace assembled in the kernel notes faults taken on the NTFS master file table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), referenced files, and referenced directories." :::

1: kd> db 000001cd00040000 L1000
000001cd`00040000  00 00 00 00 08 00 24 00-4c 00 4f 00 47 00 46 00  ......$.L.O.G.F.
000001cd`00040010  49 00 4c 00 45 00 00 00-04 00 24 00 4d 00 46 00  I.L.E.....$.M.F.
000001cd`00040020  54 00 00 00 0f 00 48 00-41 00 52 00 44 00 44 00  T.....H.A.R.D.D.
000001cd`00040030  49 00 53 00 4b 00 56 00-4f 00 4c 00 55 00 4d 00  I.S.K.V.O.L.U.M.
000001cd`00040040  45 00 31 00 0f 00 48 00-41 00 52 00 44 00 44 00  E.1...H.A.R.D.D.
000001cd`00040050  49 00 53 00 4b 00 56 00-4f 00 4c 00 55 00 4d 00  I.S.K.V.O.L.U.M.
000001cd`00040060  45 00 34 00 0f 00 48 00-41 00 52 00 44 00 44 00  E.4...H.A.R.D.D.
000001cd`00040070  49 00 53 00 4b 00 56 00-4f 00 4c 00 55 00 4d 00  I.S.K.V.O.L.U.M.
000001cd`00040080  45 00 33 00 07 00 57 00-49 00 4e 00 44 00 4f 00  E.3...W.I.N.D.O.
000001cd`00040090  57 00 53 00 08 00 53 00-59 00 53 00 54 00 45 00  W.S...S.Y.S.T.E.
000001cd`000400a0  4d 00 33 00 32 00 50 00-09 00 4e 00 54 00 44 00  M.3.2.P...N.T.D.
000001cd`000400b0  4c 00 4c 00 2e 00 44 00-4c 00 4c 00 09 00 43 00  L.L...D.L.L...C.
000001cd`000400c0  5f 00 38 00 35 00 30 00-2e 00 4e 00 4c 00 53 00  _.8.5.0...N.L.S.
000001cd`000400d0  0a 00 4c 00 5f 00 49 00-4e 00 54 00 4c 00 2e 00  ..L._.I.N.T.L...
000001cd`000400e0  4e 00 4c 00 53 00 53 00-0a 00 43 00 5f 00 31 00  N.L.S.S...C._.1.
000001cd`000400f0  32 00 35 00 32 00 2e 00-4e 00 4c 00 53 00 4c 00  2.5.2...N.L.S.L.
000001cd`00040100  03 00 57 00 45 00 52 00-06 00 44 00 45 00 56 00  ..W.E.R...D.E.V.
000001cd`00040110  49 00 43 00 45 00 00 00-0f 00 48 00 41 00 52 00  I.C.E.....H.A.R.
000001cd`00040120  44 00 44 00 49 00 53 00-4b 00 56 00 4f 00 4c 00  D.D.I.S.K.V.O.L.
000001cd`00040130  55 00 4d 00 45 00 32 00-0b 00 53 00 56 00 43 00  U.M.E.2...S.V.C.
000001cd`00040140  48 00 4f 00 53 00 54 00-2e 00 45 00 58 00 45 00  H.O.S.T...E.X.E.
000001cd`00040150  0c 00 4b 00 45 00 52 00-4e 00 45 00 4c 00 33 00  ..K.E.R.N.E.L.3.
000001cd`00040160  32 00 2e 00 44 00 4c 00-4c 00 4c 00 0e 00 4b 00  2...D.L.L.L...K.
000001cd`00040170  45 00 52 00 4e 00 45 00-4c 00 42 00 41 00 53 00  E.R.N.E.L.B.A.S.
000001cd`00040180  45 00 2e 00 44 00 4c 00-4c 00 4c 00 0a 00 4c 00  E...D.L.L.L...L.
...

Writing the Prefetch to the disk

Once SysMain has collected the kernel data, the service processes the trace data, combines it with the previously collected data, and then writes it to a file located in the folder you all know: %SystemRoot%\Prefetch.

In order to track the writing of a Prefetch, I used ProcMon and launched Zoom:

<p style="text-align:center;">Procmon</p>

Conclusion

In summary, this research has shown that the Windows Prefetcher originated from a 2003 patent aimed at solving the "seek penalty" of hard drives. Over two decades, this mechanism has evolved through versions of Windows, transforming from a simple boot optimizer into the modern SysMain service.

By following the informations left in Windows Internals, we were able to observe the step-by-step creation of a Prefetch file: from the kernel's 10-second monitoring window and the signaling of the PrefetchTracesReady event, to the final data exchange via the NtQuerySystemInformation.

Ultimately, the .pf files on our disks are the persistent results of this complex dance between the Memory Manager and user-mode services, ensuring that the most critical data is always ready in RAM before we even ask for it.

From Alert to Insight: The Art of Incident Classification

Mon, 26 May 2025 00:00:00 GMT

Introduction

During my career in incident response, I have had the opportunity to qualify a wide range of security incidents, from isolated malware infections to large-scale compromises. Through these experiences, and with the support of colleagues, I have gained valuable insights and practical advice that continue to shape my approach. This post shares those insights with practitioners facing similar challenges.

A well-executed incident qualification sets the tone for the entire response process. It clarifies the initial scope and improves evidence collection and technical analysis. A correct qualification helps align teams, reduces redundant work, and allows for faster containment and remediation.

One important mindset during incident qualification is to avoid accepting initial input without verification. In many investigations, early reports from users or stakeholders are incomplete, misunderstood, or sometimes incorrect. A useful reference here is the medical drama House MD, where Dr. House insists that "everybody lies." In cybersecurity, this usually results from stress, assumptions, or missing context rather than bad intent. Still, it often distorts the first version of events.

Acquire Context

The first step usually involves gathering contextual information. Begin by asking for the date and time when the first suspicion appeared.

Make sure to agree on a consistent time reference, such as UTC. This is especially important if the client operates across multiple time zones. Then ask how the incident was detected. The answer might be an EDR alert, a curious system administrator, or a Managed Security Service Provider (MSSP). This gives early insight into how much visibility and detection capability the organization has.

Next, ask what has been observed since the first detection. This question is essential. In some cases, the attacker may still be active and attempting to escalate privileges. Accurate and timely information at this stage can make the difference between fast containment and a much larger compromise.

It is also important to ask about business impact. Find out what the company does, and what tools or systems are needed for employees to do their work. This can include business applications, communication tools, or access to shared files. If the incident affects multiple environments, but one involves operational technology that is halting a factory and incurring substantial financial loss, then investigative efforts must prioritize containment and recovery in that area. The prioritization of DFIR tasks is often dictated by business continuity needs.

An often overlooked but critical question involves recent changes in the affected perimeter. Were there updates, migrations, or AV changes? This helps filter out potential false positives * Insert your favorite antivirus update that has triggered false alarms on an entire network * and flags risks like compromised software supply chains. Incidents like SolarWinds and 3CX have shown that legitimate updates can be used as backdoors by Threat Actors. Changes like these can also result in assets being unintentionally exposed to the internet during a migration.

Also ask to list any remedial actions taken by the customer: Assets physically turned off, network link cut, deployment of RMM tools, etc...

When you can't investigate on RAM dump for the 7786678th time because everything has been turned off

Ask about the perimeter impacted

Once the contextual information is gathered, the next focus is the assets identified by the client as impacted. At this stage, it's critical to capture technical and environmental metadata that will support both collection and triage phases. The following information should be requested:

Asset Name: to establish a list across impacted systems.
Operating System: essential for evaluating compatibility with potential forensic tools or EDR deployment. Unsupported OS versions can delay investigation.
Role: whether it's a file server, print server, workstation, etc. This helps prioritize based on criticality.
Geolocation: useful for correlating timestamps if multiple time zones are involved, or if deploying on-site responders is considered.
Physical or Virtual: impacts both how to collect (and the possibility of snapshot collection in case of VMs) and how to isolate.
Antivirus Presence and Vendor: helps assess protection gaps, identify false positives, or show possible threat actor activity on the console.
IP Address: to enable quick lookup in logs, SIEM, or network maps.

Next, determine whether logging from these assets is centralized. This is crucial. Too often, responders encounter assets with local log rotation set to just one hour, rendering retrospective analysis impossible. In the case of long-term compromises like APTs, an organization might discover that they can’t confirm the initial access date because logs beyond a certain point no longer exist.

It is equally important to ask whether the impacted systems are tied to an authentication service, especially in environments where identity is a common attack vector. Determine the type (e.g., Active Directory, local accounts, federated identity, SAML, etc.), how many domains exist, and what trust relationships are configured. This influences the logs to request (Kerberos, VPN, AD events, etc.) and helps map out lateral movement potential. In the context of cloud investigation, always asking for the type of license can give an idea of which logs are available and for how long.

Also, gather details on the security controls in place on the impacted perimeter. This includes the presence of multi-factor authentication (MFA), endpoint detection and response (EDR) deployment, hardening practices, allowlisting, and segmentation. These elements are key to quickly assessing the maturity of the environment and the capabilities of the threat actor. For example, an attacker who manages to bypass EDR and MFA likely demonstrates a higher level of sophistication than one who fails at the first hurdle. Understanding which defenses were in place and whether they were effective or circumvented allows responders to estimate the adversary’s skill level and adjust investigation depth and containment urgency accordingly.

Another key topic is resilience. Are the systems backed up? If yes, are those backups tested and isolated from impacted domains? It’s not uncommon to discover backups that are either untested, outdated, or encrypted because they were part of the same trust zone targeted by ransomware. The answer here directly informs both containment and reconstruction strategies, including the establishment of a trustworthy pivot date (the earliest point at which systems can be considered uncompromised).

When the CISO discovers that the backup plan isn't functional

Finally, a description of the surrounding network is required:

Firewall presence and configuration / logging
Proxy logging
DMZ & VLAN segmentation...

Ask about the Internet exposure, contrary to popular belief, phishing is not the primary cause of compromise in most cases observed during field operations. Many initial accesses stem from vulnerable perimeter assets: outdated Citrix, Ivanti, or Fortinet appliances, exposed RDP endpoints, etc. Understanding the exposure and protections in place around these assets often provides crucial context in tracing the initial breach path.

A quick win here is to ask for the external IP address of the impacted perimeter. This enables rapid verification using platforms like Censys or Shodan to determine what services and ports are publicly exposed, which can reveal misconfigurations or forgotten services vulnerable to exploitation.

Another key area to explore is the historical context of the perimeter in question. Ask whether there have been prior incidents affecting the same assets or environment. Sometimes an earlier event, poorly scoped, misclassified, or superficially investigated, can turn out to be the initial foothold of a threat actor who later resurfaces with elevated access and a clearer understanding of the environment. There are numerous real-world examples where credentials, defensive posture, or internal mappings were resold or reused in subsequent attacks.

Similarly, ask for the results of any recent perimeter penetration tests. Unfortunately, penetration test results are often underutilized by customers. A vulnerability may have been reported as critical, but not fixed due to time or resource constraints. Identifying these known weaknesses, especially those that have not been corrected, can shed light on how an attacker gained access to the system, and which weaknesses can still be exploited.

Conclusion

There is no single model for qualifying security incidents. While frameworks and checklists are useful for avoiding blind spots, the process itself must remain flexible and context-driven. With experience, the flow of questions and validations becomes more natural. Patterns become easier to recognize, and your instincts improve as you learn how to read between the lines.

Each case refines your approach. Over time, incident qualification becomes more intuitive, almost like muscle memory. The goal is not to ask every possible question, but to identify the most relevant ones based on the situation. Knowing what to ask, when to ask it, and how to verify the answers is what enables a fast, reliable, and focused response.

The ultimate aim is simple. Build the most accurate and complete understanding of the situation, even when chaos is unfolding around you. That is the foundation for every effective response.

Respond to a TA2541 intrusion

Sat, 09 Sep 2023 00:00:00 GMT

Introduction

Last month, I discovered a report on a threat group known as TA2541. In this report by Proofpoint, researchers have detailed the capabilities of this threat actor, highlighting its tactics and potential motivations.

In this article, I review the main findings of the report and discuss how to mimic this TA by replaying its infection chain. In addition, I will analyze the infection from a DFIR perspective and examine possible response strategies.

Emulation Part

For the purpose of this article, I have emulated the following infection chain:

Figure 1 - TA2541 Infection chain

Initial Compromise with email

In this infection chain, the initial stage typically involves a phishing email that contains a PDF document as an attachment. The PDF file is crafted to deceive the victim into clicking on a Google Drive link, which ultimately results in the download of a malicious VBS.

Once executed, the VBS initiates a sequence of malicious actions, allowing the threat actor to establish a foothold in the victim's environment.

In this infection, the threat actor utilizes the "double extension" technique to trick users who might overlook file extensions. For instance, they could name a file as follows: charters details.pdf.vbs.

For demonstration purposes, I created a phishing e-mail containing a PDF file as an attachment and sent it to my mailbox. The PDF file contained a link to a Google Drive folder in which I temporarily hosted the malicious VBS.

Stage 1 - VBS

To emulate this stage, I replicated the script mentioned in the Proofpoint report, and then substituted the TA's Paste.ee link with the one I provided. The link I used had the content of stage 2 of the attack.

The analysis of this script will be revisited in a subsequent section of the article as part of my DFIR investigation.

Stage 2 - PowerShell & AsyncRAT

The second stage is a PowerShell script, this script allows to compile an embedded AsyncRAT payload in a byte array and inject them with a RunPE technique in the memory land of a process. You can find it on this AnyRun task.

It also drops a VBS to establish a persistence in the startup folder.

To emulate this part, I went to AsyncRAT's github repo: https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp and generated a payload that I encoded to integrate into the script in place of the TA payload. We'll talk about the encoding and analysis of this script in the following section.

With the complete infection chain, I launched it by simulating the behavior of a user who receives the phishing e-mail and clicks on the first VBScript file on a GDrive link.

Respond Part

Now, let's assume the role of an Incident Responder who has been called in to investigate a computer incident detected by a Security Operations Center (SOC) due to a possible connection to IP address 192.168.1.38, possibly a C2 AsyncRAT, reported by a network intrusion detection system (NIDS). The user of the affected system informs you that he has not noticed any suspicious behavior.

I've deployed a Velociraptor agent in server/client mode (like an EDR), which allows me to see what's currently happening on the system and perform live forensic analysis.

To begin my investigation, I did a hunt to retrieve the list of processes running on the machine, network connections, user activity (Proof of Execution, Browser History and Download History), and I also looked for persistence traces on the system.

Process list

I used Velociraptor's Generic.System.Pstree artifact to list all running processes on the current system. This is a quick win, as you can immediately see a suspicious call sequence, a suspicious process name or a process launched from a suspicious path.

Figure 2 - Process list

As this is a case of process injection, there's nothing wrong with the system if you rely on the process list alone. That's why I switched to network connection analysis.

Network Connexion

To analyze network connections, I used the Windows.Network.NetstatEnriched artifact, which gives me a netstat command on the system but enriched with process name and path, authenticode information or network connection details.

Figure 3 - Network Activity

I noticed that a process called RegSvcs.exe located in "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe" was establishing a network connection with the possible AsyncRAT C2. After researching the purpose of Regsvcs.exe, it turned out to be a tool called NET Services Installation to perform the following actions:

Load and register an assembly;
Generate, register and install a type library in the specified COM+ application;
Configure the services you have programmatically added to your class.

To be honest, I didn't know whether this behavior could be caused by a legitimate action. To find out whether it was a process infected by code injection, I analyzed it with the Hollow Hunts tool and, if the result was positive, scanned it with a YARA rule detecting an AsyncRAT payload.

Process scan

Hollows Hunter

Hollows Hunter is a tool from hasherezade. It analyzes all running processes, recognizing a variety of potentially malicious implants (replaced/implanted PEs, shellcodes, hooks, memory patches).

Running it via the Windows.Memory.HollowsHunter artifact on the RegSvcs.exe process, which looks legitimate at first glance, you can see that the tool reports that a PE has been implanted in this process via code injection.

This confirms the suspicion, so all that remains is to identify it with YARA and dump the injected PE for analysis.

Figure 4 - Hollows Hunter output

YARA

Using the Windows.Detection.Yara.Process artifact, I pointed a YARA rule created by IrishIRL to detect AsyncRAT, and it turns out that this rule matched with the RegSvcs.exe process.

Figure 5 - AsyncRAT Yara rule match RegSvcs.exe

I've now been able to tell that this was a true positive, but now we need to find out how this process got infected by finding the root cause.

I then relied on the user activities I collected earlier with my hunt query.

User Activity

Evidence of download

The Windows.Analysis.EvidenceOfDownload artifact allows you to search the directory provided for any file whose Alternative Data Stream (ADS) is named Zone.Identifier, then lists it. It lists all files with a ZoneId equal to 3 or 4, calculates the file's hash value and prints the contents of the Zone.Identifier stream, as it may contain useful information in certain cases.

Figure 6 - Evidence of Download

We can see that a VBS with a double extension has been downloaded from Google Drive into the user's download directory. Thanks to the Virtual Filesystem provided by Velociraptor, which allows me to download any file on the system, I was able to proceed with its analysis:

Figure 7 - Content of the VBS

This script is obfuscated, and includes a variable named JAVA which contains a reversed PowerShell command. This command will be reversed to its original form using the StrReverse function and saved in the Everything variable.

Here is the PowerShell command once it is reversed:

Figure 8 - Reversed command

By reading and decoding it, the script use Invoke-WebRequest cmdlet to download the contents of a PowerShell script on Paste.ee, places it and then executes it in "C:\Users\Public" under the name RemoteFramework64.PS1.

Going back to the Velociraptor's Virtual Filesystem, it turns out that RemoteFramework64.PS1 is still present on the system. So I downloaded it and analyzed it:

Figure 9 - Content of the stage 2 PowerShell script

You can see that it's a PowerShell script used to compile a payload and then inject it using a RunPE technique into RegSvcs.exe , so it's this script that's causing the alert issued by the SOC.

The AsyncRAT payload, the VBS used to perform persistence and the code responsible for injecting the process are stored in byte arrays.

To be able to read them, I had to read the Decompress function, which decompresses them to make them usable. It turns out that they are compressed with gzip and then transformed into comma-separated decimals. In this case, the CyberChef solution helped me to read them in clear.

Figure 10 - Cyberchef Recipe

All that remains is to analyze the user's web history to find out when he downloaded the script from Google Drive, and why not make sure there are no other persistent files on the system.

Web History

Using the artifact Windows.Applications.Chrome.History I was able to obtain a view of the user's web history. Using this history, you can see that the user went to his Gmail inbox, consulted an e-mail named URGENT RFQ // Aircraft Parts - REF 678876 and then pivoted to Google Drive with the page title charters details.pdf.vbs - Google Drive and the link to download the file. This is the page for download the stage 1 script, and it tells us that the root cause is a phishing e-mail.

We'll ask the user for further explanation, so that we can view the e-mail and retrieve its headers.

Figures 11 & 12 - User web history

Persistence

To analyze persistence mechanisms, I used the Windows.Packs.Persistence artifact pack, as well as the Windows.System.TaskScheduler, Windows.Persistence.Wow64cpu & Windows.Persistence.PowershellProfile artifacts.

After examining the various results, we can see that the VBS named SystemFramework64Bits.vbs placed by the powershell script I analyzed above is present in the startup folder "C:\Users\y0sh\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup".

Figure 13 - Content of the Startup Folder

By downloading this script with the Velociraptor's Virtual Filesystem, you can notice that it will launch the PowerShell script (Stage 2) described above after each start-up of the compromised session of the system:

Figure 14 - Content of SystemFramework64Bits.vbs

Timeline

To complete the investigation, it would be prudent to examine both the Master File Table and the USN Journal Analysis log. In this way, an exhaustive chronology can be established of the date and type of malicious files created on the system:

Master File Table (MFT) Analysis: The MFT is a crucial component of the NTFS file system, and it contains metadata about each file and directory on the disk. By analyzing the MFT, we can identify file creation timestamps, modification timestamps, and access timestamps. This will enable us to pinpoint the exact times when the malicious files were created, modified, or accessed on the system.
USN Journal Analysis: The USN journal is a feature in Windows operating systems that records changes made to files and directories on an NTFS volume. It maintains a log of these changes, providing valuable information about file creation, modification, and deletion events. By examining the USN journal, we can obtain a comprehensive view of all file-related activities, including those associated with the malicious files involved in the incident.

By combining data from MFT and USN log analysis, you can create a detailed timeline of the attack's progression, which will help us understand how the malicious files were introduced and propagated through the system.

I could also talk about the different Event ID's within EVTX, but to keep the article short for the reader, I've decided not to write about this part.

This chronology will be an essential asset in the incident response process, and will help to formulate an effective plan to mitigate the threat and prevent its recurrence in the future.

Type of Action	Description	Timestamp (UTC+0)
[WEB HISTORY] Google Mail - Mailbox	Title: Boîte de réception (1) - REDACTED@gmail.com - Gmail	2023-07-23T17:05:37Z
[WEB HISTORY] Google Mail - Suspicious Mail	Title: URGENT RFQ // Aircraft Parts - REF 678876 - REDACTED@gmail.com - Gmail	2023-07-23T17:05:56Z
[WEB HISTORY] Google Drive - Malicious download webpage	Title: charters details.pdf.vbs - Google Drive	2023-07-23T17:06:59Z
[USER ACTIVITY - DOWNLOAD] Download of charter details.vbs	Path : C:\Users\y0sh\Downloads\charters details.pdf.vbs ZoneId = 3 ReferrerUrl = https://drive.google.com	2023-07-23T17:08:12Z
[USN] Presence of RemoteFramework64.PS1	FullPath : C:\Users\Public\RemoteFramework64.PS1 Reason : FILE_CREATE	2023-07-23T17:08:32Z
[PERSISTENCE - STARTUP FOLDER / USN] SystemFramework64Bits.vbs	OSPath : C:\Users\y0sh\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\SystemFramework64Bits.vbs Reason : FILE_CREATE	2023-07-23T17:08:34Z

I recommend the collaborative incident response platform DFIR-IRIS to do this more professionally.

Conclusion

Thanks to Velociraptor's innovation and the analysis of forensic artifacts, I was able to unravel the chain of compromise orchestrated by TA2541.

Velociraptor's capabilities proved to be essential in dissecting the threat actor's tactics, enabling us to trace his steps through the various stages of the attack lifecycle. From the initial obfuscated VBS file hosted on Google Drive URLs to the execution of PowerShell and the subsequent deployment of AsyncRAT in memory, we meticulously reconstructed the adversary's modus operandi.

References

https://www.proofpoint.com/us/blog/threat-insight/charting-ta2541s-flight

https://blog.bushidotoken.net/2021/01/analysis-of-netwire-rat-campaign.html

https://twitter.com/MsftSecIntel/status/1392219299696152578

https://blog.morphisec.com/revealing-the-snip3-crypter-a-highly-evasive-rat-loader

https://blog.talosintelligence.com/operation-layover-how-we-tracked-attack/