Detection Guide: Vidar Malware (Infostealer)
Behavioral Indicators
Vidar exhibits several runtime behaviors that can indicate its execution on a system. Monitor for processes that spawn from suspicious parent processes, particularly those launched from temporary directories or user profile paths. Vidar often creates child processes to perform its data theft functions, such as launching web browsers in a controlled manner to extract credentials and cookies. Look for processes making unusual API calls related to credential access, including calls to credential management APIs, browser data directory access, and cryptocurrency wallet file queries.
The malware typically accesses browser profile directories (like those for Chrome, Firefox, Edge, and Opera) to copy login data, cookies, and autofill information. It may also query the Windows Credential Manager and access files related to installed applications like FTP clients, messaging apps, and email clients. Monitor for processes that read from multiple user data directories in quick succession, a pattern consistent with credential harvesting. Vidar may also disable security software or tamper with Windows Defender settings using registry modification or service stop commands. Process hollowing or injection into legitimate system processes is another common technique to evade detection while performing malicious activities.
Network Indicators
Vidar communicates with command-and-control (C2) servers using HTTP and HTTPS protocols. The malware typically beacons to its C2 at regular intervals, often between 5 to 30 minutes, though this can vary between campaigns. Beaconing requests usually contain encoded or encrypted data in POST requests, with the C2 address embedded within the malware binary or retrieved from a configuration file. DNS queries may resolve to domains with random or dictionary-based subdomains, often using domain generation algorithms (DGAs) in newer variants.
Exfiltration traffic typically occurs after data collection, with stolen information compressed and transmitted to the C2 server. Look for HTTP POST requests containing base64-encoded data, ZIP archives, or custom binary formats sent to suspicious domains. The User-Agent strings in these requests may be generic (like mimicking legitimate browsers) or may contain specific identifiers unique to the Vidar campaign. SSL/TLS certificates used by C2 servers may be self-signed or issued by non-trusted certificate authorities. Network monitoring should focus on outbound connections to IP addresses or domains with low reputation scores, especially those hosted in bulletproof hosting services or recently registered domains.
File System Artifacts
Vidar drops several files during execution, primarily in user-writable directories. Common locations include:
- %APPDATA%[random folder name]\
- %LOCALAPPDATA%[random folder name]\
- %TEMP%[random folder name]\
- C:\Users[username]\Downloads\
The malware executable often uses deceptive names mimicking legitimate software, such as “update.exe”, “installer.exe”, “chrome_update.exe”, or document names like “invoice.pdf.exe”. Dropped files may include configuration files (often with .dat, .cfg, or .ini extensions) containing C2 addresses and operational parameters. Vidar creates log files documenting stolen data, typically with names like “logs.dat”, “system.txt”, or timestamp-based filenames. These logs are usually stored in the same directory as the main executable or in a subdirectory.
Temporary files created during execution include browser data copies, compressed archives of stolen information, and decoy documents used in phishing campaigns. File sizes vary but the main executable typically ranges from 200KB to 2MB. Timestamps may be manipulated to appear legitimate, but creation times often cluster around initial infection time. Look for recently created executable files in user profile directories with compilation timestamps that don’t match their file system timestamps.
Registry and Persistence Mechanisms
Vidar employs multiple persistence mechanisms to maintain access to infected systems. Common registry modifications include:
- Adding entries to HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- Adding entries to HKLM\Software\Microsoft\Windows\CurrentVersion\Run
- Modifying HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
- Creating entries under HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
The malware often creates scheduled tasks for persistence, with task names that blend with legitimate system tasks. Common naming conventions include “GoogleUpdateTask”, “OneDriveStandaloneUpdateTask”, or “MicrosoftEdgeUpdateTask”. These tasks are configured to execute the malware at system startup or at regular intervals. Vidar may also create services for persistence, particularly on systems where it has administrative privileges. Service names often mimic legitimate Windows services with slight variations.
Other persistence techniques include browser extension installation, startup folder shortcuts (in %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup), and file association hijacking. Some variants modify the registry to disable Windows security features, such as turning off Windows Defender real-time protection or adding exclusions for its installation directory. Registry keys related to User Account Control (UAC) may also be modified to reduce security prompts.
YARA Rule Guidance
When creating YARA rules for Vidar detection, focus on both string-based and structural characteristics. Target unique strings found in Vidar samples, including:
- Hardcoded C2 domains or IP addresses (often in plaintext or simple obfuscation)
- Path strings referencing specific browser data locations
- Error messages and logging strings used by the malware
- API function names related to credential theft and data collection
- Mutex names with specific patterns (often containing “vidar”, “global”, or random alphanumeric strings)
Look for byte patterns related to Vidar’s encryption routines, which often use XOR with single-byte keys or simple substitution ciphers for configuration data. The malware typically contains resources or embedded data sections with configuration information, including C2 addresses, campaign identifiers, and collection parameters. Pay attention to the import address table (IAT) for suspicious API combinations, particularly those related to credential access, process injection, and persistence establishment.
Structural characteristics include specific section names, entry point code patterns, and packing signatures. Many Vidar samples use common packers or crypters, so rules should target both packed and unpacked variants. Consider creating rules that detect the malware’s configuration structure, which often follows a specific format with field delimiters like pipes (|) or colons (:). Memory artifacts during execution can also be targeted, including specific heap allocations or process memory patterns associated with Vidar’s data collection modules.
For the latest samples, IOCs, and comprehensive overview of Vidar malware, refer to: