Engineering Insights into Information Stealers

May 28, 2024

In December of 2023, DarkOwl analysts released a blog answering the burning question of “What are Stealer Logs”. In another piece, DarkOwl analysts presented an overview of the different types of Information Stealers (Info Stealers) that are sold on the Darknet.

Now, DarkOwl would like to shed some insight into info stealers from an engineering perspective, to further explore the functionality, specific behaviors, and technical characteristics of this sophisticated form of credential theft.

Info Stealers infiltrate systems and compromise data primarily through social engineering attacks. Common tactics include but are not limited to:

Phishing Emails
Malicious Websites
Exploiting Software Vulnerabilities
Remote Access Trojans (RATs)
Removable Media Attacks
Drive-by-Downloads

Info stealers are very sophisticated forms of malware, and the complexity of the modular architecture allows them to often go undetected even by anti-virus software. While each type of info stealer does vary in its level of refinement, as they are still relatively new but rapidly evolving, this review will be focused on generalizing key elements commonly found in info stealers. Info stealers are known for their evasion techniques and for targeting what people want to protect, their private information, credentials, and financial data.

Info Stealers

Part of what makes info stealers so sophisticated are their complex modular architecture. A simplified overview of that architecture includes the following key elements:

Core Engine Module
Communication Module
Data Collection Module
Encryption Module
Exfiltration Module
Evasion Module

To understand what each of these modules are and their functionality within a stealer log we will review each term and look at a very basic version of the complex code that is used to design an Information Stealer.

Core Engine Module

This serves as the central intelligence hub of the info stealer and manages its functionality. The core engine drives tasks such as initialization and configuration of all the other modules coordinating their actions. It also initializes the malware, establishes communication with the command control (C2) server and houses the execution codes for the other five modules.

Below is a basic sample of what part of the code for a Core Engine could look like:

Keylogger – provides a basic framework for logging keystrokes
log_keystroke – this captures and logs keystrokes
save_logs – method used to save and send the logged keystrokes to a remote server
start_logging – acts as a place holder for when to start the keylogging process

Communication Module

This establishes and maintains communication with the C2 server, handles sending/receiving commands, transmission of stolen data, and maintains a covert channel of communications. Generally, this module will have some form of encryption in place to prevent the interception of the data that is being stolen as well as protecting the location of where the stolen data is being sent.

Below is a basic Communication Module code to demonstrate part of the module’s functionality:

request – this library is used to send a HTTP request to the C2 server
send_request – sends what is called a POST request to the C2 servers URL which generates a JSON response
handshake – initiates communication with the C2 server and contains information about malware versions, system architecture and contains the installation ID
execute_command – simulates the execution commands from the C2 server
exfiltrate_data – simulates the exfiltration of the stolen data

Data Collections Module

The responsibility of this module is to identify and harvest the data the threat actor is after once the system has been infected. The Data Collections Module can house a large array of submodules for specific forms of data the threat actor wants to collect. Common forms of data such as PII, financial data, device information, Geo locations, and personal photos would all require their own submodule to identify. In addition to the targeted data, the Data Collections Module also collects from numerus other sources such as browsers, system files, and apps installed on the device.

Below is a basic example to demonstrate the structure and functionality of Data Collections Module often found in info stealers:

keystroklogger – mentioned above in the core engine module
NetworkMonitor – captures network traffic (a placeholder) and sends it to a remote server.
DataExfiltration – mentioned above in the core engine module
If _ _name_ _ == “_ _main_ _”: – this creates a block instance of the three submodules are created, and separate threads are started to run their respective functions concurrently

Encryption Module

This provides cryptographic functionality and encryption keys used to communicate with the C2 server. As ironic as it seems the use of strong encryption algorithms (AES) is used to prevent interception of “unauthorized” access to the data that is currently being stolen. Only instead of protecting the device owner from the threat actor it is protecting the threat actor from the device owner, authorities, and aids in keeping the info stealer from malware detection.

Below is an example of one type of AES often used in info stealers:

EncryptionModule – methods for encrypting/decrypting data with the use of the AES algorithm
encrypt_data – imports plaintext data, encrypts it using AES, and outputs encrypted data as a “base64” encoding string
decrypt_data – does the reverse action of “encrypt_data”
if _ _name_ _== “_ _main_ _”: – generates a random encryption key

Exfiltration Module

This module handles the transmission of the stolen data once it has been encrypted. Exfiltration module formats the encrypted data into messages and sends them through the communications channel established by the communications module. This module often includes contingencies for when there are network interruptions, failed transmissions, and bandwidth issues.

Below is an example of the type of code that could be used in the Exfiltration Module:

ExfiltrationModule – this is a class that will provide a method to send the stolen data to the remote server
send_data – takes the stolen data as an input and sends it to the designated server URL
if _ _name_ _== “_ _main_ _”: – creates and instance of the exfiltration module with the URL of the remote server
data_to_exfiltrate – stolen data is sent to the remote server

Evasion Module

Just as it sounds this final module is responsible for the evasion tactics to evade malware detection by software and humans. Some common evasion techniques include polymorphism, obfuscation, and anti-debugging to hide the malware. This module acts as a chameleon as it continually adapts and evolves to remain under the radar. This is a highly scalable and adaptable to the various environments and target systems but below is a simple example of what the code could look like.

EvasionModule – defines the methods for simulating normal user activity while detecting virtualization/sandboxing and analysis tools
simulate_normal_activity – mimics typical user behavior, by opening files, browsing websites, or launching apps to hide amongst legitimate activity
detect_virtualization AND detect_analysis_tools – check for signs of virtualization/sandboxing and the presence of analysis tools
evade_detection – continuously runs evasion checks
if _ _name_ _== “_ _main_ _”: – the EvasionModule class is created, and the evade_detection method is called to start the evasion process.

There is no doubt about it, information stealers are a formidable threat to cybersecurity on multiple levels. Info Stealers are sophisticatedly engineered to stealthily execute malicious intent. By studying the architecture, functionality, and technical characteristics through an engineering perspective, cybersecurity analysts can gain a deeper understanding of how to create effective countermeasures and create robust detection strategies.