Article Banner

VoidLink: Detecting Advanced Cloud-Native Linux Malware

While most security teams focus on traditional endpoint threats, a sophisticated modular malware framework called VoidLink is built for modern cloud and container environments. Unlike generic Linux malware, VoidLink targets infrastructure managed by software engineers and cloud administrators, using advanced evasion techniques tailored to cloud security products.

Think of VoidLink as a Swiss Army knife optimized for penetrating a bank's vault rather than a burglar's crowbar. It includes cloud-specific reconnaissance tools, container-escape mechanisms, rootkit options, and credential-harvesting tools designed for AWS, Azure, GCP, and Kubernetes environments. Organizations relying on traditional endpoint defenses without cloud-native visibility may never detect its presence.

The framework's impact extends beyond immediate compromise. VoidLink provides long-term persistence mechanisms, multi-protocol command-and-control, and anti-forensics capabilities. This enables attackers to maintain access while harvesting credentials, exfiltrating data, and moving laterally across cloud infrastructure. For organizations managing software development environments, Git repositories, and cloud credentials, the risk is substantial: compromised developer machines can serve as gateways to entire cloud ecosystems and supply chain assets.

Hunting Controls & Observations

Organizations can detect VoidLink through multiple telemetry sources:

  • Endpoint Controls: EDR/XDR platforms with kernel-level visibility, Linux auditd logs, LD_PRELOAD monitoring, eBPF program tracking, LKM integrity monitoring, process memory scanning
  • Network Controls: Firewall logs, DNS query logs, SSL/TLS inspection for obfuscated C2 communications, ICMP traffic analysis, NetFlow data for peer-to-peer mesh networking patterns
  • Identity & Access Controls: SSH authentication logs, failed authentication monitoring, keyring access auditing, shadow file access logs, Git credential harvesting detection
  • Cloud & SaaS Controls: AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log, cloud metadata service access logs (169.254.169.254), Kubernetes API audit logs, Docker runtime security monitoring

Behavioral Indicators of Attack

  • Direct Syscall Patterns Bypassing libc (Endpoint): VoidLink executes system calls directly without using standard C library functions, a technique used to bypass userland security hooks installed by EDR products. This behavior appears as syscall instructions in memory regions not associated with libc.
  • Adaptive Stealth Behavior Based on Security Posture (Endpoint): The malware enumerates installed security products, assigns risk scores, and dynamically modifies its behavior based on perceived monitoring levels. Observable as sequential queries for security software processes followed by changes in C2 communication patterns or encryption cycles.
  • Cloud Metadata Service Reconnaissance (Cloud): Automated queries to cloud provider metadata APIs (169.254.169.254) targeting AWS, GCP, Azure, Alibaba, and Tencent Cloud platforms. Suspicious when originating from unexpected processes or with unusual user agents.
  • Version-Specific Rootkit Deployment (Endpoint): Kernel version enumeration followed by deployment of different persistence mechanisms—LD_PRELOAD manipulation for kernels <4.0, loadable kernel modules for 4.0-5.4, or eBPF programs for ≥5.5. Observable through system calls querying kernel version immediately before persistence installation.
  • Runtime Code Encryption and Decryption Cycles (Endpoint): Periodic encryption and decryption of code regions in memory to evade signature-based detection. Appears as repeated memory protection changes (mprotect syscalls) for the same memory regions combined with unusual entropy patterns.
  • SSH Lateral Movement with Automated Credential Harvesting (Network/Identity): The SSH worm module harvests SSH private keys and known_hosts files, then attempts automated connections to discovered hosts. Observable as SSH connections to multiple internal hosts from a single source, combined with SSH key file access.
  • Container Escape Attempt Patterns (Cloud/Endpoint): Exploitation of container runtime vulnerabilities or misconfigurations to escape to the host system. Observable through attempts to mount host filesystems, access Docker socket, or exploit kernel vulnerabilities like Dirty Pipe from within containers.
  • Selective Log Tampering with Keyword Filtering (Endpoint): Rather than clearing entire logs, VoidLink removes specific log entries containing keywords associated with its activity. Observable as log file modifications without corresponding logrotate operations, or gaps in log sequence numbers during suspicious activity windows.

MITRE Enterprise ATT&CK Tactics and Techniques

