Amazon SCS-C02: Risposta agli incidenti e analisi forense — Guida allo studio

By Laurynas Brazys · 24 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

Fa parte della AWS Security Specialty SCS-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Isolamento delle istanze EC2 compromesse

Il primo obiettivo operativo quando si sospetta che un’istanza EC2 sia compromessa è il contenimento senza la distruzione delle prove. Su AWS, il contenimento è un’attività stratificata che riguarda l’esposizione di rete dell’istanza, i suoi legami con il ciclo di vita e la sua accessibilità per i responder.

La sequenza di isolamento canonica inizia restringendo il security group dell’istanza. Poiché idealmente ogni istanza ha il proprio security group dedicato, è possibile sostituire le regole di ingresso (ingress) e di uscita (egress) con un set minimo che consenta l’accesso solo al team forense (o a un security group di diagnostica dedicato). Se l’istanza si trova dietro un Application Load Balancer o in un target group, è necessario prima deregistrarla; se è membro di un gruppo di Auto Scaling, va distaccata con il flag --should-decrement-desired-capacity in modo che l’ASG non lanci immediatamente una sostituzione o, peggio, termini l’istanza “non integra” (unhealthy) a metà dell’indagine.

aws autoscaling detach-instances \
  --instance-ids i-0abc123 \
  --auto-scaling-group-name web-asg \
  --should-decrement-desired-capacity

aws elbv2 deregister-targets \
  --target-group-arn arn:aws:elasticloadbalancing:...:targetgroup/web/abc \
  --targets Id=i-0abc123

aws ec2 modify-instance-attribute \
  --instance-id i-0abc123 \
  --disable-api-termination

Abilitare la protezione dalla terminazione è essenziale perché un operatore ben intenzionato, uno script di automazione o un evento di scale-in dell’ASG possono altrimenti distruggere proprio i volumi che si sta cercando di preservare. La protezione dalla terminazione non sostituisce il distacco dall’ASG: un ASG può comunque terminare istanze protette durante lo scale-in, a meno che non si rimuova l’istanza anche dall’ambito del gruppo.

Per il contenimento a livello di sottorete, quando è necessario un taglio immediato del traffico in uscita (ad esempio, un’istanza che comunica con IP noti per essere malevoli), è possibile aggiungere una regola esplicita di “deny-all” in uscita alla network ACL della sottorete come prima regola numerata. Questa regola è stateless e ha effetto istantaneo su tutti i flussi, a differenza delle modifiche ai security group che influenzano solo i nuovi flussi. Una volta che il percorso di accesso forense è stato stabilito tramite un SG di diagnostica, la regola di “deny” della NACL può essere rimossa in modo che la sottorete del responder possa raggiungere il target attraverso la lista di permessi (allow-list) del SG.

Preservazione delle prove volatili e non volatili

Le prove volatili — elenchi dei processi, socket di rete aperti, moduli del kernel caricati, contenuti della memoria, contenuti di tmpfs — vengono distrutte nel momento in cui l’istanza viene fermata. Le prove non volatili risiedono su EBS e sopravvivono a un arresto/avvio (stop/start), ma possono comunque essere perse se i volumi vengono distaccati o se l’istanza viene terminata senza che siano stati creati degli snapshot. La regola da seguire è: raccogliere prima gli artefatti volatili mentre l’istanza è ancora in esecuzione, quindi creare gli snapshot degli EBS.

La raccolta dei dati volatili dovrebbe essere scriptata ed eseguita tramite SSM Run Command piuttosto che da un operatore umano che digita comandi in una shell interattiva. Run Command registra l’invocazione, i parametri, il principal che ha eseguito il comando e l’output in CloudWatch Logs o S3, che a sua volta diventa parte della registrazione della catena di custodia (chain-of-custody).

Problema pratico: scenario d’uso

Scenario: Meridian Financial esegue le sue applicazioni web rivolte ai clienti in un unico account AWS su più VPC, utilizzando gruppi di Auto Scaling dietro Application Load Balancer, istanze EC2 con volumi EBS, log centralizzati su CloudTrail e CloudWatch, GuardDuty e un archivio di log basato su S3 crittografato con KMS. Il team delle operazioni di sicurezza utilizza AWS Systems Manager per la gestione remota e archivia backup e snapshot in un account di ripristino designato.

