Key Findings:
During threat hunting activities conducted on the ANY.RUN platform, the artifact was identified in public submissions of the interactive sandbox. The analysis of samples available in the public repository allowed correlating hashes and network behaviors with the already mapped C2 infrastructure (24.152.36.241), confirming that the GrabBot/Slinky campaign is active and being distributed in a real environment. The sandbox results complement the static analysis presented in this report, providing dynamic execution evidence.
Attack Vector and Social Engineering: The malware disguises itself as a Minecraft hack called “Slinky”. It uses the official game icon to induce voluntary execution, exploiting the trust of young users in the gaming scene.
Architecture and Evasion: The software operates in a two-stage modular structure:
Loader (load.exe): Packaged in Node.js (via pkg), 53.5 MB. The large size and thousands of legitimate libraries (V8, OpenSSL) aim to “dilute” malicious signatures and bypass sandbox upload limits.
Payload (chromelevator.exe): A native C++ binary of 1.4 MB, injected directly into memory.
Exfiltration and Theft Capabilities: The malware is a highly comprehensive infostealer, targeting 5 data categories across 8 different browsers (Chrome, Edge, Brave, Opera GX, Firefox, etc.):
Infection Chain:
EXECUTIVE SUMMARY
This report documents the static analysis of two PE64 binaries comprising a modular infostealer identified as LofyStealer, with characteristics of GrabBot/1.0 built with the “Slinky Cracked” builder, distributed as an alleged Minecraft hack, exploiting the trust of a predominantly young audience.
The threat operates in two stages: a 53.5 MB loader (load.exe) based on Node.js packaged via pkg, and a native C++ payload of 1.4 MB (chromelevator.exe) that is decrypted in memory and injected directly into the victim’s browser processes via direct syscalls to the Windows kernel.
The separation between loader and payload, combined with the use of syscalls that bypass EDR hooks, demonstrates a level of sophistication above average for malware distributed in a gaming context.
LOADER ANALYSIS:
Loader Packaging: load.exe is a JavaScript application packaged with pkg (a Vercel tool that compiles Node.js apps into standalone binaries). The definitive evidence lies in the PDB path: C:\Users\runneradmin\AppData\Local\Temp\pkg.6709935bf6bb94abb8c538bc\node\out\Release\node.pdb. The “runneradmin” string indicates compilation via GitHub Actions (GitHub’s CI/CD service), meaning the build is automated.
The 53.5 MB binary contains the complete Node.js runtime (Google’s V8 engine, libuv for async I/O, OpenSSL for cryptography, zlib for compression, ICU for internationalization, llhttp for HTTP parsing) plus the malicious JavaScript code embedded in the binary and executed by the runtime.
Malware Evasion: This technique is increasingly common in modern malware because it complicates static analysis (the actual code is in JavaScript, not native code), the large size (53 MB) hinders uploads to sandboxes and analysis services, and the binary “appears” legitimate as it contains thousands of functions from well-known libraries.
load.exe imports 12 DLLs with over 500 functions, a much broader profile than chromelevator.exe, reflecting the Node.js runtime complexity. Beyond inherited Node.js functions, the following DLLs stand out for malicious activity relevance:
dbghelp.dll (13 functions): Includes MiniDumpWriteDump, enabling dumps of running processes. Sym* functions (SymSetOptions, SymSetSearchPathW, SymGetModuleBase64) are used for symbol resolution. This DLL gives the loader the ability to extract process memory, potentially capturing sensitive data not accessible via the file system.
WS2_32.dll (43 functions): Windows sockets library (Winsock2). The 43 imported functions provide complete low-level network capability, including TCP/UDP sockets, DNS, and async operations. Used by libuv (Node.js I/O library) for all network operations, including HTTP, WebSocket, and potentially direct C2 communication.
Public submissions identified on ANY.RUN confirmed network activity via WS2_32, recording TCP connections to IP 24.152.36.241 on port 8080 during dynamic loader execution, validating that these functions are effectively used for C2 communication and not just passively inherited from the Node.js runtime.
CRYPT32.dll (7 functions): Includes CertOpenStore, CertCloseStore, CertEnumCertificatesInStore, CertFindCertificateInStore, and CertDuplicateCertificateContext. These functions provide access to digital certificates and private keys stored in the Windows Certificate Store. They can be used to steal authentication certificates or manipulate TLS trust.
IPHLPAPI.DLL (8 functions): Network information functions such as GetBestRoute2, if_nametoindex, and NotifyIpInterfaceChange. Used for network reconnaissance and connectivity change detection.
KERNEL32.dll (279 functions): Includes critical attack functions: CreateRemoteThread and OpenProcess (standard API process injection), VirtualAlloc and VirtualProtect (memory manipulation), CreateNamedPipeW and ConnectNamedPipe (IPC), LoadLibraryA/W/ExW (dynamic loading), IsDebuggerPresent (anti-debug). Behavioral analysis in ANY.RUN public executions corroborated the CreateProcessW call in suspended state and subsequent injection via VirtualAllocEx/WriteProcessMemory into the browser process, confirming the loader uses both standard KERNEL32 API and direct syscalls resolved from ntdll.dll at runtime by the payload.
Cryptography Algorithm:
O payload utiliza criptografhy for two distinct purposes, both based on the SHA-256 via Windows CNG (bcrypt.dll).
1. Chave mestra (ASTER_KEY): The string “ASTER_KEY:” suggests a master key is provided as a parameter (possibly via –secret or embedded in the binary). “ASTER” may be an internal acronym or reference to a custom derivation scheme.
2. SHA-256 (CNG): BCryptOpenAlgorithmProvider is called with the “SHA256” identifier (confirmed via UTF-16 string). The master key is processed by BCryptHashData to generate a 32-byte digest.
3. Decryption: The resulting SHA-256 digest is used as a key to decrypt the payload in memory. The specific symmetric cipher algorithm is not identifiable through static analysis alone; it could be AES-256 (using the 32 bytes as a key), XOR with the hash, or a custom algorithm. The string “[+] Payload decrypted ( bytes)” confirms the success of the operation.
The “sig” field in the JSON sent to the C2 contains a SHA-256 hash functioning as an integrity signature. The probable process: ZIP data (before Base64 encoding) is hashed via BCryptHashData with SHA-256, and the resulting hex digest is included as “sig” in the JSON. The C2 can then verify data was transmitted without corruption.
TLS/SSL: Secure connections via SSL_CTX_*, SSL_connect, SSL_read, SSL_write. Can be used for encrypted C2 communication.
Random number generation: RAND_bytes, BCryptGenRandom (imported from bcrypt.dll) for nonce and session key generation.
Below is the comparison between Loader and final Payload
| Aspecto | chromelevator.exe | load.exe |
| Papel | Payload / worker | Loader / orquestrador |
| Linguagem | C++ nativo (MSVC) | JavaScript (Node.js via pkg) |
| Tamanho | 1.4 MB (cirúrgico) | 53.5 MB (runtime completo) |
| Subsystem | GUI (sem janela) | Console |
| Compilação | 21/04/2026 (mais recente) | 25/03/2026 (mais antigo) |
| DLLs importadas | 5 DLLs, 127 funções | 12 DLLs, 500+ funções |
| Onde roda | Injetado no processo do browser | Processo independente |
| Evasão | Syscalls diretas, sem PDB/metadata | Camuflado em binário Node.js |
| Metadados | Zero (stripped) | “Slinky Cracked” exposto |
| Comunicação C2 | WinHTTP (11 funcs) | WS2_32 + OpenSSL/TLS |
| Criptografia | bcrypt (SHA-256 CNG) | OpenSSL completo + bcrypt |
| Injeção | Syscalls diretas (ntdll runtime) | API padrão (CreateRemoteThread) |
| Persistência | Nenhuma (vive em memória) | Arquivo em disco |
PAYLOAD ANALYSIS – STAGE 2
The binary has the followinges compiler-enabled protections: HIGH_ENTROPY_VA (support for 64-bit ASLR with high entropy), DYNAMIC_BASE (ASLR, base address randomization), NX_COMPAT (DEP, data execution prevention), and TERMINAL_SERVER_AWARE. Notably, GUARD_CF (Control Flow Guard) is disabled, facilitating control flow exploitation.
Binary Structure: The binary has 6 sections. The .text section occupies 98.4% of the total file with an entropy of 7.84, which is extremely high. This entropy indicates compilation with LTCG (Link-Time Code Generation) combined with possible inline encrypted data, such as the injection payload and decryption keys. Detect It Easy (DiE) classified it as “[Heur] Compressed or packed data”; however, there is no classic packer, as the Raw/Virtual ratios are all close to 1.0.
chromelevator.exe imports only 5 DLLs with 127 functions, an extremely lean and surgical profile. Each DLL has a clear purpose in the attack cycle. Beyond statically imported DLLs, the binary loads ntdll.dll and mscoree.dll at runtime via LoadLibraryExW/GetProcAddress to resolve direct syscalls and check the .NET environment.
Imports – Functional Analysis:
A KERNEL32.dll provides the base functions used by the malware, covering multiple operation stages. It is used for process creation and control, including starting the browser suspended for injection, terminating existing processes, and managing timing.
It also enables internal communication (IPC) via Named Pipes between the payload and the main process. For data access, it allows file manipulation, reading browser databases (cookies, credentials) and organizing temporary directories. For injected code execution, it uses memory control (VirtualProtect), while more sensitive allocation functions are dynamically resolved via syscalls.
The malware employs dynamic API resolution (LoadLibrary/GetProcAddress) to avoid IAT exposure, hindering static analysis. It also includes anti-analysis mechanisms such as debugger detection and timing checks against sandboxes.
Finally, it performs system reconnaissance (hostname, time, environment variables) and encoding conversion (UTF-16 ↔ UTF-8) to structure and exfiltrate data to the C2.
WinHTTP is the Windows client HTTP library, used here for all communication with the C2 server. The 11 imported functions form the complete cycle of an HTTP request: WinHttpOpen initializes the HTTP session with the User-Agent “GrabBot/1.0”. WinHttpConnect establishes the connection with the C2 IP (24.152.36.241). WinHttpOpenRequest creates the POST request for the /upload endpoint. WinHttpAddRequestHeaders adds “Content-Type: application/json”. WinHttpSetOption configures options such as timeout and security flags. WinHttpSendRequest sends the request with the JSON body containing the stolen data in Base64. WinHttpReceiveResponse waits for the server response. WinHttpQueryHeaders and WinHttpQueryDataAvailable verify the HTTP status and response size. WinHttpReadData reads the response. WinHttpCloseHandle releases the resources.
WinHTTP is the Windows client HTTP library, used here for all communication with the C2 server. The 11 imported functions form the complete cycle of an HTTP request: WinHttpOpen initializes the HTTP session with the User-Agent “GrabBot/1.0”. WinHttpConnect establishes the connection with the C2 IP (24.152.36.241). WinHttpOpenRequest creates the POST request for the /upload endpoint. WinHttpAddRequestHeaders adds “Content-Type: application/json”. WinHttpSetOption configures options such as timeout and security flags. WinHttpSendRequest sends the request with the JSON body containing the stolen data in Base64. WinHttpReceiveResponse waits for the server response. WinHttpQueryHeaders and WinHttpQueryDataAvailable verify the HTTP status and response size. WinHttpReadData reads the response. WinHttpCloseHandle releases the resources.
A bcrypt.dll is the modern Windows cryptography API (CNG, Cryptography Next Generation). The 6 functions form a complete hashing pipeline:
BCryptOpenAlgorithmProvider opens the SHA-256 algorithm provider (identified via “SHA256” string in UTF-16). BCryptCreateHash creates a hash object. BCryptHashData feeds the data to be hashed. BCryptFinishHash finalizes and obtains the digest. BCryptDestroyHash and BCryptCloseAlgorithmProvider release resources.
This pipeline is used for two purposes: (1) runtime decryption key derivation (“Deriving runtime decryption keys…”) using SHA-256 to transform the master key (ASTER_KEY) into session keys, and (2) generation of the “sig” (signature) field in the exfiltration JSON, so the C2 can validate received data integrity.
RegOpenKeyExW open the regkeys to locate installed browsers, HKLM\SOFTWARE\Clients\StartMenuInternet\{browser}\shell\open\command to find the browser executable, and (2) HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{browser} to obtain the InstallLocation and verify browser presence. Both paths are queried in 64-bit root and WOW6432Node (32-bit). RegQueryValueExW reads key values. RegCloseKey closes handles.
GetFileVersionInfoSizeW, GetFileVersionInfoW e VerQueryValueW are used to read the version of found browser executables. This allows the malware to verify compatibility and select the correct extraction methods for each browser version.
O ntdll.dll does not appear in the binary’s IAT (Import Address Table); it is loaded at runtime via LoadLibraryExW and functions are resolved via GetProcAddress. This is a deliberate evasion technique to bypass EDR/antivirus hooks that monitor IAT functions.
The resolved ntdll.dll functions are low-level syscalls (kernel level) that execute process injection operations without going through KERNEL32.dll wrapper functions.
Strings and Functions:
Stracted Strings with Floss revealed 2,925 ASCII strings and 531 UTF-16LE strings. The categorization of the most relevant strings completely exposes the malware’s logic:
C2 Communication: The command and control server is hardcoded in the binary in UTF-16LE: 24.152.36.241. The endpoints are /upload (POST, for sending stolen data) and /time (GET, likely a keepalive or clock synchronization). The User-Agent used is “GrabBot/1.0” and the Content-Type is “application/json”.
Target Browsers and Registry Detection: The malware searches for 8 browsers through Windows registry queries. For each browser, StartMenuInternet keys (for the executable), Uninstall (for InstallLocation), and App Paths are queried, both in HKLM\SOFTWARE and HKLM\SOFTWARE\WOW6432Node:
| Browser | Executável | Pipe Pattern | Chave Uninstall | StartMenuInternet |
| Chrome | chrome.exe | chrome.sync.%u.%u.%04X | Google Chrome | Google Chrome |
| Chrome Beta | chrome.exe | chrome.nacl.%u_%04X | Google Chrome Beta | Google Chrome Beta |
| Edge | msedge.exe | msedge.sync.%u.%u | Microsoft Edge | Microsoft Edge |
| Brave | brave.exe | (via Chromium) | BraveSoftware Brave-Browser | Brave |
| Avast | AvastBrowser.exe | (via Chromium) | (não listado) | (não listado) |
| Opera | opera.exe | opera.sync.%u.%u.%04X | Opera Stable | Opera |
| Opera GX | opera.exe | opera.ipc.%u_%04X | Opera GX Stable | Opera GX |
| Firefox | xfirefox.exe | firefox.%u.%u | Mozilla Firefox | Firefox |
Stolen data and IPC Protocol: Data extracted from browsers is transmitted via named pipes using a simple text protocol with prefixes. Each data type is preceded by an uppercase marker followed by a colon:
COOKIES: <dados codificados>
Irocess Injection, Complete Sequence: The binary’s log messages reveal the exact process injection sequence, following the process hollowing pattern with direct syscalls
Compression and Exfiltration: After collection, data is compressed using PowerShell in hidden mode:
powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden
-Command “Compress-Archive -Path ‘…’ -DestinationPath ‘…'”
Generated files follow two naming patterns: .grab_<name>.zip and output_YYYYMMDD_HHMMSS.zip. After compression, the ZIP is Base64-encoded and sent to the C2 as part of a JSON payload.
JSON Exfiltration Payload
Reconstruction of string fragments reveals the complete JSON structure sent to the C2:
| Flag | Propósito |
| –verbose | Ativa modo verboso com todas as mensagens de log |
| –fingerprint | Coleta fingerprint do host (FINGERPRINT_TRUE/FINGERPRINT_FALSE) |
| –kill | Mata processos de browser antes da injeção |
| –secret | Chave de autenticação enviada ao C2 no campo “secret” |
| –output-path | Define caminho alternativo para os ZIPs gerados |
| –help | Exibe ajuda/uso |
C2 Infrastructure, LofyStealer Web Panel
C2 Investigation: The investigation of the C2 IP address (24.152.36.241) revealed a complete victim management web panel accessible on port 8080. The platform identifies itself as “LofyStealer, Advanced C2 Platform V2.0” and offers a graphical interface for operators to manage data theft campaigns in real time.
After authenticação, the operator is redirected to a dashbashboard with campaign overview:
the subtitle “Manage your account and monitor victims”, the “Recent Victims” panel with status “No victims yet, Waiting for connections…”, and account info in the side card (User, Type: Free, Total victims: 0, Online now: 0).
The “Quick Actions” section presents four buttons: Panel (victim monitoring), My Profile (settings), Premium (plan upgrade), and Builder (executable generator). The “Refresh” button in the victims panel indicates real-time monitoring of compromised machines.
Based on screenshot analysis and behavior observed, the C2 panel architecture can be described:
Frontend: SPA (Single Page Application) web application served as a JavaScript bundle. The interface uses a dark theme with purple/gold palette, modern UI components with particle animations, and responsive design.
Backend: Node.js serving on port 8080 at IP 24.152.36.241. The same server receiving exfiltrated data on /upload (POST) and /time (GET) endpoints also serves the management web panel.
Business model: MaaS (Malware-as-a-Service) with two tiers — Free (limited access, no builder or victim panel) and Premium (full access via activation key). Multi-operator, each operator having their own account and secret key linked to generated executables.
| Endpoint | Método | Função |
| / (porta 8080) | GET | Landing page — LofyStealer V2.0 |
| /?role=client | GET | Dashboard do operador (autenticado) |
| /upload | POST | Recebimento de dados exfiltrados (JSON/Base64) |
| /time | GET | Keepalive / sincronização de relógio |
IOC’s
| Arquivo | Algoritmo | Hash |
| chromelevator.exe | MD5 | d21a5d08b4614005c8fcd9d0068f0190 |
| SHA1 | 9b1264eb4ff5ee8f00b8b80341fb6917dc3d3148 | |
| SHA256 | 293006cec43c663ccff331795d662c3b73b4d7af5f8584e2899e286c672c9881 | |
| load.exe | MD5 | fb203c0ac030a97281960d7c28d86ebf |
| SHA1 | f9fe23f24d45eae418c60819c523a83ddba4ca50 | |
| SHA256 | 45d4040e76a0d357dd6e236e185aba2eb82420d78640bfd1f3dede32b33931f7 |
| Indicador | Valor |
| IP do C2 | 24.152.36.241 |
| Endpoint de upload | /upload (HTTP POST) |
| Endpoint de tempo | /time (HTTP GET) |
| User-Agent | GrabBot/1.0 |
| Content-Type | application/json |
| Protocolo fallback | WebSocket |
| Painel C2 | http://24.152.36.241:8080 (LofyStealer V2.0) |
| Nome da plataforma | LofyStealer — Advanced C2 Platform V2.0 |
| String | Contexto |
| [chromelevator] | Tag de identificação do payload |
| __DLL_PIPE_COMPLETION_SIGNAL__ | Sinal IPC de conclusão |
| GrabBot/1.0 | User-Agent HTTP do C2 |
| Slinky Cracked | Nome do builder (VersionInfo do loader) |
| ASTER_KEY: | Prefixo de chave de criptografia |
| FINGERPRINT_TRUE / FINGERPRINT_FALSE | Flags de fingerprinting do host |
| Deriving runtime decryption keys… | Log de descriptografia do payload |
| LofyStealer | Nome da plataforma C2 (landing page) |
MITRE ATT&CK
| Técnica | Nome | Evidência | Binário |
| T1055.012 | Process Injection: Process Hollowing | Criação de processo suspenso + injeção de payload | chromelevator |
| T1055.003 | Process Injection: Thread Execution Hijacking | Criação de thread remota via syscall direta | chromelevator |
| T1106 | Native API | Uso de syscalls diretas de ntdll.dll em runtime | chromelevator |
| T1539 | Steal Web Session Cookie | Extração de cookies de 8 browsers | chromelevator |
| T1555.003 | Credentials from Web Browsers | Extração de senhas armazenadas | chromelevator |
| T1012 | Query Registry | Consulta ao registro para localizar browsers | chromelevator |
| T1082 | System Information Discovery | Coleta de hostname e fingerprint do host | chromelevator |
| T1057 | Process Discovery | Detecção de processos de browser em execução | load.exe |
| T1059.001 | Command and Scripting: PowerShell | Compressão via Compress-Archive oculto | chromelevator |
| T1560.001 | Archive Collected Data: Archive via Utility | Compressão ZIP dos dados roubados | chromelevator |
| T1132.001 | Data Encoding: Standard Encoding | Codificação Base64 do ZIP para exfiltração | chromelevator |
| T1041 | Exfiltration Over C2 Channel | Envio dos dados via HTTP POST ao C2 | ambos |
| T1071.001 | Application Layer Protocol: Web Protocols | Comunicação C2 via HTTP/JSON | ambos |
| T1562.001 | Impair Defenses: Disable or Modify Tools | Terminação de processos de browser (–kill) | chromelevator |
| T1027 | Obfuscated Files or Information | Payload criptografado, descriptografado em runtime | chromelevator |
| T1497.003 | Virtualization/Sandbox Evasion: Time Based | Timing checks via GetTickCount/QPC | chromelevator |
Conclusion
ANY.RUN Contribution: The ANY.RUN platform was essential in this investigation, enabling artifact identification in public submissions during threat hunting and confirming the campaign is active in real environments. Dynamic sandbox execution data validated static analysis hypotheses — C2 connections, process injection, and PowerShell exfiltration — consolidating the platform as an indispensable resource for threat intelligence teams.
Static analysis of chromelevator.exe and load.exe confirms this is a sophisticated, modular infostealer operating under the identity “GrabBot/1.0”, built with the “Slinky Cracked” builder. The two components demonstrate a clear division of responsibilities reflecting design maturity:
Modularity: The loader (Node.js/JavaScript) is responsible for orchestration, while the payload (native C++) performs sensitive data extraction operations. This separation allows the authors to update the payload independently of the loader, as evidenced by the 27-day difference in compilation dates.
Advanced evasion: The use of direct syscalls (ntdll.dll resolved at runtime) for process injection bypasses EDR/antivirus hooks that only monitor high-level KERNEL32.dll functions. The payload has no identifiable metadata (PDB, VersionInfo, resources) and operates exclusively in memory after injection.
Camouflage via pkg: The use of Node.js packaged via pkg for the loader is a growing technique in the threat landscape. The 53 MB binary hinders sandbox analysis, and ~3000 legitimate Node.js/V8/OpenSSL exports dilute malicious indicators. Automated GitHub Actions build indicates a professionalized production chain.
Resilient exfiltration: The exfiltration mechanism with WebSocket fallback, SHA-256 integrity signature, and “secret” authentication demonstrates concern for C2 communication reliability and security.
Theft scope: The malware targets 8 different browsers and extracts 5 categories of sensitive data (cookies, passwords, tokens, cards, IBANs), covering both access credentials and direct financial data.
Dynamic analysis (sandboxing, debugging, network monitoring) would be necessary to confirm behaviors such as: the exact symmetric encryption algorithm used in payload decryption, the complete structure of the loader’s JavaScript code, possible persistence mechanisms not identified by static analysis, and specific WebSocket fallback behavior.
