1. Overview
   1. Stage 1 - AutoIt Dropper (script.au3)
   2. Stage 2 – DLL Loader (740b0000.clr.dll)
   3. Stage 3 – Decrypted Payload Execution (RegSvcs.exe)
      1. Volatility Memory Analysis - Manual PE Mapping
         1. Legitimate ntdll.dll Locations
         2. Suspicious RWX Memory Region at 0x400000
         3. Not Listed in Loader Table
         4. PE Structure + Shellcode Confirmed (malfind)
   4. Network Analysis
      1. DNS Resolution and IP Rotation
      2. Connection Behavior
   5. YARA Rules
      1. AutoIt_Evasive_Loader
      2. Evasive_DotNet_Payload
   6. MassLogger Attribution
   7. IOC List
   8. Tools Used

Overview

This blog documents the reverse engineering of a staged malware sample tagged as MassLogger / Snakelogger variant. The original file was retrieved from MalwareBazaar and analyzed through a hybrid static and dynamic workflow involving memory dumping, emulation, and custom detection engineering.

Sample Details:

• Filename: NEWORDER.exe
• First Seen: 2025-01-15 17:07:30 UTC
• SHA256: e3140471b8e10e218754105e8fe4305bd7045f0f1da7eee586b07e5cfe4206b5
• Tags: masslogger, snakekeylogger, stealer, autoit, regsvcs
• Sandbox Behavior: Identified by ANY.RUN as SnakeKeylogger, with observed use of RegSvcs.exe for DLL execution, beaconing to checkip.dyndns.org, and system recon via WMI and registry access.

The binary is a compiled AutoIt dropper containing an obfuscated payload stored in the variable $FPPRUULVXM. Decryption is performed using a custom function AJZIWSIBC(), which implements XOR-based arithmetic on long numeric strings, a common pattern in AutoIt-based malware. Once decrypted, a .NET DLL (740b0000.clr.dll) is dropped and executed via RegSvcs.exe. This DLL then decrypts and injects a third-stage shellcode payload into memory.

The investigation used:

• PE-Sieve to extract the memory-mapped DLL
• IDA Pro and x64dbg to reverse and trace functions (sub_740C1C96, sub_740C2045)
• Speakeasy and scdbg for shellcode emulation attempts (ultimately inconclusive)
• YARA to match known traits and author custom rules for detection

Stage 1 - AutoIt Dropper (script.au3)

The first stage of this malware is a compiled AutoIt executable named NEWORDER.exe. To analyze its behavior, the binary was unpacked using AutoIt-Ripper, which extracted an embedded script into a readable script.au3 file.

At the top of this script, a custom decryption function named AJZIWSIBC() is defined:

Func AJZIWSIBC ( $JCAYYEU , $OCDHLSA )
    Local $IWUAXZNCM = ""
    For $VWHHUCUWIZS = 1 To StringLen ( $JCAYYEU )
        $IWUAXZNCM &= Execute ( _
            "Chr(Asc(StringMid($jcayyeu, $vwhhucwizs, 1)) - Mod($ocdhlsa + $vwhhucwizs, 256))" )
    Next
    Return $IWUAXZNCM
EndFunc

This function performs a position-dependent arithmetic transformation on each character of the input string, dynamically evaluating it using Execute(). Unlike fixed-key XOR encoding, this technique introduces a per-character offset based on its position and a supplied key, making it harder to decode without full emulation or reversing.

Following this definition, the script constructs a large obfuscated payload by repeatedly appending numeric-looking strings to a global variable named $FPPRUULVXM. For example:

Global $FPPRUULVXM = "56184065205618406525..."
$FPPRUULVXM &= "52056184065205618406525..."
$FPPRUULVXM &= "84065205618406525..."
; (spans many lines and hundreds of KB of encoded content)

These segments contain numeric ASCII sequences, not actual binary data. Each 9-digit chunk encodes one character, typically using the last three digits (e.g., 652), which are interpreted and transformed at runtime. The full blob is passed to AJZIWSIBC() with a hardcoded key of 4.

None of the decoded content exists statically in the script. All transformation occurs during execution, allowing the loader to bypass static analysis and signature-based detection. The decrypted code is not written to disk. Instead, execution is handed off to RegSvcs.exe, a signed Microsoft binary, which loads the resulting .NET DLL (740b0000.clr.dll) directly into memory.