VoidLink's methodology aligns with MITRE ATT&CK Enterprise tactics across the entire kill chain:

  • Initial Access (T1195 – Supply Chain Compromise): VoidLink appears designed to target software developers and development infrastructure, potentially enabling supply chain attacks. The framework's focus on Git credential harvesting and development environment persistence suggests pre-positioning for downstream compromise.
  • Execution (T1059 – Command and Scripting Interpreter): Multiple shell execution plugins enable command execution across compromised systems. The framework's plugin architecture supports dynamic command execution without writing files to disk.
  • Execution (T1106 – Native API): VoidLink performs direct syscall operations to bypass userland security hooks. This technique circumvents EDR products that rely on libc function interposition.
  • Persistence (T1547.006 – Boot or Logon Autostart Execution: LD_PRELOAD): The framework abuses the LD_PRELOAD environment variable to inject malicious libraries into the dynamic linking process. This technique provides persistence and enables hooking of standard library functions for stealth.
  • Persistence (T1547.015 – Boot or Logon Autostart Execution: Systemd Service): VoidLink establishes persistence through systemd service creation. The malware creates legitimate-appearing service definitions that launch on system boot.
  • Persistence (T1053.003 – Scheduled Task/Job: Cron): The cron_persist module installs cron jobs for periodic execution. This provides redundant persistence alongside systemd services.
  • Privilege Escalation (T1611 – Escape to Host): VoidLink includes Docker escape capabilities targeting container runtime vulnerabilities. Successful container escape grants host-level access from containerized compromises.
  • Privilege Escalation (T1068 – Exploitation for Privilege Escalation): The framework includes exploit modules such as Dirty Pipe for kernel exploitation. These exploits enable escalation from unprivileged to root access.
  • Defense Evasion (T1014 – Rootkit): VoidLink deploys kernel-version-specific rootkits (LD_PRELOAD, LKM, eBPF) to hide processes, files, and network connections. The adaptive rootkit selection based on kernel version demonstrates sophisticated evasion planning.
  • Defense Evasion (T1027 – Obfuscated Files or Information): The framework employs runtime code encryption with periodic re-encryption cycles. This self-modifying code technique evades signature-based detection and memory scanning.
  • Defense Evasion (T1140 – Deobfuscation/Decode Files or Information): VoidLink decrypts code segments on-demand for execution, then re-encrypts them. This minimizes the window of clear-text malicious code in memory.
  • Defense Evasion (T1070.001 – Indicator Removal: Clear Command History): The history_wipe module removes command history files to hinder forensic investigation. This anti-forensic capability complements the selective log tampering functionality.
  • Defense Evasion (T1070.004 – Indicator Removal: File Deletion): The log_wiper module performs keyword-based log entry removal and file timestomping. This selective approach is stealthier than mass log deletion.
  • Defense Evasion (T1480 – Execution Guardrails): VoidLink enumerates security products, assigns risk scores, and modifies behavior based on defensive posture. This environment-aware evasion represents sophisticated operational security.
  • Credential Access (T1555 – Credentials from Password Stores): Multiple modules target credential stores including browser credential databases, system keyrings, and password managers. This comprehensive credential harvesting enables lateral movement and persistence.
  • Credential Access (T1003.008 – OS Credential Dumping: /etc/passwd and /etc/shadow): The passwd_dump module extracts password hashes from Linux authentication files. Combined with offline cracking, this enables authentication to other systems.
  • Credential Access (T1552.004 – Unsecured Credentials: Private Keys): The ssh_harvester module specifically targets SSH private keys and Git credentials. Harvested keys enable authenticated lateral movement without triggering authentication failures.
  • Discovery (T1526 – Cloud Service Discovery): VoidLink includes specialized reconnaissance for AWS, GCP, Azure, Alibaba Cloud, and Tencent Cloud. The framework queries cloud metadata services to identify the hosting environment and available resources.
  • Discovery (T1613 – Container and Resource Discovery): Dedicated modules enumerate Kubernetes clusters and Docker containers. This reconnaissance enables targeted container escape and lateral movement within orchestrated environments.
  • Discovery (T1082 – System Information Discovery): The sys_info module collects comprehensive system information including kernel version, installed packages, and running services. This reconnaissance informs adaptive evasion technique selection.
  • Lateral Movement (T1570 – Lateral Tool Transfer): The SSH worm functionality automatically propagates to systems in harvested known_hosts files. This autonomous lateral movement can rapidly expand the compromise footprint.
  • Lateral Movement (T1021.004 – Remote Services: SSH): VoidLink uses harvested SSH credentials and keys to authenticate to additional systems. The framework establishes SSH tunnels for network pivoting and C2 communications.
  • Collection (T1557 – Adversary-in-the-Middle): Browser credential harvesting capabilities enable man-in-the-browser attacks. This technique captures credentials even from systems with full disk encryption.
  • Collection (T1115 – Clipboard Data): The framework monitors clipboard contents for sensitive information like passwords, API keys, and authentication tokens. Captured clipboard data often contains credentials users copy-paste between systems.
  • Command and Control (T1071 – Application Layer Protocol): VoidLink supports multiple C2 protocols (HTTP/1.1, HTTP/2, WebSocket) with traffic obfuscation resembling legitimate formats. HTTP requests are camouflaged to appear as JSON, CSS, or PNG traffic.
  • Command and Control (T1095 – Non-Application Layer Protocol): The framework implements ICMP tunneling for C2 communication in environments where outbound traffic is restricted. This enables command-and-control even through restrictive firewalls.
  • Exfiltration (T1041 – Exfiltration Over C2 Channel): Stolen data is exfiltrated through the established C2 channels using the same obfuscated protocols. This blends exfiltration traffic with normal C2 communications.

