Babble Babble Babble Babble Babble Babble BabbleLoader Intezer Loaders, an Ever Evolving Market The pace of innovation and development in the malware detection market is relentless, the same goes for the development of malware itself. Constantly charging and adapting to create ever more evasive and capable payloads. One such sector of this market is the loader (also called crypter or packer) market. In today’s threat landscape, loaders have become a critical tool in cybercrime operations, serving as the backbone for delivering a range of malicious payloads. Loaders are often the first stage in an attack chain, designed to stealthily execute or inject malware, such as info-stealers or ransomware, into a target system. Their prevalence reflects an evolution in tactics, allowing threat actors to evade traditional antivirus defenses through techniques like in-memory execution and anti-analysis features. Widely available for purchase or lease on underground markets, loaders are now a commodity in malware distribution, making sophisticated attack methods accessible to a broader range of actors and adaptable across diverse campaigns and targets. In this blog, we will introduce “BabbleLoader”, an extremely evasive loader, packed with defensive mechanisms, that is designed to bypass antivirus and sandbox environments to deliver stealers into memory. BabbleLoader’s Techniques to Evade Traditional and AI Systems BabbleLoader stands out for its array of sophisticated evasion techniques that challenge both traditional and AI-based detection systems. Key features include junk code insertion and metamorphic transformations, which alter the loader’s structure and flow, effectively evading signature-based, Artificial Intelligence, and behavioral detections. Through dynamic API resolution, the loader sidesteps common API monitoring by resolving necessary functions only at runtime, preventing static analysis from identifying telltale Windows APIs. Also bypassing sandbox injected DLLs that hook API calls. Shellcode loading and decryption further obfuscate the payload by embedding and decrypting malicious code in memory, bypassing file-based scanning. Additionally, anti-sandboxing and anti-analysis measures detect virtual environments, impeding sandbox analysis and automated AI defenses. Together, these techniques make this loader a versatile tool, capable of subverting both static and dynamic security layers. When investigating this loader, we have seen it used across multiple campaigns, targeting both

Phase: Initial Access

• Technique: Loader Deployment via Phishing or Exploit
• Procedure: The attacker delivers BabbleLoader through phishing emails or exploits, initiating the attack chain by executing the loader.

Phase: Execution

• Technique: In-Memory Execution
• Procedure: BabbleLoader uses in-memory execution to deploy its payload, bypassing traditional antivirus file-based scans.

Phase: Evasion

• Technique: Junk Code Insertion and Metamorphic Code

• Procedure: Implements junk code and metamorphic transformations to alter the loader's structure, evading signature-based and AI detections.

• Technique: Dynamic API Resolution

• Procedure: Resolves necessary API functions at runtime, preventing static analysis from detecting Windows APIs.

• Technique: Shellcode Loading and Decryption

• Procedure: Embeds and decrypts malicious shellcode in memory, avoiding detection by file-based scanning.

• Technique: Anti-Sandboxing Techniques

• Procedure: Detects virtual environments to impede sandbox analysis, preventing automated defenses from executing.

Phase: Impact

• Technique: Payload Delivery
• Procedure: Stealthily injects info-stealers or ransomware into the target system's memory, executing the payload without alerting defenses.

English and Russian speaking individuals. Lure themes suggest it is targeting a vast range of users, from users looking to download generic cracked software, such as video editing, gaming, VPN, browsers, and utilities. We have also noticed campaigns that target with a particular focus on business professionals in finance and administration, masquerading as accounting software, and forms for filling out eligibility checks often used by HR or payroll professionals. Technical Analysis The sample used in this analysis is: a08db4c7b7bacc2bacd1e9a0ac7fbb91306bf83c279582f5ac3570a90e8b0f87 Junk Code/Metamorphism BabbleLoader makes diabolical use of junk code. This is done in an effort to hamper analysis by confusing the analyst. This is achieved through multiple means. There are many paths of code that are never actually accessed, but use random imports with randomly generated hardcoded strings. Junk Code making rubbish calls The loader also makes excessive use of random instructions, adding values to local variables and moving data around registers for no particular functionality.

Phase: Initial Access

• Technique: Phishing with Malicious Software Themes
• Procedure: The attacker uses themes of cracked software and business-related applications, such as accounting software, to lure users into downloading malicious executables.

Phase: Defense Evasion

• Technique: Junk Code Injection
• Procedure: The malware employs junk code and random instructions to obfuscate its functionality and hinder analysis. This includes random instructions, unnecessary local variable manipulations, and unused code paths.

Phase: Delivery

• Technique: Malicious Software Execution
• Procedure: Users are tricked into executing the malware under the guise of legitimate software, which could include fake video editing tools, games, VPNs, browsers, or business utilities specific to finance and administration.

(Note: Exact commands and tools are not provided in the report. The above procedures are inferred based on typical behaviors associated with described techniques.)