Global $SJNWPER = Call ( AJZIWSIBC ( "J~lk~~p" , 4 ) , $JAYFUDCI & "(@TempDir & ""\overfertilize"", 18)" )

During runtime, the script decodes this payload entirely in memory using the AJZIWSIBC() function. The resulting blob is then saved to %TEMP%\overfertilize and executed using RegSvcs.exe, a trusted signed Microsoft binary. This approach avoids writing any static payloads or recognizable binary headers to disk during initial stages, effectively bypassing many forms of static analysis and signature-based detection.

The decrypted data does not start with a standard MZ header, suggesting it may be shellcode, an encrypted .NET assembly, or a second-layer loader. The file overfertilize is ultimately loaded as a .NET DLL via RegSvcs.exe, marking the transition into Stage 2: a memory-resident payload.

Stage 2 – DLL Loader (740b0000.clr.dll)

The second stage of the malware chain is a memory-resident .NET DLL (740b0000.clr.dll) executed by RegSvcs.exe, recovered using PE-Sieve during runtime. Although it was unpacked from an AutoIt wrapper and presents as a .NET module, analysis shows it lacks a valid CLR header and does not invoke typical CLR bootstrap routines. This suggests it operates outside the managed runtime, likely through unmanaged shellcode or custom loader stubs. Furthermore, the DLL does not import any Windows API functions via the import table, instead relying on pointer arithmetic, jump tables, and low-level constructs to resolve functionality dynamically, evading traditional static analysis.

The Stage 2 DLL does not import Windows API functions via the import table; instead, it likely resolves necessary APIs dynamically at runtime. This inference is supported by downstream use of functions like CreateThread, despite their absence in static imports, implying runtime export parsing or pointer-based resolution.

Initially, the loader employs a compact jump-table located at .data:747F4110–747F411C (Figure 2), where four DWORD entries direct execution flow. These DWORD values facilitate indirect jumps to specialized staging routines such as handling "small chunks" or "large regions," contributing to variant handling and stealth by preventing direct API or memory access.

Each DWORD in the jump table corresponds to a loader routine, guiding execution based on runtime conditions. For instance:

• +0x04 → 0x740C1C96: initiates memory allocation and staging via sub_740C1C96.
• +0x10 → 0x740C2045: responsible for XOR decryption of the embedded payload.

Disassembly of sub_740C1C96 confirmed these runtime jump destinations: the loader reads thread-local flags via fs:[0xE24], which determine whether execution is routed to sub_740C2045.

The core dispatcher, sub_740C1C96 (Figure 3), merges TEB access and flag masking into a unified narrative. It begins by establishing thread context, pushing EBX/EDI/ESI registers, and retrieving a global staging pointer from .data:747F4010. If ECX is nonzero, it calls sub_740C20C4, a minimal helper accessing thread-specific memory via the TEB (fs:[0xE24]), crucial for anti-debugging and state tracking. This context then informs a per-thread flags operation—masked by 0x5F—before routing execution through the aforementioned jump-table based on the thread-specific state.

Execution then transitions to sub_740C2045, streamlining its primary logic through LOCK CMPXCHG instructions. Here, an atomic compare-and-exchange sequence safely claims memory slots, enabling thread-safe staging without external APIs. This subroutine notably handles entropy reseeding by recursing into the earlier mentioned sub_740C20C4, and concludes via a direct tail-call to sub_7415BBB4, orchestrating the final memory preparation stage.

Sub_7415BBB4 (Figure 5) emphasizes anti-debugging through structured exception handling. It sets up a structured-exception frame via __EH_prolog3_catch, establishing crash-resilience and anti-debugging defenses. Stack variables receive pointer-based context before transitioning control to sub_740C2C00, verifying the preparation of the memory region before restoring registers and transitioning control to the prepared RWX region.

Throughout Stage 2, the loader operates without traditional WinAPI imports, performing all operations through calculated pointer resolutions, interlocked memory instructions, and structured exception frames, significantly complicating static and dynamic analysis.

Importantly, Stage 2 does not initiate any observable network connections. This was validated via FakeNet and Wireshark during controlled execution. All external communication—such as DNS resolution and TLS handshakes to C2 servers—is deferred until Stage 3, after payload decryption and injection.