Sfida: Un’istanza EC2 di produzione mostra segni di compromissione con traffico in uscita sospetto e attività di processo inaspettata; il team deve isolare l’istanza e preservare sia le prove volatili della memoria sia quelle non volatili del disco per l’analisi forense, senza distruggere le tracce di audit.

Approccio consigliato:

1. Utilizzare le API di Auto Scaling e ELB per distaccare l’istanza dai target group e sospendere i processi di Auto Scaling, quindi applicare un Security Group restrittivo (nega tutto il traffico in entrata/uscita) e aggiornare le regole della Network ACL dell’istanza per isolare l’accesso di rete, mantenendo la gestione tramite AWS Systems Manager Session Manager.
2. Utilizzare AWS Systems Manager Run Command per eseguire un’acquisizione della memoria in-guest (ad esempio, LiME) che scrive il dump della RAM su un volume EBS crittografato collegato o direttamente in un bucket S3 crittografato con SSE-KMS e con S3 Object Lock abilitato per la conservazione.
3. Utilizzare EC2 CreateSnapshot (o CreateImage) per catturare snapshot point-in-time di tutti i volumi EBS collegati, quindi copiare tali snapshot in un account AWS separato o in un’altra regione per preservare la catena di custodia e prevenire manomissioni.
4. Abilitare o recuperare VPC Traffic Mirroring per l’ENI dell’istanza per raccogliere catture di pacchetti su un’istanza EC2 di monitoraggio dedicata e, contemporaneamente, esportare i VPC Flow Logs, i log di accesso di ELB, CloudTrail, CloudWatch Logs e i risultati di GuardDuty nell’archivio S3 sicuro.
5. Taggare e inventariare tutti gli artefatti raccolti in AWS Security Hub o in un sistema di ticketing, assicurarsi che gli oggetti S3 siano crittografati e che Object Lock sia impostato, e limitare l’accesso IAM a un piccolo team forense, registrando ogni accesso tramite CloudTrail.

Motivazione: Isolare l’accesso di rete prima di creare le immagini previene un’ulteriore contaminazione, mentre l’uso di SSM evita di aprire nuovi vettori di rete; catturare prima la memoria volatile e creare snapshot EBS immutabili e archivi S3 sicuri preserva l’integrità delle prove e la catena di custodia, in linea con le best practice di AWS per la risposta agli incidenti.

# ssm-document: capture-volatile.yml
schemaVersion: '2.2'
description: Collect volatile artifacts from a suspect Linux host
mainSteps:
  - action: aws:runShellScript
    name: volatileCapture
    inputs:
      runCommand:
        - TS=$(date +%s)
        - mkdir -p /var/ir/$TS && cd /var/ir/$TS
        - ps auxfww > processes.txt
        - ss -tanp > sockets.txt
        - lsof -n > openfiles.txt
        - cat /proc/mounts > mounts.txt
        - lsmod > modules.txt
        - dd if=/dev/mem of=mem.raw bs=1M 2>/dev/null || true
        - aws s3 cp . s3://ir-evidence-bucket/$INSTANCE_ID/$TS/ --recursive

Subito dopo l’acquisizione dei dati volatili, creare uno snapshot di ogni volume EBS collegato. Taggare gli snapshot con l’identificativo dell’incidente in modo che siano legati in modo inequivocabile al caso.

aws ec2 create-snapshot \
  --volume-id vol-0def456 \
  --description "IR-2024-0917 root volume i-0abc123" \
  --tag-specifications 'ResourceType=snapshot,Tags=[
     {Key=IncidentId,Value=IR-2024-0917},
     {Key=SourceInstance,Value=i-0abc123},
     {Key=Handler,Value=jdoe}]'

Taggare l’istanza stessa con lo stesso ticket dell’incidente, il nome dell’investigatore e un’etichetta di stato come Quarantine. Il tagging coerente dei metadati è il meccanismo nativo di AWS per la catena di custodia: è interrogabile, immutabile tramite le condition key di IAM e appare in ogni evento CloudTrail relativo alla risorsa.

Risposta live con Session Manager e Run Command

Un punto sottile ma cruciale per l’esame: le sessioni SSH esistenti sopravvivono alla rimozione delle regole del security group. I security group sono stateful e valutano le regole all’instaurarsi della connessione; una sessione TCP già stabilita continua a fluire anche dopo che la regola di ingresso che l’ha permessa viene eliminata. Se un operatore isola un’istanza rimuovendo le regole del SG e facendo affidamento sulla propria sessione SSH per l’accesso, quella sessione funzionerà — finché non cade, a quel punto si ritroverà escluso e qualsiasi rientro tramite bastion o basato su chiavi sarà impossibile.

Il pattern corretto è concedere al team di forensica l’accesso tramite SSM Session Manager, che non richiede l’apertura di alcuna porta in ingresso. Session Manager funziona tramite la connessione in uscita dell’Agente SSM verso gli endpoint di SSM, EC2 Messages e SSM Messages (idealmente tramite endpoint di interfaccia VPC, così che l’istanza isolata non necessiti di una rotta internet). È necessario associare un profilo di istanza che permetta ssm:UpdateInstanceInformation e le API dei messaggi, e concedere agli operatori l’autorizzazione ssm:StartSession con ambito limitato tramite tag all’istanza in quarantena.

Poiché le sessioni di Session Manager sono gestite dal control plane di SSM, restringere o svuotare completamente le regole di ingresso del security group non le disturba, e ogni pressione di tasto può essere registrata su S3 o CloudWatch Logs — una sessione interattiva e verificabile, non una scatola nera.

Ripristino Cross-Account di Snapshot Crittografati

Gli ambienti maturi instradano gli snapshot forensi verso un account di forensica dedicato, isolato dall’account del workload compromesso. La condivisione di snapshot tra account richiede due cose: lo snapshot deve essere condiviso con l’account di destinazione (modify-snapshot-attribute --create-volume-permission), e se lo snapshot è crittografato con una chiave KMS gestita dal cliente (CMK), la policy della chiave KMS deve concedere ai principal dell’account di forensica le autorizzazioni kms:Decrypt, kms:CreateGrant e kms:DescribeKey. Gli snapshot crittografati con la chiave aws/ebs gestita da AWS non possono essere condivisi tra account — è necessario prima ri-crittografarli con una CMK tramite un’operazione di copia. Nell’account di forensica, copiare lo snapshot condiviso e ri-crittografarlo con una CMK locale di forensica, in modo che la successiva creazione di volumi non dipenda dall’account di origine.

Progettazione dei Playbook e Minimizzazione dell’Overhead

Codificare i passaggi di contenimento come un documento SSM Automation o un workflow di Step Functions, attivati da risultati (finding) di GuardDuty o Security Hub tramite EventBridge. Una singola automazione dovrebbe: (1) acquisire i dati volatili tramite Run Command, (2) creare snapshot dei volumi con i tag dell’incidente, (3) abilitare la protezione dalla terminazione, (4) scollegare dall’ASG e deregistrare dai target dell’ELB, (5) sostituire il SG con il SG di quarantena, e (6) taggare l’istanza con l’ID del ticket. Mantenere l’istanza in esecuzione preserva le prove vive (live evidence) e abilita l’indagine interattiva tramite Session Manager — lo spegnimento dovrebbe essere un passo successivo e deliberato, non parte del contenimento automatico, perché l’arresto azzera le prove volatili e può innescare logiche di pulizia incorporate nel malware.

Le trappole da interiorizzare: rimuovere le regole del SG fidandosi di una sessione SSH esistente lascia l’operatore alla cieca e dà una falsa fiducia nell’isolamento; eseguire una bonifica sul posto (in-place remediation) prima di creare lo snapshot distrugge gli artefatti che rispondono a come è avvenuta l’intrusione; e lasciare l’istanza nel suo ASG o target group invita a una terminazione automatica o, peggio, a una sostituzione silenziosa che nasconde la portata dell’incidente.

Contenimento Immediato