Junk Code The amount of junk code added into the sample greatly increases the amount of code to the point where it starts to crash disassembly or decompilation tools through its sheer mass alone. In the case of IDA needs to collapse nodes due to them being so large. Collapsed Node in IDA In Ghidra the function graph view will freeze and there are too many instructions for the decompiler to show. Decompilation output in Ghidra We have even checked in Binary Ninja to see the effects of the junk code. The user is required to manually force analysis of the function due to the size. Binary Ninja showing large function Each of these techniques also serve the purpose of making the loader metamorphic. Each build of the loader will have unique strings, unique metadata, unique code, unique hashes, unique encryption, and a unique control flow. Each sample is structurally unique with only a few snippets of shared code. Below is a very small snippet of the main method of two different samples, showing very different control flow. Comparison of structure of two BabbleLoader samples Even the metadata of the file is randomized for each sample.

Phase: Obfuscation

• Technique: Junk Code Insertion

• Procedure: The attacker inserts a significant amount of junk code into the malware samples to hinder disassembly or decompilation tools. This results in exceptionally large functions that cause tools like IDA, Ghidra, and Binary Ninja to struggle, making analysis difficult.

• Technique: Metamorphic Code

• Procedure: The loader undergoes transformations for each build, resulting in unique strings, metadata, code, hashes, encryption, and control flow. This approach ensures each sample is structurally unique, complicating detection and analysis.

Phase: Evasion

• Technique: Randomized Metadata
• Procedure: The metadata of each malware file is randomized for every sample, contributing to its uniqueness and helping bypass signature-based detection mechanisms.

Junk Metadata What This Means for AI-Based Analysis Techniques These techniques also have large implications for AI based analysis techniques. This constant variation in code structure forces AI models to continuously re-learn what to look for—a process that often leads to missed detections or false positives. By filling the code with junk instructions, the loader can trick AI into interpreting irrelevant actions as meaningful ones, leading it to predict that the malware will perform operations that it never actually executes. Junk code also generates a large volume of “noise” in the program flow, overwhelming the AI’s pattern-recognition capabilities and forcing it to sift through thousands of extraneous actions that mask the true behavior of the malware. Additionally, the inclusion of countless junk variables adds another layer of complexity. AI models analyzing variable behavior to understand data flow must now track thousands of decoy variables, each potentially obfuscated or dynamically transformed to further confuse the analysis. This variable noise, combined with the ever-shifting structure from metamorphism, makes it extremely difficult for AI to reliably determine which variables are integral to the malware’s function and which are simply junk. The sheer volume of junk code and variables also makes analyzing this loader exceptionally costly. The sheer number of tokens AI must process to parse and interpret the junk alone leads to high computational and financial costs, effectively weaponizing the malware’s complexity against AI- driven defenses. This combination of overwhelming data volume, misleading patterns, and high processing requirements creates significant challenges in detecting and analyzing the malware accurately. Dynamic API Resolution One of the first operations of the loader is to start the process of dynamically resolving API calls. It will achieve this through API hashing. It will first get a module handle for ntdll.dll. The string for the DLL is decrypted using a rolling XOR cipher.

Phase: Execution

• Technique: Dynamic API Resolution
• Procedure: The threat actor uses dynamic API resolution by employing API hashing. This process begins with obtaining a module handle for ntdll.dll. The DLL string is decrypted using a rolling XOR cipher.

Phase: Defense Evasion

• Technique: Junk Code Injection

• Procedure: The loader introduces junk instructions throughout its code to obfuscate real functionality. This effectively tricks AI detection systems into misinterpreting the code structure, leading to false positives or missed detections.

• Technique: Junk Variable Injection

• Procedure: A large number of junk variables are included and obfuscated, adding another layer of complexity and confusion for AI-based analysis, making it challenging to differentiate between essential and decoy variables.

These procedures create significant computational overhead for AI-driven defenses, complicating the detection and analysis processes.

Decoding of NTDLL string Using the returned handle, the loader will start to read the PE header of ntdll.dll and it will locate the export directory and start parsing out values that it will need to dynamically resolve the functions by hash. The loader builds up the following struct. struct _NtDllExportInfo { DWORD AddressOfFunctions; DWORD AddressOfNames; DWORD* AddressOfNameOrdinals; DWORD NumberOfNames; HMODULE NtdllModuleHandle; } The parsed values can be seen easily from viewing the export directory in CFF explorer. Parsed fields shown in CFF Explorer Once the struct has been built up, it can then proceed to iterate through the export names, hashing the names to compare to hardcoded values in the binary. Resolution of functions by hash The following calls are resolved, getting pointers for imports. Whilst the exports will remain the same for each build of the malware, the hashing will be unique per each build. Hash Call 1ABEC790 NtCreateSection 993C0058 NtMapViewOfSection

Phase: Defense Evasion

• Technique: Dynamic API Resolution
• Procedure: The malware decodes strings to identify and load ntdll.dll. It reads the PE header to locate the export directory and parses fields like AddressOfFunctions, AddressOfNames, AddressOfNameOrdinals, and NumberOfNames. The malware uses these to dynamically resolve function names by hashing them and comparing against hardcoded values.

Phase: Execution

• Technique: API Function Call
• Procedure: The malware resolves and calls the following functions dynamically using their hashes:
• Hash: 1ABEC790, Function: NtCreateSection
• Hash: 993C0058, Function: NtMapViewOfSection

Contextual Notes

• Objective: This behavior allows the malware to obfuscate API calls, making it harder for defenders to detect and analyze, as function resolution is done dynamically without static indicators.

