T1584.003: Virtual Private Server
Adversaries may compromise third-party Virtual Private Servers (VPSs) that can be used during targeting. There exist a variety of cloud service providers that will sell virtual machines/containers as a service. Adversaries may compromise VPSs purchased by third-party entities. By compromising a VPS to use as infrastructure, adversaries can make it difficult to physically tie back operations to themselves.CitationNSA NCSC Turla OilRig
Compromising a VPS for use in later stages of the adversary lifecycle, such as Command and Control, can allow adversaries to benefit from the ubiquity and trust associated with higher reputation cloud service providers as well as that added by the compromised third-party.
Security context for executives and security teams
This technique matters because adversaries can use compromised third-party virtual private servers as staging or later command-and-control infrastructure while benefiting from the reputation of legitimate cloud providers and the unrelated victim organization that owns the VPS. For leaders, the key issue is that “known cloud provider” traffic is not automatically benign, and infrastructure preparation may occur before an intrusion is visible inside the enterprise.
Executive priority
Prioritize this as a resilience and detection-readiness issue rather than a simple blocklist problem. The ATT&CK relationships connect this behavior to resource development and to groups/campaigns with espionage and critical-infrastructure context, so executives should ask whether SOC, threat intelligence, and incident response teams can recognize suspicious use of reputable cloud-hosted infrastructure without disrupting legitimate business use of cloud services.
Technical view
T1584.003 is a PRE-platform, resource-development sub-technique of Compromise Infrastructure. MITRE provides no official detection text, but the related DET0854 detection strategy indicates detection is expected through infrastructure-focused analysis. Teams should validate external infrastructure hunting, network-scan-derived indicators, passive DNS/DNS history, proxy and firewall logs, NetFlow, and command-and-control investigation workflows that can distinguish normal VPS/cloud traffic from suspicious infrastructure patterns. Because this behavior precedes or supports later activity, internal endpoint telemetry alone may be insufficient.
Likely telemetry
- External attack-surface and internet scan data relevant to VPS-hosted services
- Passive DNS, DNS resolution history, and domain-to-IP infrastructure pivots
- Firewall, proxy, secure web gateway, and egress logs showing connections to cloud-hosted VPS ranges
- NetFlow or other network metadata for unusual beaconing or repeated outbound sessions
- Threat intelligence records linking domains, certificates, IPs, hosting providers, and observed infrastructure changes
Detection direction
- Do not rely solely on cloud provider reputation; validate behavioral and infrastructure context around connections to VPS-hosted assets.
- Tune detections for suspicious infrastructure patterns while accounting for high false-positive potential from legitimate cloud-hosted services.
- Use relationship-driven context: this is resource development and may only become visible when linked to later command-and-control or campaign infrastructure.
- Confirm whether DET0854-style infrastructure detection is operationalized with documented data sources, enrichment, and analyst playbooks.
- Review blind spots where proxy logs, DNS history, NetFlow, or external scan intelligence are missing or retained for too short a period.
Mitigation priorities
- Apply M1056 Pre-compromise principles: reduce exposed weaknesses and make adversary preparation harder to convert into successful operations.
- Maintain external attack-surface awareness and limit unnecessary public information that helps adversaries select or abuse infrastructure pathways.
- Strengthen egress governance so cloud-hosted destinations are evaluated by behavior and business need, not provider reputation alone.
- Prepare IR procedures for rapidly scoping suspicious VPS-hosted infrastructure across DNS, proxy, firewall, and network metadata.
- For critical infrastructure or cyber-physical environments, ensure monitoring and response plans include cloud-hosted intermediary infrastructure that may support disruptive campaigns.
Additional notes and limits
The supplied ATT&CK object is about adversaries compromising third-party VPS infrastructure, not purchasing their own VPS. The strongest defensive value is in infrastructure correlation, egress visibility, and threat-intelligence-supported hunting. Relationships to Turla, Volt Typhoon, Operation MidnightEclipse, and the 2025 Poland Wiper Attacks show ATT&CK-observed relevance across serious threat contexts, but local exposure and activity must be established with organization-specific telemetry.
MITRE provides no official detection text for this technique, and the object is PRE-platform resource development, so many indicators may be external or only inferable after later-stage activity is observed. This take does not establish active exploitation, attribution, or detection coverage for any environment.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Virtual Private Server
Adversaries may compromise third-party Virtual Private Servers (VPSs) that can be used during targeting. There exist a variety of cloud service providers that will sell virtual machines/containers as a service. Adversaries may compromise VPSs purchased by third-party entities. By compromising a VPS to use as infrastructure, adversaries can make it difficult to physically tie back operations to themselves.CitationNSA NCSC Turla OilRig
Compromising a VPS for use in later stages of the adversary lifecycle, such as Command and Control, can allow adversaries to benefit from the ubiquity and trust associated with higher reputation cloud service providers as well as that added by the compromised third-party.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.