Stage 3 – Decrypted Payload Execution (RegSvcs.exe)

After the AutoIt dropper launches RegSvcs.exe, execution is passed to a custom loader embedded in a .NET DLL. To observe the final stage of execution and extract payload artifacts, we attach to RegSvcs.exe using x32dbg after it has already begun staging the payload in memory.

Once attached, we pause the process and set a breakpoint on CreateThread - a common API used to invoke in-memory payloads. When this breakpoint is hit, we inspect the value pushed as the lpStartAddress parameter, which points to the memory address where execution of the next stage will begin.

Following this lpStartAddress into the Memory Map leads us to a surprising location: the address resides within the .text section of ntdll.dll. This suggests the loader did not use traditional shellcode injection via VirtualAlloc and memcpy, but instead unpacked the decrypted payload directly into the code section of a dropped or side-loaded DLL.

The .text section was dumped and analyzed. Although not marked as RWX or residing in anonymous memory, this region exhibited all the expected hallmarks of a final payload: high-entropy code, embedded plaintext strings, and behavioral indicators common in stealer malware and C2 stagers. In x32dbg, the CreateThread start address appeared to reference ntdll.dll (0x77231000), but Volatility later confirmed that the actual payload was mapped at 0x400000 — a manually mapped PE not listed in the loader’s module list. This mislabeling is a deliberate evasion tactic, allowing malicious code to masquerade as a trusted module.

A manual diff between the memory-mapped .text region at 0x400000 and the legitimate ntdll.dll at 0x771c0000 confirmed this was not a real image. The fake section lacked standard syscall exports like ZwQueryInformationProcess or RtlExitUserThread, and instead contained entirely custom routines such as sub_74207D0F, sub_7439C4F0, and sub_744665CA. These functions implement complex control flow, SEH-based anti-debugging, and indirect function resolution.

Closer inspection of these routines clarifies their respective roles: sub_74207D0F functions as a dispatcher, walking through a memory-based function pointer table and calling handlers based on runtime values. This structure suggests a modular loader architecture. sub_7439C4F0 wraps multiple validation and setup routines inside an SEH-controlled block, with indirect pointer use and stack cookie protection — behavior typical of anti-debug and crash-safe stagers. sub_744665CA manipulates a context block at [esi+10h] and [esi+14h], sets transition flags, and invokes further payloads using a call chain. It also contains DebugBreak and int 3, confirming its anti-analysis design.

I noticed that the .text section of ntdll.dll having executable and read permissions was highly unusual even though the address of CreateThread matched the memory address in the x32dbg Memory Map. ntdll.dll's .text section is typically protected as PAGE_EXECUTE_READ, meaning it's read-only and executable but not writable.

Further reversing revealed the internal structure of these routines. sub_74207D0F acts as a dispatcher that walks through a custom pointer table, selecting handlers based on runtime memory state. sub_7439C4F0 wraps its logic in SEH and performs staged control logic that culminates in conditional handler calls, likely to decoding or setup functions. Finally, sub_744665CA manipulates fields such as [esi+10h] and [esi+14h], invokes lower-level stagers, and includes intentional DebugBreak and int 3 instructions, signaling anti-analysis behavior and payload staging.

Volatility Memory Analysis - Manual PE Mapping

Memory analysis with Volatility confirmed that the payload was not executing from the legitimate ntdll.dll. Instead, the second stage loader manually mapped a PE file residing at 0x400000 into the memory region to appear as if it belonged to ntdll.dll.

Legitimate ntdll.dll Locations

To establish the loader's known modules using ldrmodules:

Result:

• ntdll.dll is correctly loaded at:
  • 0x771c0000 - SysWOW64
  • 0x7ffe63d5xxxx - WoW64 transition space

This confirms that the real ntdll.dll is present and untouched in expected memory regions.

Suspicious RWX Memory Region at 0x400000

Next, I used vadinfo to examine all memory regions mapped within the process:

Result:

• Memory range: 0x400000 – 0x41dfff
• Protection: PAGE_EXECUTE_READWRITE
• Mapped file: N/A

Red Flags:

• RWX permissions are rarely legitimate, and almost always signal potential code injection.
• The absence of a mapped file means this region was not loaded via standard OS mechanisms.