Decryption stages Before calling the decrypted code, the loader will perform one of a number of anti sandboxing checks. AntiSandboxing/Analysis DirectX DLL One of the anti-sandboxing checks involves checking the installed graphics adapters to see if it is running in a sandboxed environment or not. This is achieved by importing the DLL dxgi.dll. The DLL is the DirectX Graphics Infrastructure library and is a core Windows DLL that provides functionality for interfacing with graphics hardware.
The exported function CreateDXGIFactory is called giving the loader a IDXGIFactory object. This allows the loader to enumerate information from the installed graphics adapters by calling EnumAdapters, followed by GetDesc from the IDXGIAdapter object to give a DXGI_ADAPTER_DESC struct. typedef struct DXGI_ADAPTER_DESC { WCHAR Description[ 128 ]; UINT VendorId; UINT DeviceId; UINT SubSysId; UINT Revision; SIZE_T DedicatedVideoMemory; SIZE_T DedicatedSystemMemory; SIZE_T SharedSystemMemory; LUID AdapterLuid; } DXGI_ADAPTER_DESC; From these structs is parsed the VendorId, and it is compared against three values that form a vendor whitelist. ID Vendor 8086 Intel 10DE Nvidia

Phase: Anti-Analysis

• Technique: Graphics Adapter Enumeration for Sandbox Detection
• Procedure:
• Import DirectX DLL: dxgi.dll
• Function Call: CreateDXGIFactory to obtain an IDXGIFactory object.
• Enumeration: Use EnumAdapters and GetDesc from the IDXGIAdapter object.
• Data Structure: Obtain DXGI_ADAPTER_DESC struct.
• Vendor Check: Compare VendorId against a whitelist with the following IDs:
  • 8086 (Intel)
  • 10DE (Nvidia)

92263458 NtUnmapViewOfSection 9DA1D253 NtClose 6AF3F390 NTQuerySystemInformation 0A96AB0E4 RtlAllocateHeap 8A21A480 RtlFreeHeap Shellcode Loading and Payload Decryption Once the loader resolves pointers for the imports, it first calls NtCreateSection, followed by NtMapViewOfSection. This approach allows the malware to allocate and manage memory outside the standard process space. The decryption process begins with the loader rearranging the randomly stored encrypted chunks of the payload into their correct order within the mapped memory, before proceeding to decrypt each block.

Phase: Execution

• Technique: Process Injection and Memory Management

• Procedure:

• API Calls:

  • NtCreateSection: Used to create a memory section for storing malicious payloads.
  • NtMapViewOfSection: Maps a view of the created section into the virtual address space of the current process.
  • NtUnmapViewOfSection: Unmaps the view of a section from the process's address space to manage memory usage.
  • NtClose: Closes handles to free resources.
  • RtlAllocateHeap: Allocates memory from the heap for rearranging and decrypting payload data.
  • RtlFreeHeap: Frees allocated heap memory after use.

• Action:

• The loader resolves necessary API pointers.
• Allocates and manages memory using the above functions to handle encrypted payload chunks.
• Reassembles and decrypts these chunks in the correct order within mapped memory for execution.

This structured approach allows attacks such as shellcode loading by operating outside standard process constraints.

Another form of anti-sandboxing comes in the form of a VDLL check to combat Windows Defender’s Antivirus Emulator. To start this check, BabbleLoader, in a similar manner to how it deobfuscates strings to dynamically resolve functions, will decode two DLLs with exports. The first check is to get kernel32.dll and look for the proc address for MpSwitchToNextThread_WithCheck. The second check is ntdll.dll with the export of MpDispatchException. Call of emulated function If any of the GetProcAddress calls are successful, it will set a variable for the loader to exit later. A successful import of any of these calls will indicate that the loader is being emulated by Windows Defender. This is because these exports only exist in VDLLs, which are modified Windows system DLLs available only in the emulator for Defender. This technique has been used by Raspberry Robin previously, and suggests that the loader developer is able to incorporate new technical research around antivirus and sandboxing internals. Unique process count When the shellcode payload that is stored in the mapped memory of the newly created section is executed, it performs another anti sandboxing check, this time based on the running processes in the machine. This is achieved first by calling NtQuerySystemInformation, previously dynamically resolved from ntdll.dll. Getting the SystemProcessInformation class. This returns an array of SYSTEM_PROCESS_INFORMATION structures, one for each process running in the system. The process name for each process in the array is gathered and hashed as a checksum, and compared with the hash of the name of the process next in the array. A counter is incremented with each iteration, but if the checksums match, the counter is reduced by one. Giving the number of processes with unique names running.

Phase: Defense Evasion

• Technique: Virtual Environment Detection via VDLL Check
• Procedure: BabbleLoader decodes two DLLs and attempts to locate specific exports:
• DLLs and Functions:
  • kernel32.dll: Check for MpSwitchToNextThread_WithCheck
  • ntdll.dll: Check for MpDispatchException
• If GetProcAddress successfully locates these functions, the loader interprets it as running in a Windows Defender emulator and sets a variable to exit.

Phase: Discovery

• Technique: Process Enumeration and Unique Process Count
• Command: Call NtQuerySystemInformation with SystemProcessInformation to retrieve running processes.
• Procedure: The shellcode payload performs the following:
• Retrieves an array of SYSTEM_PROCESS_INFORMATION structures for each process.
• Gathers and hashes the process names.
• Compares hashes to identify unique process names, adjusting a counter based on matches to count unique processes.

1002 AMD This anti-sandboxing technique has been observed in previous malwares, namely Furtim in 2016 and Invalid Printer Loader in 2023. BabbleLoader takes additional measures to hide the vendor ID numbers through using a simple XOR key and a few assembly instructions. The instructions are separated by a large amount of junk code so as to hide the values when statically analyzing the sample in a disassembler. mov [rsp+1FF48h+nvidiaId], 0E8185136h ... //Junk ... mmov eax, [rsp+1FF48h+nvidiaId] xor eax, 0E81841E8h mov [rsp+1FF48h+nvidiaId], eax ... //Junk ... mov eax, [rsp+1FF48h+nvidiaId] cmp [rsp+1FF48h+vendorId], eax The decoded value (Nvidia Vendor ID) is shown below: XOR to derive VendorID VDLL Function

Phase: Anti-Analysis

• Technique: Anti-Sandboxing via Obfuscation
• Procedure: BabbleLoader implements anti-sandboxing by hiding vendor ID numbers through obfuscation using XOR operations and assembly instructions. Junk code is inserted between meaningful instructions to resist static analysis.

Assembly Instructions:

• Store Vendor ID:
  assembly mov [rsp+1FF48h+nvidiaId], 0E8185136h

• Decode Vendor ID using XOR:
  assembly mov eax, [rsp+1FF48h+nvidiaId] xor eax, 0E81841E8h mov [rsp+1FF48h+nvidiaId], eax

• Compare Decoded Value:
  assembly mov eax, [rsp+1FF48h+nvidiaId] cmp [rsp+1FF48h+vendorId], eax

This sequence hides the Nvidia Vendor ID through a simple XOR operation and surrounds it with junk instructions to hinder analysis.

Second stage of decryption Donut Loader and Payload The next stage in this chain is a Donut loader. This is used to unpack and execute the final payload in memory. Donut loaders have been used by many different malware and threat groups in their operations. The payload in this sample is a WhiteSnake stealer. WhiteSnake Payload This payload has a very interesting method of communication with its Command and Control (C2) server over TOR. The C2 communication is described in further detail in a blog from JFrog in 2023, but instead of downloading from the official TOR Project website. The payload is downloaded from this github repository. Open source project downloaded by WhiteSnake In other samples, Meduza stealer has also been observed. There may be other stealer payloads delivered that have not been observed yet. Considerations for Defense The use of loaders is a long-standing technique incorporated by threat actors. In order for modern day threat actors to have any success against the many layers of detection employed by security vendors, they too must incorporate multiple layers of defense within their own builds. It is a never ending arms race between attacker and defender. Each side imposing increasing costs on the other in a frantic effort to come out on top, no matter how short that time period may be. The better that the loaders can protect the ultimate payloads, the less resources threat actors will need to expend in order to rotate burned infrastructure. BabbleLoader takes measures to protect against as many forms of detection that it can, in order to compete in a crowded loader/crypter market. The types of protection utilized protect the loader against hash, rule, genetic, static,

Phase: Execution

• Technique: In-memory Execution with Donut Loader
• Procedure: The Donut loader is used to unpack and execute the final payload directly in memory, avoiding disk writes and traditional detection methods. This involves running the loader which then decrypts and executes the payload in memory.

Phase: Execution

• Technique: Payload Execution (WhiteSnake Stealer)
• Procedure: Once unpacked by the Donut loader, the WhiteSnake stealer is executed in memory. This stage involves leveraging in-memory operations to further evade detection.

Phase: Command and Control

• Technique: Communication over TOR
• Procedure: The WhiteSnake stealer uses TOR for secure communication with its Command and Control (C2) server. This involves anonymizing its network traffic to conceal the C2 communication paths.

Phase: Execution (Alternative Payload)

• Technique: Payload Execution (Meduza Stealer)
• Procedure: In other observed instances, the Meduza stealer is used as the payload executed by the Donut loader. This again follows the pattern of in-memory execution to avoid detection.

Note: The specific command-line syntax and parameters for the Donut loader and associated payloads are not provided in the report but the techniques and procedures imply in-memory loading and execution techniques typically used by loaders.

Checksum counter The counter is compared to check if there are at least 85 unique processes running on the machine. With the assumption that a true infected computer would have more running processes rather than a sandbox or emulator that is trying to be as lightweight as possible to reduce noise and costs. This technique has been employed by other malware also, such as Latrodectus. When the check has passed, the next stage of the payload will be decoded and executed.

Phase: Defense Evasion

• Technique: Environment Evasion via Process Count
• Procedure: The malware checks for at least 85 unique processes running on the machine to differentiate between a real environment and a sandbox or emulator. If the condition is met, the next stage payload is decoded and executed.