Quando si sospetta che un workload sia compromesso, la prima decisione è se isolarlo sul posto o rimuoverlo dal servizio. Rimuoverlo — arrestandolo o terminandolo — distrugge le prove volatili come il contenuto della RAM, i processi in esecuzione, i socket aperti e qualsiasi malware che vive solo in memoria. Il contenimento sul posto è quasi sempre la mossa iniziale corretta, e deve avvenire abbastanza rapidamente da impedire a un utente malintenzionato di esfiltrare dati aggiuntivi o di muoversi lateralmente prima che i controlli abbiano effetto.

Due controlli nativi di AWS operano a livelli diversi, e la distinzione è importante. I security group sono stateful e associati alle interfacce di rete elastiche (ENI); le network ACL (NACL) sono stateless e associate alle subnet. Sostituire i security group di un’istanza con un SG di “quarantena” bloccato è l’approccio chirurgico — isola una singola ENI senza disturbare altri workload nella stessa subnet e preserva lo stato di runtime dell’istanza. Tuttavia, le modifiche ai security group influenzano solo i nuovi flussi che raggiungono l’ENI, e se l’istanza compromessa ha già connessioni in uscita di lunga durata, lo stato esistente può persistere. Le regole di “deny” delle NACL hanno effetto immediato al confine della subnet e possono interrompere il traffico ancora più velocemente quando la velocità è più importante della precisione chirurgica — ad esempio, quando sono implicate più istanze nella stessa subnet, o quando una sessione attiva di un utente malintenzionato deve essere interrotta istantaneamente. Le NACL sono utili anche quando le policy impediscono di modificare direttamente un’istanza.

Il SG di quarantena canonico non consente nessun traffico in ingresso e traffico in uscita solo verso gli endpoint di interfaccia VPC per com.amazonaws.<region>.ssm, com.amazonaws.<region>.ssmmessages e com.amazonaws.<region>.ec2messages. Ciò preserva l’accesso tramite Systems Manager Session Manager bloccando al contempo i canali C2, l’esfiltrazione di dati e i movimenti laterali.

QuarantineSG:
  Type: AWS::EC2::SecurityGroup
  Properties:
    GroupDescription: Forensic quarantine - SSM only
    VpcId: !Ref VpcId
    SecurityGroupEgress:
      - IpProtocol: tcp
        FromPort: 443
        ToPort: 443
        DestinationPrefixListId: !Ref SsmEndpointPrefixList
    SecurityGroupIngress: []

Ordine di conservazione delle prove

Il valore forense si degrada dal più volatile al meno volatile, quindi l’ordine delle operazioni è fisso e non negoziabile:

• Abilitare prima la protezione dalla terminazione. Impostare DisableApiTermination=true impedisce che un evento di Auto Scaling, un errore dell’operatore o un’azione pianificata distruggano l’istanza nel bel mezzo dell’indagine. Scollegare anche l’istanza dal suo gruppo di Auto Scaling in modo che i controlli di integrità dell’ASG non possano sostituirla.

• Scollegare o proteggere dall’Auto Scaling. Usare EnterStandby o scollegare l’istanza in modo che l’ASG non la termini perché non integra.

• Eseguire lo snapshot di ogni volume EBS collegato. CreateSnapshot (o CreateSnapshots per un’acquisizione atomica multi-volume) produce un artefatto forense immutabile e crittografato. Assegnare tag agli snapshot con l’ID dell’incidente, l’ID dell’istanza di origine, il timestamp e l’analista. Copiare gli snapshot in un account forense dedicato di proprietà del team di sicurezza, in modo che sopravvivano a una compromissione dell’account.

• Acquisire la memoria. Usare un documento RunCommand di SSM per invocare uno strumento di acquisizione della memoria (LiME, AVML su Linux; WinPMEM su Windows) e trasmettere l’immagine in streaming a un bucket S3 forense con Object Lock in modalità compliance. La memoria deve essere acquisita mentre l’istanza è ancora in esecuzione: un’istanza arrestata non ha RAM da acquisire.

• Raccogliere i metadati. Registrare l’ID dell’istanza, l’AMI, il profilo dell’istanza IAM, VPC/sottorete, ID delle ENI, tag, elenco dei processi in esecuzione, output di netstat e contenuti dell’IMDS. Assegnare all’istanza i tag Status=Quarantined e IncidentId=<id> in modo che le automazioni a valle e gli operatori umani ne riconoscano lo stato.