Not Listed in Loader Table

To further validate this region’s origin, I rechecked ldrmodules for any entry corresponding to 0x400000:

Result:

• No matching module was found, seen in the last column with the MappedPath value as N/A - proving it has no backing file.

This confirms 0x400000 is not part of any module the Windows loader is aware of, ruling out legitimate libraries like ntdll.dll, kernel32.dll, etc.

PE Structure + Shellcode Confirmed (malfind)

Finally, I examined the contents of the suspicious region with malfind:

Result:

• An MZ header was found at 0x400000 → confirms PE structure.
• Disassembly revealed a typical shellcode preamble including stack manipulation (pop edx), arithmetic instructions (add [reg], al), and padding (nop).
• This region contains a manually mapped, reflectively injected PE file.

Although no breakpoint was set on VirtualAlloc or NtMapViewOfSection, the combination of RWX memory, a valid MZ header, and absence from the loader list suggests that the payload was reflectively loaded. Function sub_740C1C96 is a likely candidate for this behavior based on its use of memory copying and pointer-based control logic.

Network Analysis

Wireshark was used to monitor network traffic during execution of the AutoIt dropper and the subsequent RegSvcs.exe process. Shortly after launch, the malware attempted outbound connections to public IP services including checkip.dyndns.org and reallyfreegeoip.org. This behavior is consistent with staging routines where the payload attempts to determine the host’s external IP address and geolocation before progressing to later stages of execution.

DNS Resolution and IP Rotation

Within seconds of execution, DNS queries were issued for both domains. The response from checkip.dyndns.org included multiple rotating A records, such as 132.226.8.169, 158.101.44.242, and 193.122.130.0.

Similar DNS traffic was recorded for reallyfreegeoip.org, which resolved to Cloudflare IPs including 104.21.64.1 and 104.21.48.1, as well as multiple IPv6 addresses. This behavior reflects dynamic infrastructure usage to complicate static domain-to-IP detection.

Connection Behavior

Following the DNS resolution, outbound TCP connections were initiated to the resolved IPs on port 443. Wireshark captured a complete TLS handshake for reallyfreegeoip.org, with the Server Name Indication field in the Client Hello explicitly confirming the target domain. TLS version 1.3 was used in all observed handshakes.

No application-layer data was visible in these sessions, which is expected given the encrypted channel. However, the sequence—DNS resolution, TLS handshake, and the use of known IP profiling services—indicates that the malware performs an initial environmental fingerprinting step. This may involve public IP registration, geolocation logging, or basic connectivity verification, all of which are common in commodity malware and staged delivery frameworks.

YARA Rules

Based on the static and behavioral traits uncovered during analysis, the following YARA rules were developed to detect both the loader and its injected payload.

AutoIt_Evasive_Loader

import "pe"

rule AutoIt_Evasive_Loader
{
    meta:
        author = "Vincent Dinh"
        description = "Detects a compiled AutoIt loader using potential anti-debugging and TLS callbacks"
        version = "1.1"
        created = "2025-05-21"
        reference = "SHA256: e3140471b8e10e218754105e8fe4305bd7045f0f1da7eee586b07e5cfe4206b5"
        tags = "AutoIt, loader, TLS, anti-debug, Go-artifacts"
        malware_family = "Masslogger"

    strings:
        // AutoIt traits
        $autoit_marker1 = ">>>AUTOIT SCRIPT<<<" ascii wide
        $autoit_marker2 = "#pragma compile" ascii wide
        $autoit_marker3 = "This is a third-party compiled AutoIt script." ascii wide

        // Go-related strings (suspicious if mixed with AutoIt)
        $go_build = "Go build" ascii wide
        $go_runtime = "runtime" ascii wide

        // Anti-debugging artifacts
        $dbg1 = "IsDebuggerPresent" ascii
        $dbg2 = "OutputDebugString" ascii
        $dbg3 = "QueryPerformanceCounter" ascii
        $dbg4 = "GetTickCount" ascii
        $dbg5 = { 0F A2 }           // cpuid
        $dbg6 = { 0F 31 }           // rdtsc

    condition:
        uint16(0) == 0x5A4D and
        (
            2 of ($autoit_marker*) and
            1 of ($go_*) and
            4 of ($dbg*)
        ) and
        pe.data_directories[9].virtual_address != 0 and
        pe.data_directories[9].size != 0  // TLS callback presence
}