dynamic, and AI forms of detection, imposing costs upon security vendors in the hope that the cost of detection will be so high that it will cause security vendors to overlook analyzing these files. The developer behind this loader demonstrates an active engagement with current security research, rapidly integrating new techniques to enhance evasion capabilities. For instance, recent anti-sandboxing features reflect insights from research on Windows Defender presented by white- hat experts at Black Hat, allowing the loader to better evade detection by Microsoft’s defenses. This adaptability shows a strategic commitment to keeping the loader ahead of evolving security tools by adopting the latest innovations in bypass techniques, making it more resilient and harder to detect with each new build. Many security vendors will look at using AI to help in future cases with combating these loaders. The loaders of the future are already well equipped in this fight. The loader’s layered obfuscation tactics pose a formidable challenge for AI-based defenses. These techniques flood the AI with irrelevant tokens and misleading patterns, making it difficult to distinguish meaningful actions from noise. Each layer of complexity forces the AI to process massive amounts of data, drastically increasing computational and financial costs. By weaponizing this volume and variability, the loader effectively undermines AI’s pattern recognition and analysis capabilities, pushing the limits of automated detection systems. There is no signs of slowing down in the pace in the thriving loader market. IOCs BabbleLoader: 052c776fdc9700dfb37f964a73d461a57efad30a01bcf54505d7abcd601e6ff3 0ad8513b62a778d7e426627be3ed2dbaf00d99b9802a1f566dc9203e3d311fc3 0f6847d33cb38b0ed6dc1d8cfe3dc5d2e293d91c4880e3b4f5ddb77fd9d4cd1f 114b868f319162c5d6ff92796e41910f54de0e89f895a066fd4980c6dba2e323 1367fb270f35512b17fe5e73cc0233ace272daafe15cf94e45f696431f52332f 1537965c7722a9886d542688fcbafecd1248b2fbd56e9a90a803a50e880e1bb8 16200bbe4646fe8cefeee5be20ce55c50300485f3356ab181fb930bd02536709 1da4de2b4b87bff7f9f1a3208c5c663a06f7f9b67f918e5a5e8e860e759b7075 200289d5a408a2e49a894228edb3324548ca5c5c0283d09486aa287df41f15bc 217d7501287ae894f47bd04253bd184d1901dd131b0cd15bcbbeba5158049d5d 22866e6ded40916de8002606f82e44ee141f27c3340fa2c4d16514624ee05a72 237812322bbbcf47feeb79b8e91b97d00453ffd5deb52c819c183b45d18b0b5a

The provided text primarily discusses a loader's evasion techniques rather than specific command lines or tools. However, I can infer some likely procedures based on the behavior described.

Phase: Defense Evasion

• Technique: Anti-Sandboxing

• Procedure: The loader employs anti-sandboxing techniques derived from research on Windows Defender to evade detection. This likely includes methods such as checking for sandbox artifacts or manipulating execution flow to avoid sandbox triggers.

• Technique: Obfuscation

• Procedure: The loader uses layered obfuscation to confuse AI-based defenses. This could involve techniques such as code packing, encryption, or using polymorphic code to change appearance with each execution, complicating signature-based detection.

Phase: Defense Evasion (AI Manipulation)

• Technique: Data Flood
• Procedure: The loader introduces irrelevant tokens and misleading patterns. This can involve inserting random or nonsensical code snippets and strings to overwhelm AI models' pattern recognition.

There are no explicit command lines given in the text, but typical methods for achieving these may include:

• Command (Inferred): Use of scripts or custom executables with obfuscation techniques (packer.exe, script.ps1 -encoded)
• Command (Inferred): Executing environment checks to detect sandboxes (if sandboxed then exit)

These inferred procedures would be part of a broader strategy to remain undetected while delivering payloads or conducting further actions.

25923b822e9a1374817caf79375170b944f2762b1e3f2add921008ffec702740 2a8a340fc9c395fe23211ac95d124b64452d49c67b069f53aaf3dbe16e95791d 2b6bff7b8c23f1fa526e116c7577c32845d5b969c68a66850c305a351adc9726 2d6b50003436ed489d1b46566eb879e317e1b9a5b6edb12f3cbb4c8a8d932a08 2eab850166944175e5fac4c89706328a58dcef55dbc22ff20342d1d246ba76b9 2ee32c46207119f6851f2869203124c104c72cfdf9622416252ae3405f485cd2 328d92b71034d74c016b1f8e70217be3f432a2ade8fe44522f84980fd0dbb1f9 33e42e7828cda7987d17342e0eb8134f590cd3d291dbc75f13334259a4908ba1 3bf5f07059a24fb803c6fefb874f000e9c300372b1b870e48b4935bd0219fe2b 401209ec9dda222984fd5cb775a6b6c2e651d88c04a506c9058cb1decdce869d 451e1bec8476a89c7d2b526071fa2918187f2f5b3ba9362e6999114993a74da5 455cd0db2de92ee348295780f8fc7a32a5406a5986a4d162761680f11b6346b1 466a8af8d0b51ed82aec35b17b845e6baf77ada259aa2fd5591024a01d8e31b5 46b355d25b95d7f9d7029f1ee1a346028e3c5bdec9e6c9245c12d1607cb1c686 46f0e190cd346d1eb6d0c27386bb3aceebf4ad44b25d253cac4063e2ccde9028 478eb22a1f1be2ef6e70625cf42ca61c716389135acbb705c0e21f0cf330bf46 47a71eb078b14a92eb5fb990f606aa48e535860af90ebc5e075c8b2e4d829633 4b7fa864007357e3e799eeb4a9630425652178551a9c37181fc6ea86660af814 4ba95478ea0ac78e038d30693fabf95244bd70e40b36b2a928f3854551d6fa78 4bed4960a896ebeafa9a9421d7ecf389205a2f0216ad911bdcd80f28237159e6 4e40aaddf718b70f397d449f8ca9a577ef0106f281ccb50f0b5cde531b758881 5305556bee271232973a9e09c4776a3b386964112785db638b225b2cc61d9af7 53e451750c099f33f80a3652d9f2a804390de0f867af13ae22ad0fbf4b15f8c3 5493fa6f2ab69da66352532b2c13e7e461bcde6cc2810a6f6af88e139dde1ae7 5665c96975c959b5e8057b7aed46f7c203335aefa35f5e290c538e9300e3e293 5b9481d9022b0efcaed04513d338048de4aa3e1328bacc0966486ef322c0d086 5eb3bb67656d990ceec07f55c78dcd8032a7cf00ac919a399e3642b177f68381 60ecef2d0a966db913bff15872c072175b895e16271351c43e5a0cf9e4018f22 643dde3f461907a94f145b3cd8fe37dbad63aec85a4e5ed759fe843b9214a8d2