• Solo allora arrestare l’istanza se l’indagine richiede un’analisi offline del disco. L’arresto cancella la memoria, quindi questo è sempre l’ultimo passaggio.

aws ec2 modify-instance-attribute --instance-id i-0abc --disable-api-termination
aws autoscaling enter-standby --instance-ids i-0abc \
    --auto-scaling-group-name app-asg --should-decrement-desired-capacity
aws ec2 create-snapshots --instance-specification InstanceId=i-0abc \
    --description "IR-2024-071 forensic" --copy-tags-from-source volume
aws ssm send-command --instance-ids i-0abc \
    --document-name "AWS-RunShellScript" \
    --parameters 'commands=["avml /tmp/mem.lime && aws s3 cp /tmp/mem.lime s3://forensics-bucket/"]'

Flussi di lavoro di IR automatizzati

I rilevamenti di GuardDuty dovrebbero attivare il contenimento in pochi secondi, non ore. La pipeline canonica è EventBridge → Lambda → SSM Automation, con SNS per le notifiche.

Una regola di EventBridge effettua il match su source: aws.guardduty con un detail-type di GuardDuty Finding e un pattern che filtra i tipi di rilevamento pertinenti a EC2 come UnauthorizedAccess:EC2/*, Backdoor:EC2/*, Trojan:EC2/* e CryptoCurrency:EC2/*.

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "type": [{"prefix": "UnauthorizedAccess:EC2/"},
             {"prefix": "Backdoor:EC2/"},
             {"prefix": "Trojan:EC2/"}]
  }
}

Il target Lambda estrae l’ID dell’istanza da detail.resource.instanceDetails.instanceId, quindi invoca un documento di SSM Automation (o chiama direttamente l’SDK) per: abilitare la protezione dalla terminazione, sostituire i security group dell’ENI con il SG di quarantena tramite ModifyNetworkInterfaceAttribute, eseguire lo snapshot di tutti i volumi collegati, assegnare tag all’istanza e pubblicare un messaggio SNS sul canale del SOC. L’uso di SSM Automation anziché di chiamate SDK dirette fornisce tracce di audit dettagliate nella cronologia di esecuzione di Automation.

Logging per l’analisi di esfiltrazione e C2

Il contenimento senza telemetria è un lavoro di pura supposizione. I VPC Flow Logs devono essere abilitati a livello di VPC o di sottorete con il tipo di traffico impostato su ALL (sia ACCEPT che REJECT). I record REJECT rivelano scansioni, tentativi di esfiltrazione bloccati e beacon C2 che cercano di raggiungere IP noti come dannosi; i record ACCEPT mostrano quali flussi sono andati a buon fine. Instradare i flow log verso CloudWatch Logs per query in tempo reale e verso S3 per la conservazione a lungo termine con Object Lock. CloudTrail con eventi dati sul bucket S3 forense e su KMS fornisce la catena di audit per la gestione delle prove. Combinare con il logging delle query DNS (Route 53 Resolver) per intercettare DGA e DNS tunneling che i soli flow log non riuscirebbero a rilevare.

Accesso forense controllato tramite Session Manager

Session Manager elimina la necessità di chiavi SSH, bastion host o porte 22/3389 aperte, motivo per cui il SG di quarantena può bloccare ogni accesso tradizionale. Abilitare il logging della sessione su un bucket S3 con SSE-KMS e su CloudWatch Logs; imporre EnforceEncryption=true nelle preferenze della sessione in modo che nessuna sessione venga eseguita senza TLS e crittografia dei log. Le policy IAM su ssm:StartSession dovrebbero avere uno scope limitato alle istanze con tag:Status=Quarantined ed essere concesse solo al ruolo di incident response.

Trappole comuni e perché falliscono

• Arrestare o terminare l’istanza per prima cosa. L’arresto (stop) rilascia la memoria, interrompe le connessioni attive ed elimina la possibilità di acquisire artefatti volatili. La terminazione (terminate) rilascia inoltre il volume root a meno che non sia impostato DeleteOnTermination=false, e anche in quel caso si perde lo stato di runtime. Contenere sempre l’istanza sul posto prima di qualsiasi modifica dello stato di alimentazione.

• Affidarsi esclusivamente ai security group quando le NACL sono più veloci. Le modifiche ai SG sono chirurgiche ma interessano solo l’ENI a cui sono collegati e governano solo i nuovi flussi. Quando sono coinvolte più istanze in una subnet, o quando una sessione in uscita esistente di un utente malintenzionato deve essere interrotta immediatamente, una regola di deny a livello di NACL sulla subnet chiude la porta più velocemente perché le NACL sono stateless e bloccano ogni pacchetto indipendentemente dallo stato precedente.

• Eseguire la remediation prima di creare snapshot. Eseguire il reimaging, il patching o la sostituzione dell’istanza prima di creare snapshot EBS distrugge le prove residenti su disco: binari di malware, meccanismi di persistenza, log, timestamp. Gli snapshot sono economici e immutabili; crearli prima di qualsiasi azione di remediation e copiarli in un account dedicato alla forensica in modo che un account di produzione compromesso non possa eliminarli.

Problema pratico: scenario d’uso

Scenario: Meridian Financial gestisce un ambiente AWS multi-account con carichi di lavoro di produzione in un account dedicato: servizi EC2 ed EKS che ospitano dati dei clienti, bucket S3 per gli archivi, logging centralizzato in un account di sicurezza con CloudTrail, GuardDuty, Security Hub e Config abilitati, e una pipeline CI/CD per i deployment. Il loro team operativo utilizza Systems Manager per il patching e la manutenzione e Route 53/ALB per gli endpoint pubblici.

Sfida: Un finding di GuardDuty e picchi di traffico in uscita imprevisti indicano una probabile istanza EC2 compromessa, impegnata nell’esfiltrazione di dati e in chiamate API IAM sospette, che richiede un contenimento immediato preservando le prove forensi e mantenendo un accesso tracciabile per gli investigatori.

Approccio raccomandato:

1. Attivare il contenimento immediato tramite EventBridge sul finding di GuardDuty per invocare un workflow di Step Functions che utilizza una Lambda/SSM Automation per collegare un security group di quarantena, rimuovere gli IP pubblici o scollegare l’ENI, e revocare/ruotare le credenziali IAM implicate tramite IAM.
2. Preservare le prove volatili e persistenti eseguendo un documento SSM Automation per creare uno snapshot EBS e una AMI dell’istanza, copiare gli snapshot in un account AWS dedicato alla forensica e archiviare gli artefatti esportati in un bucket S3 con S3 Object Lock (modalità compliance) e crittografia KMS.
3. Acquisire i log per l’analisi dell’esfiltrazione e del C2 (Command and Control) assicurandosi che gli eventi di gestione e dati di CloudTrail (S3, Lambda) siano abilitati, inoltrando i VPC Flow Logs, i log di accesso di ALB/NGINX e i log delle query di Route 53 all’account di sicurezza centrale, ed elevare il finding ad Amazon Detective per la correlazione della timeline.
4. Automatizzare l’orchestrazione e le notifiche utilizzando EventBridge -> Step Functions -> Lambda per coordinare il contenimento, la copia delle prove, le notifiche SNS ai responsabili dell’incidente e la creazione di ticket nel sistema ITSM esistente.
5. Fornire un accesso forense controllato richiedendo AWS Systems Manager Session Manager per le sessioni di indagine dal vivo, con la registrazione delle sessioni su CloudWatch Logs e sul bucket S3 forense, consentito solo a un ruolo IAM designato per la forensica con MFA e credenziali temporanee.

Motivazione: Questo approccio isola rapidamente la minaccia, preserva artefatti immutabili e log centralizzati per l’analisi, automatizza i passaggi di risposta ripetibili per ridurre il tempo di contenimento (time-to-contain) e impone un accesso forense tracciabile e basato sul principio del privilegio minimo (least-privilege) tramite Session Manager, secondo le best practice di AWS.

← Sicurezza dei container e serverless · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →