Detect Virtual Private Server in Google Chronicle
Adversaries may compromise third-party Virtual Private Servers (VPSs) to use as operational infrastructure. By taking over VPS instances purchased by legitimate third parties at providers such as DigitalOcean, Linode, Vultr, Hetzner, or OVH, adversaries gain infrastructure that carries the reputation of trusted cloud providers while obscuring the true origin of their operations. Compromised VPS infrastructure is typically leveraged for Command and Control, staging payloads, proxying traffic, or exfiltrating data. Notable examples include Volt Typhoon compromising VPS nodes to proxy C2 traffic through legitimate-appearing cloud infrastructure, and Turla reusing compromised Iranian threat actor VPS infrastructure. Detection must pivot from the adversary's external preparatory action (compromising the VPS itself, which is unobservable from the victim network) to the observable USAGE patterns: beaconing connections to VPS provider IP space, C2-characteristic network behavior such as regular connection intervals with low data volume, and threat intelligence matches against known-compromised VPS nodes.
MITRE ATT&CK
- Tactic
- Resource Development
- Technique
- T1584 Compromise Infrastructure
- Sub-technique
- T1584.003 Virtual Private Server
- Canonical reference
- https://attack.mitre.org/techniques/T1584/003/
YARA-L Detection Query
rule T1584_003_c2_infrastructure {
meta:
author = "Detection Engineering"
description = "Detects potential C2 infrastructure activity and reconnaissance"
severity = "high"
confidence = "medium"
mitre_attack = "T1584.003"
reference = "https://attack.mitre.org/techniques/T1584/003/"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.network.direction = "OUTBOUND"
$e.target.port in (443, 8443, 4443, 8080, 53)
not re.regex($e.target.ip, `^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)`)
re.regex($e.principal.process.file.full_path, `(?i)(powershell|cmd|wscript|cscript|nslookup|dig)`)
condition:
$e
}Google Chronicle YARA-L 2.0 detection for Virtual Private Server. Detects potential C2 beaconing over compromised VPS infrastructure by combining two detection signals: (1) outbound connections to known VPS provider IP ranges (DigitalOcean, Linode, Vultr, Hetzner, O
Data Sources
Required Tables
False Positives & Tuning
- Legitimate business connections to cloud hosting providers
- Security researchers accessing authorized VPS environments for testing
- Development teams connecting to cloud-based build and test environments
- IT administrators managing company-owned remote server infrastructure
Other platforms for T1584.003
Testing Methodology
Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate C2 Beacon to VPS Provider IP Range
Expected signal: Sysmon Event ID 3: 20 Network Connection events with Image=curl.exe (or the parent PowerShell/cmd.exe), DestinationIp=143.198.0.1, DestinationPort=80. Events will be spaced approximately 60 seconds apart. Firewall/proxy logs will show 20 outbound connections to 143.198.0.1:80 from the test host.
- Test 2Resolve and Connect to Known VPS-Hosted Domain (DNS + Network Correlation)
Expected signal: Sysmon Event ID 22: DNS query for ipinfo.io resolving to an IP in cloud provider space. Sysmon Event ID 3: Network connection to the resolved IP on port 80 within seconds of the DNS query. Both events will share the same PID (powershell.exe) allowing correlation. The DNS event will contain the resolved IP in QueryResults.
- Test 3Linux Beacon Simulation to VPS IP Range
Expected signal: auditd SYSCALL records for connect() syscalls to 95.216.0.1:80, or syslog entries if auditd is configured to capture network calls. On hosts with Sysmon for Linux: Event ID 3 (Network Connection) with DestinationIp=95.216.0.1. Firewall/proxy session logs show repeated connections from the source host at ~30s intervals.
- Test 4Cobalt Strike Default JA3 Fingerprint Simulation via Custom TLS Client Hello
Expected signal: Sysmon Event ID 3: Network connection to 143.198.0.1:443 initiated by python.exe. If TLS fingerprinting is deployed at the network layer (Zeek bro:ssl:json or similar), the JA3 field will contain the fingerprint value matching or approximating Cobalt Strike's default. MDE DeviceNetworkEvents will record the connection with TlsFingerprint field populated.
References (9)
- https://attack.mitre.org/techniques/T1584/003/
- https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
- https://media.defense.gov/2019/Oct/18/2002197242/-1/-1/0/NSA_CSA_Turla_20191021%20ver%204%20-%20nsa.gov.pdf
- https://michaelkoczwara.medium.com/cobalt-strike-c2-hunting-with-shodan-c448d501a6e2
- https://cloud.google.com/blog/topics/threat-intelligence/scandalous-external-detection-using-network-scan-data-and-automation/
- https://threatconnect.com/blog/infrastructure-research-hunting/
- https://github.com/activecm/rita
- https://docs.zeek.org/en/master/logs/ssl.html
- https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967/
Unlock Pro Content
Get the full detection package for T1584.003 including response playbook, investigation guide, and atomic red team tests.