Evasive_DotNet_Payload

import "pe"

rule Evasive_DotNet_Payload
{
    meta:
        author = "Vincent Dinh"
        description = "Detects a .NET-based evasive payload containing Go strings, anti-debugging, and injection behavior"
        version = "1.1"
        created = "2025-05-21"
        reference = "Dropped by AutoIt loader – 740b0000.clr.dll"
        tags = ".NET, anti-debug, process-injection"
        malware_family = "Masslogger"

    strings:
        // Suspicious Go references in a .NET context
        $go1 = "Go build" ascii wide
        $go2 = "runtime" ascii wide

        // Known anti-debugging or evasion APIs
        $api1 = "IsDebuggerPresent" ascii
        $api2 = "OutputDebugString" ascii
        $api3 = "QueryPerformanceCounter" ascii
        $api4 = "GetTickCount" ascii
        $api5 = "SetConsoleCtrlHandler" ascii
        $api6 = "AddVectoredExceptionHandler" ascii
        $api7 = "SetThreadContext" ascii

        // Timing tricks
        $ins1 = { 0F A2 }  // cpuid
        $ins2 = { 0F 31 }  // rdtsc

    condition:
        uint16(0) == 0x5A4D and
        1 of ($go*) and
        5 of ($api*, $ins*)
}

MassLogger Attribution

The analyzed sample (SHA256: e3140471b8e10e218754105e8fe4305bd7045f0f1da7eee586b07e5cfe4206b5) matches a known Masslogger variant listed on MalwareBazaar. Attribution is further supported by:

• Use of an AutoIt dropper for payload staging, a known Masslogger delivery method.
• Reflective memory mapping and jump-table logic in the Stage 2 loader, consistent with modular Masslogger architectures.
• Stage 3 memory-resident payload includes strings such as ClipboardVault, PasswordVault, and FFLogins, aligning with past credential theft functionality seen in Masslogger campaigns.
• Network IOCs include api.telegram.org and reallyfreegeoip.org, which have been repeatedly observed in Masslogger operations.
• Registry and file paths such as HKCU\Software\Microsoft\Windows\CurrentVersion\Run, and %APPDATA%\CloudServices.exe, further reinforce stealer behavior.

IOC List

Sample Metadata

• Initial Dropper: NEWORDER.exe
• Stage 2 Loader: 740b0000.clr.dll
• Shellcode Dump: overfertilize
• Memory Dump Region: regsvcs_77231000.bin
• Analyzed Process: RegSvcs.exe

File Names

• CloudServices.exe
• MozillagLue.dll
• nss3.dll
• omnibox.dll
• sqlite_master_entry
• UserData.txt
• logins.json
• secserv.dll
• .txt2

URLs/Domains

• checkip.dyndns.org
• reallyfreegeoip.org
• api.telegram.org

Network-Based Indicators

• TLS SNI (Observed in Handshake): reallyfreegeoip.org
• URIs: /sendDocument?chat_id= (Telegram exfiltration endpoint)
• URIs: /xml/70.120.59.240
• URIs: / (default root beacon for checkip service)
• Ports: 443 (HTTPS / TLS)
• TLS Version: TLS 1.3
• User-Agent (Confirmed from Memory): Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR1.0.3705;)

Internal Vault & Data Artifacts

• UserData.txt
• ClipboardVault
• PasswordVault
• ScreenshotVault

Credential Harvesting / DB Schema Artifacts

• CREATE TABLE logins
• CREATE TABLE password_notes
• CREATE TABLE insecure_credentials
• RecoveredApplicationAccount
• FFLogins
• KeyLoggerEventArgs

Registry & Persistence References

• HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
• HKCU\Software\Microsoft\Windows Messaging Subsystem\Profiles\Outlook\9375CFF0413111d3B88A00104B2A6676
• HKLM\SYSTEM\CurrentControlSet\Control\WMI\Security
• SOFTWARE\Classes\Foxmail.url.mailto\shell\open\command
• SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\Outlook\9375CFF04131111d3B88A00104B2A6676
• SOFTWARE\Microsoft\Office\16.0\Outlook\Profiles\Outlook\9375CFF04131111d3B88A00104B2A6676
• HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options

Anti-Debugging & Evasion Strings

• IsDebuggerPresent
• OutputDebugString
• QueryPerformanceCounter
• GetTickCount
• RaiseFailFastException
• SetThreadContext
• AddVectoredExceptionHandler
• GetForegroundWindow
• UnhookWindowsHookEx
• ToUnicodeEx
• GetKeyboardLayout
• MapVirtualKey

Embedded APIs & System Functions

• GetTokenInformation
• OpenProcessToken
• CryptProtectPromptFlags
• ReadAllBytes
• ReadAllText
• GetWindowText
• TakeScreenshot
• Directory.GetFiles
• Environment.GetFolderPath
• AppDomain.CurrentDomain
• WebClient, SmtpClient, FtpWebRequest

Other (Application/Service Names & File Paths)

• Foxmail
• Foxmail.exe
• Thunderbird
• Firefox
• Outlook
• Thunderbird\profiles
• FileZilla
• %APPDATA%\FileZilla\recentservers.xml
• %APPDATA%\Thunderbird\Profiles\
• %APPDATA%\Mozilla\Firefox\Profiles\
• %APPDATA%\SeaMonkey\Profiles\
• %APPDATA%\Comodo\IceDragon\Profiles\
• %APPDATA%\Opera\
• %APPDATA%\Kometa\User Data\Default\Login Data
• %APPDATA%\Epic Privacy Browser\User Data\Default\Login Data
• %APPDATA%\Nichrome\User Data\Default\Login Data
• %APPDATA%\Amigo\User Data\Default\Login Data
• %APPDATA%\Xpom\User Data\Default\Login Data
• %APPDATA%\BraveSoftware\Brave-Browser\User Data\Default\Login Data
• %APPDATA%\Torch\User Data\Default\Login Data
• %APPDATA%\UCBrowser\User Data_i18n\Default\UC Login Data.18
• %APPDATA%\Blisk\User Data\Default\Login Data
• %APPDATA%\7Star\User Data\Default\Login Data
• %APPDATA%\xVast\User Data\Default\Login Data
• %APPDATA%\Chedot\User Data\Default\Login Data
• %APPDATA%\Superbird\User Data\Default\Login Data
• %APPDATA%\360Browser\Browser\User Data\Default\Login Data
• %APPDATA%\360Chrome\Chrome\User Data\Default\Login Data
• %APPDATA%\Comodo\Dragon\User Data\Default\Login Data
• %APPDATA%\e360_China\User Data\Default\Login Data
• %APPDATA%\Opera\User Data\Default\Login Data
• %APPDATA%\QIP Surf\User Data\Default\Login Data
• %APPDATA%\BlackHawk\User Data\Default\Login Data
• %APPDATA%\SevinStar\User Data\Default\Login Data
• %APPDATA%\Sleipnir\User Data\Default\Login Data
• %APPDATA%\Iridium\User Data\Default\Login Data
• %APPDATA%\Chromium\User Data\Default\Login Data
• %APPDATA%\orbitum\User Data\Default\Login Data
• %APPDATA%\Uran\User Data\Default\Login Data
• %APPDATA%\Falkon\User Data\Default\Login Data
• %APPDATA%\Iron\User Data\Default\Login Data
• %APPDATA%\Comodo\User Data\Default\Login Data
• %APPDATA%\Amigo\User Data\Default\Login Data
• %APPDATA%\Citrio\User Data\Default\Login Data
• %APPDATA%\CoolNovo\User Data\Default\Login Data
• %APPDATA%\Microsoft Edge\User Data\Default\Login Data
• %APPDATA%\Cent Browser\User Data\Default\Login Data
• %APPDATA%\Ghost Browser\User Data\Default\Login Data
• %APPDATA%\Chromium\User Data\Default\Login Data

Tools Used

• AutoIt-Ripper for script extraction
• IDA Free for static disassembly of DLL
• x32dbg for live memory introspection
• PE-Sieve for dumped DLL acquisition
• Wireshark for network telemetry capture
• scdbg & Speakeasy for shellcode emulation (partial)
• Volatility 3 for Memory Forensics

← Back to Blog