Safeguard
Application Security•

Acquire Virtual Private Servers (T1583.003) Guide

MITRE T1583.003: attackers rent VPSs for C2 and staging because they are quick to start and hard to trace. How defenders find and limit them.

Safeguard Security Team
3 min read

Virtual Private Server (T1583.003) is a sub-technique of Acquire Infrastructure in the resource development tactic. The adversary rents virtual private servers (VPSs) to use in targeting. Platform: PRE.

How attackers use it

Many cloud providers sell virtual machines and containers as a service. MITRE says a VPS makes it harder to physically tie operations to the adversary, and cloud infrastructure makes it easier to provision, modify and shut down quickly.

For later stages such as command and control, a VPS lets an adversary benefit from the ubiquity and trust that come with higher-reputation cloud providers. MITRE adds that adversaries may also choose providers known for renting VPSs with minimal registration information, which allows more anonymous acquisition.

The consequence: traffic to a major cloud provider's address range is not good evidence of legitimacy, since that is where adversary servers live too.

How to detect it

MITRE notes much of this happens outside your visibility. It suggests two angles.

  • Internet scan data. Once a VPS is running, internet scans may reveal it. Look for identifiable patterns such as services listening, certificates in use, SSL/TLS negotiation features or other response artifacts tied to adversary C2 software.
  • Later lifecycle stages. Focus on command and control, where the server has to talk to something inside your network.

Inside your network, that means watching outbound connections to cloud-hosted addresses that are new or rare for your estate, and reviewing which internal processes made them.

How to reduce the risk

MITRE lists one mitigation, pre-compromise, noting that this technique cannot easily be prevented since it happens outside enterprise defenses. Defensive options are about shrinking the reach of whatever server the adversary rents:

  • Limit outbound traffic by segment to approved destinations.
  • Feed scan-derived indicators from a threat intelligence source into your blocklists.
  • Treat a first-seen cloud destination from a server as an event worth a look.

Check your own environment

# Linux: remote addresses currently connected, with process names
ss -tpn state established

# Windows PowerShell: remote addresses currently connected and owning process ids
Get-NetTCPConnection -State Established | Select-Object RemoteAddress,RemotePort,OwningProcess
  • Can servers reach arbitrary internet hosts, or only approved ones?
  • Do you keep a baseline of destinations per server role?
  • Do you ingest scan-based C2 indicators?

Quick check

Why does a reputable cloud provider's IP range not prove traffic is safe?

Adversaries rent VPSs from those providers to benefit from their ubiquity and trust, so malicious servers can sit in the same ranges.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.