Controls' Observables

Endpoint Controls

Endpoint detection and response platforms with kernel-level visibility can identify VoidLink through multiple behavioral signatures:

  • Direct Syscall Execution Patterns: Monitor for syscall instructions originating from memory regions outside standard libraries, particularly in processes without corresponding libc calls. (Related MITRE Techniques: T1106, T1027 | Detection Difficulty: MEDIUM)
  • LD_PRELOAD Environment Variable Manipulation: Alert on modifications to LD_PRELOAD settings, particularly in systemd service files or shell profiles, combined with loading of unsigned or unusual shared libraries. (Related MITRE Techniques: T1547.006, T1014 | Detection Difficulty: LOW)
  • Kernel Module or eBPF Program Loading: Detect loading of unsigned kernel modules (insmod/modprobe) or eBPF program attachment, especially on production systems where dynamic kernel modifications are uncommon. (Related MITRE Techniques: T1014, T1547.014 | Detection Difficulty: LOW)
  • Runtime Code Encryption Cycles: Identify processes with repeated memory protection changes (mprotect syscalls) affecting the same memory regions, combined with high entropy regions suggesting encrypted code. (Related MITRE Techniques: T1027, T1140 | Detection Difficulty: HIGH)
  • Security Product Enumeration Sequences: Alert on processes sequentially querying for multiple security product processes (ps, /proc enumeration) combined with subsequent behavior changes or network activity. (Related MITRE Techniques: T1480, T1518.001 | Detection Difficulty: MEDIUM)
  • Selective Log File Modifications: Monitor for log file writes not originating from logging daemons, or log file modifications during suspicious activity without corresponding logrotate operations. (Related MITRE Techniques: T1070.001, T1070.004 | Detection Difficulty: MEDIUM)
  • SSH Private Key and Git Credential Access: Alert on processes reading SSH private keys (~/.ssh/id_*) or Git credential files outside of normal SSH client or Git execution contexts. (Related MITRE Techniques: T1552.004, T1555 | Detection Difficulty: LOW)

Network Controls

Network monitoring systems can detect VoidLink's command-and-control and lateral movement activities:

  • Obfuscated HTTP Traffic Patterns: Identify HTTP requests with unusual content types or bodies containing high-entropy data masquerading as JSON, CSS, or image formats. Look for HTTP/2 connections to non-standard ports. (Related MITRE Techniques: T1071, T1001 | Detection Difficulty: MEDIUM)
  • ICMP Tunneling Activity: Alert on ICMP traffic with unusual payload sizes, non-standard sequence patterns, or high volume between internal hosts, suggesting covert channel usage. (Related MITRE Techniques: T1095 | Detection Difficulty: LOW)
  • DNS Tunneling Indicators: Monitor for excessive DNS query volumes to single domains, unusually long DNS query names, or queries containing high-entropy subdomains suggesting data encoding. (Related MITRE Techniques: T1071.004 | Detection Difficulty: MEDIUM)
  • Automated SSH Lateral Movement: Detect SSH connections from single sources to multiple internal destinations within short time periods, especially when combined with SSH key file access. (Related MITRE Techniques: T1021.004, T1570 | Detection Difficulty: LOW)
  • Peer-to-Peer Mesh Networking: Identify unusual direct connections between systems that normally don't communicate, particularly on non-standard ports suggesting mesh C2 architecture. (Related MITRE Techniques: T1071 | Detection Difficulty: MEDIUM)

Cloud & SaaS Controls

Cloud platform monitoring can detect VoidLink's cloud-native reconnaissance and attack techniques:

  • Cloud Metadata Service Reconnaissance: Alert on unusual processes accessing cloud metadata endpoints (169.254.169.254), particularly from application containers or with non-standard user agents. (Related MITRE Techniques: T1526, T1552.005 | Detection Difficulty: LOW)
  • Kubernetes API Abuse: Monitor for unusual Kubernetes API calls, particularly privilege escalation attempts (pod creation with hostPath volumes), service account token access, or secret enumeration from unexpected sources. (Related MITRE Techniques: T1613, T1611 | Detection Difficulty: MEDIUM)
  • Container Escape Attempts: Detect suspicious activities from containers including attempts to mount host filesystems, access Docker socket, or exploit kernel vulnerabilities through unusual syscall patterns. (Related MITRE Techniques: T1611, T1068 | Detection Difficulty: MEDIUM)
  • Abnormal Cloud API Activity: Alert on CloudTrail/Cloud Audit events showing reconnaissance patterns—rapid enumeration of resources across services, IAM role assumption from unusual sources, or infrastructure discovery from compromised instances. (Related MITRE Techniques: T1526, T1580 | Detection Difficulty: LOW)

Identity & Access Controls

Identity and authentication monitoring can detect VoidLink's credential harvesting and abuse:

  • Password File Access Anomalies: Alert on processes reading /etc/shadow or equivalent authentication files outside of legitimate administrative tools or package management operations. (Related MITRE Techniques: T1003.008 | Detection Difficulty: LOW)
  • Keyring and Credential Store Access: Monitor for unusual processes accessing system keyrings (libsecret), browser credential databases, or password manager files. (Related MITRE Techniques: T1555, T1539 | Detection Difficulty: MEDIUM)
  • Multiple Failed SSH Attempts Followed by Success: Detect SSH authentication patterns showing multiple failures (potentially brute force or credential testing) followed by successful authentication, suggesting compromised credentials. (Related MITRE Techniques: T1110 | Detection Difficulty: LOW)

Insights and Recommendation

Successful VoidLink compromise in a software development environment creates cascading organizational risk. Attackers gain persistent access to developer machines containing Git credentials, SSH keys, and cloud access tokens—enabling unauthorized commits to source code repositories, deployment of malicious infrastructure as code, and supply chain compromise affecting downstream customers. The framework's anti-forensics capabilities and long-term persistence mechanisms mean compromise may exist undetected for months while attackers systematically harvest credentials and establish infrastructure footholds.

Organizations should prioritize establishing cloud-native security visibility through Kubernetes audit logging, container runtime monitoring, and cloud provider audit log aggregation. Implement behavioral analysis for credential access patterns targeting SSH keys, Git repositories, and cloud APIs. Deploy kernel integrity monitoring and rootkit detection capabilities specifically for Linux infrastructure. Finally, establish baseline behavior for cloud API consumption and network communication patterns to identify VoidLink's adaptive command-and-control and metadata service reconnaissance activities. These capabilities require deeper cloud infrastructure instrumentation than traditional endpoint-focused security programs typically provide.

Source and Credits

This summary is based on Check Point Research's threat analysis article "VoidLink: The Cloud-Native Malware Framework" published in January 2026. Check Point Research's detailed analysis of VoidLink's modular architecture, cloud detection capabilities, and sophisticated evasion mechanisms provides foundational threat intelligence for this hunting guide.

Threat Hunting IOCs & Queries

The following section contains known Indicators of Compromise (IOCs) identified in Check Point Research's VoidLink analysis, along with Microsoft Defender (KQL) and Splunk queries designed to detect VoidLink deployment, persistence mechanisms, credential harvesting, and command-and-control activities. These queries translate behavioral indicators and IOCs into actionable detection logic. Note that queries have been created with AI assistance and should be validated against your environment's data schemas and baseline behaviors before production deployment.

Known Indicators of Compromise

  • File Hashes (SHA256): Stage 0 Loader: 70aa5b3516d331e9d1876f3b8994fc8c18e2b1b9f15096e6c790de8cdadb3fc9;
    Stage 1 Loader: 13025f83ee515b299632d267f94b37c71115b22447a0425ac7baed4bf60b95cd;
    VoidLink Implants: 05eac3663d47a29da0d32f67e10d161f831138e10958dcd88b9dc97038948f69, 15cb93d38b0a4bd931434a501d8308739326ce482da5158eb657b0af0fa7ba49, 6850788b9c76042e0e29a318f65fceb574083ed3ec39a34bc64a1292f4586b41, 6dcfe9f66d3aef1efd7007c588a59f69e5cd61b7a8eca1fb89a84b8ccef13a2b, 28c4a4df27f7ce8ced69476cc7923cf56625928a7b4530bc7b484eec67fe3943, e990a39e479e0750d2320735444b6c86cc26822d86a40d37d6e163d0fe058896, 4c4201cc1278da615bacf48deef461bf26c343f8cbb2d8596788b41829a39f3f
  • IP Addresses: No public command-and-control IP addresses confirmed as of source publication date. Check Point Research noted that VoidLink may use fast-flux infrastructure or residential proxy networks to evade IP-based blocking.
  • Domains: No public C2 domains or registrar information available. VoidLink's traffic camouflage as legitimate website content and DNS tunneling capabilities may mask attacker infrastructure.
  • File Paths: Persistence indicators include: /etc/ld.so.preload (LD_PRELOAD injection), /etc/systemd/system/ (systemd service installation), /lib/modules/ (kernel module storage), /var/log/ (log file targets for deletion).

Log Analytics and Splunk Queries

The following queries translate VoidLink behavioral indicators into actionable detection logic. Queries have been created with AI assistance and should be validated in your environment before production use. Adjust thresholds, time windows, and exclusion lists based on your organization's baseline behavior.

Query 1: Detect SSH Key Enumeration and Harvesting

  • Behavior Targeted: VoidLink harvests SSH private keys from user home directories for lateral movement and credential reuse.
  • MITRE ATT&CK: T1555 (Credentials from Password Stores)
  • Expected Results: Processes accessing ~/.ssh/ directories with unusual frequency or permissions; detection of SSH key file reads by non-SSH processes.
  • False Positive Likelihood: Medium – SSH key management tools, configuration synchronization utilities, and legitimate credential rotation may trigger alerts. Establish baseline for expected key access patterns.

Splunk (SPL)


// Detect SSH key file access by non-SSH processes
// Target: Credential harvesting via SSH key enumeration
index=linux sourcetype=auditd action=open path=*/.ssh/* (name=id_rsa OR name=id_ed25519 OR name=id_ecdsa OR name=config)
  NOT exe IN (/usr/bin/ssh*, /usr/bin/sftp*, /usr/bin/scp*, /usr/bin/ssh-agent*, /usr/libexec/openssh*)
| stats count by host, user, exe, path, action
| where count > 10
| table host, user, exe, path, count
                

Microsoft Defender (KQL)


// Detect SSH key file access and credential harvesting
// Data Tables: ProcessCreationEvents, FileAccessEvents, DeviceFileEvents
// Monitor for processes accessing SSH directories and credential stores
DeviceFileEvents
| where FolderPath contains ".ssh" and FileName in ("id_rsa", "id_ed25519", "id_ecdsa", "config")
| where InitiatingProcessName !in ("ssh", "sftp", "scp", "ssh-agent", "ssh-keygen")
| summarize AccessCount=count(), UniqueUsers=dcount(InitiatingProcessAccountName) by DeviceName, InitiatingProcessName, FolderPath
| where AccessCount > 5
| project DeviceName, InitiatingProcessName, FolderPath, AccessCount, UniqueUsers
                

Query 2: Detect LD_PRELOAD Persistence Mechanism Installation

  • Behavior Targeted: VoidLink modifies /etc/ld.so.preload to inject code into all running processes for persistent rootkit functionality.
  • MITRE ATT&CK: T1547.006 (Kernel Modules and Extensions), T1547.015 (Boot or Logon Initialization Scripts)
  • Expected Results: Modifications to /etc/ld.so.preload file; creation of suspicious shared objects (.so files) referenced in ld.so.preload; non-root process attempts to modify the file.
  • False Positive Likelihood: Low – /etc/ld.so.preload modifications should be rare and only from system administrators or package managers. Any unexpected modifications warrant investigation.

Splunk (SPL)


// Detect LD_PRELOAD modification and suspicious shared object loading
// Tuning: Exclude legitimate system updates and patch management tools
index=linux sourcetype=auditd (path="/etc/ld.so.preload" OR path=/lib*/ld.so.preload) action IN (write, modify)
| stats earliest(_time) as first_seen latest(_time) as last_seen count by host, user, exe, path, name
| where count > 1 OR (user != "root" AND user != "_apt" AND user != "dpkg")
| table host, user, exe, path, first_seen, last_seen, count

// Secondary: Detect execution of processes with suspicious LD_PRELOAD environment variable
index=linux sourcetype=sysmon EventCode=1 LD_PRELOAD=*
| where LD_PRELOAD!="" AND LD_PRELOAD!="/lib/ld-linux*.so*"
| table Computer, User, CommandLine, LD_PRELOAD, ParentImage
                

Microsoft Defender (KQL)


// Detect LD_PRELOAD file modifications in Linux systems
// Data Tables: DeviceFileEvents, ProcessCreationEvents
// Monitor /etc/ld.so.preload for unauthorized changes
DeviceFileEvents
| where FolderPath == "/etc" and FileName == "ld.so.preload"
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where InitiatingProcessAccountName != "root" and InitiatingProcessAccountName != "system"
| project Timestamp, DeviceName, InitiatingProcessName, ActionType, FolderPath
| join kind=inner (
    ProcessCreationEvents
    | where FileName == "sudo" or ProcessCommandLine contains "ld.so.preload"
  ) on DeviceName
                

Query 3: Detect Systemd Service Creation for Persistence

  • Behavior Targeted: VoidLink creates systemd service files for automated persistence and privilege escalation across reboots.
  • MITRE ATT&CK: T1547.015 (Boot or Logon Initialization Scripts), T1053 (Scheduled Task/Job)
  • Expected Results: New .service files in /etc/systemd/system/ or /usr/lib/systemd/system/; suspicious service unit files with ExecStart commands pointing to unexpected binaries; service enable/start events from non-administrative processes.
  • False Positive Likelihood: Medium – Legitimate application deployment may create systemd services. Baseline expected service creation patterns and verify against change management procedures.

Splunk (SPL)


// Detect suspicious systemd service creation and execution
// Target: Persistence via systemd unit files
index=linux sourcetype=auditd path=/etc/systemd/system/*.service action=create
| fields host, user, exe, path, time
| stats count by host, user, exe
| where count >= 1

// Secondary query: Detect service start/enable from suspicious processes
index=linux sourcetype=auditd exe="*systemctl*" OR exe="*timedatectl*" action IN (start, enable)
| where user != "root"
| table host, user, exe, type, msg
                

Microsoft Defender (KQL)


// Detect systemd service creation and manipulation
// Data Tables: ProcessCreationEvents, DeviceFileEvents
// Monitor for suspicious service file creation and systemctl execution
DeviceFileEvents
| where FolderPath contains "/etc/systemd/system" and FileName endswith ".service"
| where ActionType in ("FileCreated", "FileModified")
| join kind=inner (
    ProcessCreationEvents
    | where ProcessName == "systemctl" or CommandLine contains "systemctl"
  ) on DeviceName
| project Timestamp, DeviceName, InitiatingProcessName, ActionType, FolderPath, ProcessName
                

Query 4: Detect Cloud Metadata Service Enumeration

  • Behavior Targeted: VoidLink queries AWS, Azure, GCP, Alibaba, and Tencent metadata services to determine cloud provider and adapt evasion strategies.
  • MITRE ATT&CK: T1592 (Gather Victim Host Information), T1087 (Account Discovery)
  • Expected Results: HTTP requests to 169.254.169.254 (AWS metadata service), Azure Instance Metadata Service (169.254.169.254:80/metadata/instance), GCP metadata servers; requests originating from processes outside normal cloud agent scope.
  • False Positive Likelihood: Medium – Cloud agents and legitimate applications query metadata services. Establish baseline for expected metadata service consumers and time patterns.

Splunk (SPL)


// Detect suspicious cloud metadata service queries
// Tuning: Exclude cloud agents (AWS Systems Manager, Azure agent, GCP agent, etc.)
index=network dest_ip="169.254.169.254" OR dest="169.254.169.254"
| where src_ip != "127.0.0.1" AND dest_port IN (80, 443, 8080)
| stats count by src_ip, src_host, dest_ip, request, user_agent
| where count > 5 OR (user_agent NOT LIKE "%curl%AmazonSSM%" AND user_agent NOT LIKE "%AzureAgent%" AND user_agent NOT LIKE "%GCloud%")
| table src_host, src_ip, request, count, user_agent
                

Microsoft Defender (KQL)


// Detect cloud metadata service enumeration
// Data Tables: DeviceNetworkEvents, ProcessCreationEvents
// Monitor for HTTP requests to cloud metadata endpoints from non-agent processes
DeviceNetworkEvents
| where RemoteIP == "169.254.169.254" and RemotePort in (80, 443, 8080)
| where InitiatingProcessName !in ("amazon-ssm-agent", "waagent", "google-guest-agent", "alibaba-agent", "tencentcloud-agent")
| summarize RequestCount=count(), FirstSeen=min(Timestamp), LastSeen=max(Timestamp) by DeviceName, InitiatingProcessName, InitiatingProcessCommandLine
| where RequestCount > 3
| project DeviceName, InitiatingProcessName, InitiatingProcessCommandLine, RequestCount, FirstSeen, LastSeen
                

Query 5: Detect Anti-Forensics Activities (Log Deletion, History Clearing)

  • Behavior Targeted: VoidLink's anti-forensics module deletes logs, clears bash history, manipulates file timestamps, and overwrites sensitive data to evade detection and incident response.
  • MITRE ATT&CK: T1070 (Indicator Removal), T1565 (Data Destruction)
  • Expected Results: Processes deleting log files (/var/log/*), clearing shell history files (~/.bash_history, ~/.zsh_history), running secure deletion tools (shred, dd, wipe); file timestamp modifications on sensitive files.
  • False Positive Likelihood: Low-Medium – Log rotation and cleanup are normal, but should originate from logrotate, cron, or system processes. Direct process manipulation of /var/log/ from user processes is suspicious.

Splunk (SPL)


// Detect log deletion and history clearing activities
// Target: Anti-forensics and evidence removal
index=linux sourcetype=auditd action=unlink path IN (/var/log/*, /var/log/audit/*)
| where user != "root" OR exe NOT IN ("logrotate", "systemd-journal", "syslog-ng", "rsyslog")
| stats count by host, user, exe, path
| table host, user, exe, path, count

// Secondary: Detect bash history file deletion/modification
index=linux sourcetype=sysmon EventCode=23 FileName IN ("bash_history", "zsh_history", "history")
| where CommandLine NOT LIKE "%logrotate%" AND CommandLine NOT LIKE "%systemd%"
| table Computer, User, CommandLine, TargetObject
                

Microsoft Defender (KQL)


// Detect log file deletion and history clearing
// Data Tables: DeviceFileEvents, ProcessCreationEvents
// Monitor for deletion of system logs and shell history files
DeviceFileEvents
| where FolderPath contains "/var/log" and ActionType == "FileDeleted"
| where InitiatingProcessName !in ("logrotate", "journalctl", "auditd", "rsyslog", "syslog-ng")
| join kind=inner (
    ProcessCreationEvents
    | where CommandLine contains "rm" or CommandLine contains "truncate" or CommandLine contains "shred"
  ) on DeviceName
| project Timestamp, DeviceName, InitiatingProcessName, FolderPath, FileName, ProcessCommandLine

// Detect shell history file access for deletion or clearing
| union (
    DeviceFileEvents
    | where FileName in ("bash_history", "zsh_history", "history", ".bash_history")
    | where ActionType in ("FileDeleted", "FileModified")
    | where InitiatingProcessName !in ("bash", "zsh", "sh")
  )
                
Back to Hunting off the Red