I'm sorry, it seems that the provided content is not a CTI report. If you could provide more information or context regarding a cybersecurity threat intelligence report, I would be able to help extract and structure the procedures used by the threat actor.

69ad389722dd8b49590b2aa014f703b39737894073c7339ea44c94d296e00273 78f6c822cee2b0587df145d67478cce5bbeb76147a7846d08b7b6fd09aa36ce2 796c245c5bb1e7c1dcd52c4e8f83e1c707e391f6409ee9b5e1dd18658ff0e05f 7df313618a02e8e9961ddb1c3289956eb18361f1ca9fb639d64a00fae7568a4b 7e5ba9e3ccc1cb52d24c21c6d378a32bb540a8519789d8cf796e5dd351fc6958 8907a8454ef56d64bf788b9c8c64bbaaf187be7a9666d8d8331fd187c49c6031 8a28e457b19060678d5d007b291722e1dea92f69249e1588ca5b97eb1fe10807 8cc2e1104480875ee237bf4ca9f3d83e46ca213f5c88df95be0d78e05c7c2d71 8cf8bea6842219e565720919372e4aa530942b28d533231043ee57e7bb424cbe 8d8c3b6be212ce645566311ce95ad9ad3aad37795042882adefda9716deb2eab 8e63b1f7f8e29b9a714f796e2e8ca0cd1094086e2d0a5de21601e23e1792a906 9125c13250a14905a4fd97978a3a6dbba80df01e73d98f8d4fa2d19b49d9fda0 9314ea889f93da5cd39129840a42bd5f228538686a2345f56e757e5a5d956dee 9bf7a01254fed809e0f564f28a3cf54156ea98f85d3b633ae3a213a87f9db143 9dfb8ed499b667d782ae3a4ce40472893a789ed973f48884b47358536b6a76e8 9fa7574f35fae3d309c8cefe0e8a43d07afb6cefaee0caa3b2538263bd4a7ec5 a01ac4244102e3958296c70d71e3d951f11abcc355458d1918d081587b151d90 a08db4c7b7bacc2bacd1e9a0ac7fbb91306bf83c279582f5ac3570a90e8b0f87 a29e108e912c77ed565873bd205da01ed0e6001d18b442139c06827428d2eba1 a3b45619606d4c3c487047786e3d51a98fdcc1fdc43dc7b6f6e80974fd0a9c97 a695cb493631962a4c2fd61a094cb0b952ce708a99af714772cddd4991f32df0 ae6ee6bf2f9890ed83922e5c80770dd88faa9b32b2211462ea2eed29bf1bf6c5 b14af38c4230de20c7c4fefc1e3c5fffb1562bacedfebc56a508f55182a6fe88 b1ebe1794e091fd82a34d6806f18f64ebadb5d3b2343a661c481fb7c54cb872f b2a91277e5fb40a0a38215142f683554b4e7c03ccd439e0d056c56b031a5bec5 b72d9ae8484b91ec9c6167e6707617f495622f3b684f6b3e30b29106891c778b bb4f812f8bb4e7b33d7b583407370a5351d079f63b26956adc7ab317b3d90601 bdd6bd29937059dd944fb09163a24e4482c5ce420d3de749e5e46c6c25b2ea86 c2a95f22cfee1f4df67a424e30425b59c23db265bff611f2ee653d71b30a70d8

The text provided seems to be a sequence of alphanumeric strings with no context or information related to threat actor procedures or a cyber threat intelligence (CTI) report. To assist you, please provide details or segments from a CTI report that describe the threat actor's tactics, techniques, and procedures (TTPs), such as command lines, tools, and attack techniques used.

ca67f61b5f8d20ec3f45dbbfc355045a8ceee15396f1cad032850a3ee23a42b3 cd3f064d088a3a6a6ad03da148701fb6b660866b8aac2a808359505620166641 d7967661947ca835deddec30ae6e62d580718cbdeafb42cd6d0f038a407edcf0 d9cea34db0d1dc016dd4007d8cd11416f095c41b0639f13af1eb6ad675651df2 db282cae419ed5af3338f65f170ecd7b312cac2500b5cb2c8824721ba981c361 db41e032193becc097d0da85cac74cf1f519b85cf731f783ccea11c1e20ad23f e09c36993e1c29b6ef0f1c73e02aee54686c0df49b6d87b577e70f261313acaf e13f20752f6298728ac0463a3f4b0657d5657ca7710e63a27ac1179078ac71f6 e1448680114cb3dd06aa81a3b1037f77e6d5b3f6dce213aa38cffdec72d59e74 f2f23a963952c1a822484382bf4c68cd8b7278400ad2d8bacf3235ba2fc42a89 fa292bfcf81223bab0f79d4ce08187e37d68960005629df0241ea22f0b95d7a8 fc589aa3529a057fee52a1c9bd9bb19fa42bbfd291b7dbb3791e77eced376640 ffcae0093d509563b47b1d0cef3aa455a4358de3a1d2c2b84c298a927aa238e8 WhiteSnake Stealer: 6dce9024ec032390ca4294f62cb282a09291cf141cb003f7e0ef23bb7a34bfae Ryan Robinson Ryan is a security researcher analyzing malware and scripts. Formerly, he was a researcher on Anomali's Threat Research Team.

Based on your input, it seems that specific procedures from a CTI report have not been included. However, if you're looking for how a threat actor might utilize a malware such as a stealer in an attack, here’s a structured guess at what the procedures could look like:

Phase: Initial Access

• Technique: Phishing via Malicious Email
• Procedure: The attacker sends a phishing email with an attachment or link to download the malicious executable.

Phase: Execution

• Technique: User Execution
• Command: Execution of the stealer executable by the user after downloading.

Phase: Credential Access

• Technique: Credential Dumping with WhiteSnake Stealer
• Procedure: Once executed, WhiteSnake Stealer attempts to extract credentials from the browser and system.

Phase: Persistence

• Technique: Registry Run Key
• Command: reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v WhiteSnake /t REG_SZ /d "C:\path\to\malware.exe" /f

Phase: Exfiltration

• Technique: Data Transfer to External Server
• Procedure: Collected credentials and data are sent back to the attacker's server over HTTP/HTTPS.

For exact procedures from a detailed CTI, please provide or describe the specific steps from the report.

Model: gemini-2.0-flash

Okay, here's the structured extraction of TTPs from the BabbleLoader CTI report, formatted for red team emulation:

Phase: Initial Access

• Technique: Exploitation of Cracked Software and Masquerading
  • Procedure: Targets users seeking cracked video editing software, gaming software, VPNs, browsers, and utilities. Also targets business professionals in finance and administration via masquerading as accounting software or forms for eligibility checks.

Phase: Defense Evasion

• Technique: Junk Code Insertion & Metamorphism

  • Procedure: Inserts junk code to confuse analysts and crash disassembly/decompilation tools.
  • Note: Achieved through random imports with randomly generated hardcoded strings and excessive random instructions for no particular functionality.

• Technique: Dynamic API Resolution (API Hashing)

  • Procedure: Resolves API calls at runtime to evade static analysis.
    1. Decrypts the string for "ntdll.dll" using a rolling XOR cipher.
    2. Gets the module handle for ntdll.dll.
    3. Reads the PE header of ntdll.dll, locating the export directory.
    4. Parses the export directory to dynamically resolve function addresses.
  • Note: Employs API hashing, comparing calculated hashes against hardcoded values.

• Technique: Shellcode Loading & Payload Decryption

  • Procedure:
    1. Calls NtCreateSection followed by NtMapViewOfSection to allocate memory outside standard process space.
    2. Rearranges encrypted chunks of the payload into the correct order in mapped memory.
    3. Decrypts each block.

• Technique: Anti-Sandbox/Analysis – DirectX DLL Check

  • Procedure: Imports dxgi.dll.
  • Calls CreateDXGIFactory giving an IDXGIFactory object.
  • Enumerates graphics adapters using EnumAdapters.
  • Calls GetDesc from the IDXGIAdapter object, creating a DXGI_ADAPTER_DESC struct.
  • Parses the VendorId from the struct.
  • Compares the VendorID against a whitelist (Intel, Nvidia, AMD).
  • Applies a XOR operation to the stored VendorID to derive the actual value.

• Technique: Anti-Sandbox/Analysis – VDLL Check

  • Procedure: Decode "kernel32.dll" to getmodulehandleA and decode "MpSwitchToNextThread_WithCheck" to getprocaddress. And decode "ntdll.dll" to getmodulehandleA and decode "MpDispatchException" to getprocaddress.

• Technique: Anti-Sandbox/Analysis – Unique Process Count

  • Procedure:
    1. Calls NtQuerySystemInformation to get the SystemProcessInformation class, which returns an array of SYSTEM_PROCESS_INFORMATION structures.
    2. Gathers process names for each process in the array.
    3. Hashes the process name as a checksum.
    4. Compares the checksum with the next process in the array, incrementing a counter unless the checksums match.
    5. Checks if the counter is greater than or equal to a threshold (85) representing unique process names.

Phase: Execution (Payload)

• Technique: Donut Loader
  • Procedure: Unpacks and executes the final payload in memory using a Donut loader.
• Payload Type: WhiteSnake Stealer
  • C2 Communication: communicates with its Command and Control (C2) server over TOR.

Disclaimer: This information is based solely on the provided CTI report. The actual techniques and procedures used may vary. Red team operations should be conducted with proper authorization and adherence to ethical hacking principles.

Model: gemini-2.5-flash-preview-05-20

Below are the extracted and structured procedures based on the provided CTI report, focusing on attack techniques, programs, and tools, while excluding specific IOCs.

Phase: Initial Access

• Technique: Phishing via Malicious File Delivery
• Procedure: Threat actors distribute the BabbleLoader using lure themes suggesting downloads of generic cracked software (e.g., video editing, gaming, VPN, browsers, utilities) or masquerading as legitimate business tools (e.g., accounting software, HR/payroll eligibility forms). This delivery is likely achieved through spear-phishing emails or malicious websites.

Phase: Execution

• Technique: Loader-based Execution / In-Memory Payload Delivery
• Procedure: BabbleLoader functions as the initial stage in the attack chain, designed to stealthily execute or inject subsequent malicious payloads, such as info-stealers or ransomware, directly into the target system's memory, thereby bypassing file-based scanning.
• Tool: BabbleLoader

Phase: Defense Evasion

• Technique: Code Obfuscation / Junk Code Insertion
• Procedure: BabbleLoader injects a large volume of non-functional instructions, random code paths, and irrelevant operations with randomly generated hardcoded strings and random imports. This technique is used to confuse analysts and analysis tools, leading to difficulties in disassembly and decompilation.

• Command: Not applicable; implemented as internal loader logic.

• Technique: Metamorphic Code Generation

• Procedure: Each distinct build of BabbleLoader features unique strings, metadata, code structure, encryption keys, and control flow. This constant variation ensures that the loader's hash and appearance change with every compilation, evading signature-based and static detection methods.

• Command: Not applicable; implemented as internal loader logic.

• Technique: Dynamic API Resolution / API Hashing

• Procedure: BabbleLoader dynamically resolves necessary Windows API functions at runtime, rather than statically linking them. This is achieved by first decrypting the DLL string (e.g., ntdll.dll) using a rolling XOR cipher, then parsing its PE header to locate and resolve required functions (e.g., NtCreateSection, NtMapViewOfSection, NTQuerySystemInformation, RtlAllocateHeap, RtlFreeHeap, NtUnmapViewOfSection, NtClose) by their calculated hash values. This bypasses static analysis and evades sandboxes that rely on API hooking.

• Command: Not applicable; internal programmatic execution.

• **Technique: Shellcode Loading and Decryption in Memory

• Procedure: After resolving necessary APIs, the loader calls NtCreateSection followed by NtMapViewOfSection to allocate and manage memory outside the standard process space. It then rearranges randomly stored encrypted chunks of the payload into their correct order within this mapped memory before decrypting each block.

• Command: Not applicable; internal programmatic execution.

• Technique: Virtualization/Sandbox Evasion / Graphics Adapter Check

• Procedure: BabbleLoader performs a check for virtualized environments by examining the installed graphics adapters. It imports dxgi.dll and utilizes functions like CreateDXGIFactory, EnumAdapters, and GetDesc to retrieve graphics adapter information. The VendorId obtained (which is obfuscated using XOR and junk assembly) is then compared against a whitelist of legitimate vendor IDs (e.g., Intel, Nvidia, AMD). If the VendorId does not match, it indicates a likely virtual or sandboxed environment.

• Command: Not applicable; internal programmatic check.

• Technique: Virtualization/Sandbox Evasion / Windows Defender Emulator Detection (VDLL Check)

• Procedure: To detect Windows Defender's antivirus emulator, the loader attempts to dynamically resolve specific API functions that are known to exist only within VDLLs (modified Windows system DLLs used by the emulator). Specifically, it checks for MpSwitchToNextThread_WithCheck from kernel32.dll and MpDispatchException from ntdll.dll. If these functions are successfully resolved, the loader identifies an emulated environment and may terminate execution.

• Command: Not applicable; internal programmatic check.

• Technique: Virtualization/Sandbox Evasion / Process Count Check

• Procedure: The second-stage shellcode performs an anti-sandboxing check based on the number of unique processes running on the machine. It calls NtQuerySystemInformation to obtain an array of SYSTEM_PROCESS_INFORMATION structures. The loader then hashes the name of each process and compares adjacent hashes to count unique processes. Execution proceeds only if the count of unique processes exceeds a threshold (e.g., at least 85), under the assumption that a real system will have more running processes than a lightweight sandbox.
• Command: Not applicable; internal programmatic check.

Phase: Impact

• Technique: Data Exfiltration
• Procedure: After passing anti-sandboxing checks and decryption, the final payload (delivered by a Donut loader) communicates with its Command and Control (C2) server over the TOR network to exfiltrate stolen data.
• Tool: Donut loader (used to unpack and execute the final payload in memory)
• Tool: WhiteSnake stealer (observed payload in the analyzed sample)
• Tool: Meduza stealer (observed payload in other samples)
• Command: Not applicable; internal programmatic communication and execution of stealer.