Analisi e risposta alle minacce

Questo documento fornisce indicazioni informali per aiutarti a esaminare i risultati di attività sospette nel tuo ambiente Google Cloud da parte di soggetti potenzialmente malintenzionati. Questo documento fornisce anche risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguire questi passaggi ti aiuta a capire cosa è successo durante un potenziale attacco e a sviluppare possibili risposte per le risorse interessate.

Non è garantito che le tecniche riportate in questa pagina siano efficaci contro le minacce precedenti, attuali o future che dovete affrontare. Consulta la sezione Correzione delle minacce per capire perché Security Command Center non fornisce indicazioni ufficiali per la correzione delle minacce.

Prima di iniziare

Per visualizzare o modificare risultati e log e modificare le risorse Google Cloud, devi disporre di ruoli di gestione di Identity and Access Management (IAM) adeguati. Se riscontri errori di accesso nel Security Command Center, chiedi assistenza all'amministratore e consulta la sezione Controllo dell'accesso per saperne di più sui ruoli. Per risolvere gli errori relativi alle risorse, leggi la documentazione dei prodotti interessati.

Informazioni sui risultati relativi alle minacce

Event Threat Detection produce risultati di sicurezza abbinando gli eventi negli stream di log di Cloud Logging agli indicatori di compromissione (IoC) noti. Gli indicatori di compromissione, sviluppati da fonti di sicurezza interne di Google, identificano potenziali vulnerabilità e attacchi. Event Threat Detection rileva le minacce anche identificando tattiche, tecniche e procedure di attacco note nello stream di log e rilevando deviazioni dal comportamento passato della tua organizzazione o del tuo progetto. Se attivi il livello Premium di Security Command Center a livello di organizzazione, Event Threat Detection può anche analizzare i log di Google Workspace.

Container Threat Detection genera risultati raccogliendo e analizzando il comportamento osservato a basso livello nel kernel guest dei container.

I risultati vengono scritti in Security Command Center. Se attivi il livello Premium di Security Command Center a livello di organizzazione, puoi anche configurare la scrittura dei risultati in Cloud Logging.

Esaminare i risultati

Per esaminare i risultati relativi alle minacce nella console Google Cloud:

1. Nella console Google Cloud, vai alla pagina Risultati di Security Command Center.

   Vai a Risultati

2. Se necessario, seleziona il progetto, la cartella o l'organizzazione Google Cloud.

   

3. Nella sezione Filtri rapidi, fai clic su un filtro appropriato per visualizzare il risultato che ti serve nella tabella Risultati della query sui risultati. Ad esempio, se selezioni Event Threat Detection o Container Threat Detection nella sottosezione Nome visualizzato dell'origine, nei risultati vengono visualizzati solo i risultati del servizio selezionato.

   La tabella viene compilata con i risultati relativi all'origine selezionata.

4. Per visualizzare i dettagli di un determinato rilevamento, fai clic sul nome del rilevamento in Category. Il riquadro dei dettagli del risultato si espande per visualizzare un riepilogo dei dettagli del risultato.

5. Per visualizzare la definizione JSON del rilevamento, fai clic sulla scheda JSON.

I risultati forniscono i nomi e gli identificatori numerici delle risorse coinvolte in un incidente, insieme alle variabili di ambiente e alle proprietà delle risorse. Puoi utilizzare queste informazioni per isolare rapidamente le risorse interessate e determinare l'ambito potenziale di un evento.

Per facilitare la tua indagine, i risultati relativi alle minacce contengono anche link alle seguenti risorse esterne:

• Le voci del framework MITRE ATT&CK. Il framework spiega le tecniche per gli attacchi alle risorse cloud e fornisce indicazioni per la correzione.

• VirusTotal, un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi. Se disponibile, il campo Indicatore VirusTotal fornisce un link a VirusTotal per aiutarti a esaminare ulteriormente potenziali problemi di sicurezza.

  VirusTotal è un'offerta con un prezzo separato, con funzionalità e limiti di utilizzo diversi. È tua responsabilità comprendere e rispettare le norme di utilizzo dell'API di VirusTotal e gli eventuali costi associati. Per ulteriori informazioni, consulta la documentazione di VirusTotal.

  Nota: VirusTotal potrebbe non contenere gli hash di tutte le varianti di malware.

Le sezioni seguenti descrivono le potenziali risposte ai risultati relativi alle minacce.

Disattivazione dei risultati relativi alle minacce

Dopo aver risolto un problema che ha attivato un rilevamento di minacce, Security Command Center non imposta automaticamente lo stato del rilevamento su INACTIVE. Lo stato di un rilevamento di minacce rimane ACTIVE, a meno che non imposta manualmente la proprietà state su INACTIVE.

Per un falso positivo, ti consigliamo di lasciare lo stato del risultato su ACTIVE e di disattivare l'audio del risultato.

Per i falsi positivi persistenti o ricorrenti, crea una regola di disattivazione. L'impostazione di una regola di disattivazione può ridurre il numero di risultati da gestire, il che semplifica l'identificazione di una vera minaccia quando si verifica.

Per una minaccia reale, prima di impostare lo stato del rilevamento su INACTIVE, elimina la minaccia ed esegui un'indagine approfondita sulla minaccia rilevata, sull'entità dell'intrusione e su eventuali altri rilevamenti e problemi correlati.

Per disattivare l'audio di un rilevamento o modificarne lo stato, consulta i seguenti argomenti:

• Disattivare i risultati
• Modificare lo stato di un rilievo

Risposte di Event Threat Detection

Per scoprire di più su Event Threat Detection, consulta come funziona Event Threat Detection.

Questa sezione non contiene risposte per i risultati generati dai moduli personalizzati per Event Threat Detection, perché la tua organizzazione definisce le azioni consigliate per questi rilevatori.

Evasion: Access from Anonymizing Proxy

L'accesso anomalo da un proxy anonimo viene rilevato esaminando Cloud Audit Logs per verificare la presenza di modifiche ai servizi Google Cloud originate da indirizzi IP proxy anonimi, come gli indirizzi IP di Tor.

Nota: Google Cloud ha un proprio meccanismo interno per identificare gli indirizzi IP anonimi, come gli indirizzi IP di TOR.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Evasion: Access from Anonymizing Proxy rilevamento, come indicato in Esaminare i rilevamenti. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo email principale: l'account che ha apportato le modifiche (un account potenzialmente compromesso).
     • IP: l'indirizzo IP del proxy da cui vengono apportate le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Se vuoi, fai clic sulla scheda JSON per visualizzare altri campi di risultati.

Passaggio 2: cerca metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK relativa a questo tipo di rilevamento: Proxy: proxy multi-hop.
2. Contatta il proprietario dell'account nel campo principalEmail. Verifica se l'azione è stata eseguita dal proprietario legittimo.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Defense Evasion: Breakglass Workload Deployment Created

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Breakglass Workload Deployment Created viene rilevato esaminando Cloud Audit Logs per verificare se sono presenti deployment in workload che utilizzano il flag di emergenza per eseguire l'override dei controlli di Autorizzazione binaria.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Defense Evasion: Breakglass Workload Deployment Createdrisultato, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui è stato eseguito il deployment.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta di firma del certificato specifica.

3. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Evasione della difesa: deployment di emergenza del workload.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Defense Evasion: Breakglass Workload Deployment Updated

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Breakglass Workload Deployment Updated viene rilevato esaminando Cloud Audit Logs per verificare se sono presenti aggiornamenti ai workload che utilizzano il flag di emergenza per eseguire l'override dei controlli di Autorizzazione binaria.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Defense Evasion: Breakglass Workload Deployment Updatedrisultato, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui è avvenuto l'aggiornamento.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta di firma del certificato specifica.

3. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Evasione della difesa: deployment di emergenza del workload.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Defense Evasion: Manually Deleted Certificate Signing Request (CSR)

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha eliminato manualmente una richiesta di firma del certificato (CSR). I CSR vengono rimossi automaticamente da un controller di garbage collection, ma gli utenti malintenzionati potrebbero eliminarli manualmente per eludere il rilevamento. Se la richiesta CSR eliminata riguardava un certificato approvato ed emesso, l'utente potenzialmente malintenzionato ora dispone di un metodo di autenticazione aggiuntivo per accedere al cluster. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere molto privilegiate. Kubernetes non supporta la revoca del certificato. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati a questa CSR per determinare se la CSR era approved e se la creazione della CSR era un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha eliminato la CSR era diversa da quella che l'ha creata o approvata?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Defense Evasion: Modify VPC Service Control

Questo risultato non è disponibile per le attivazioni a livello di progetto.

I log di controllo vengono esaminati per rilevare le modifiche ai perimetri dei Controlli di servizio VPC che potrebbero comportare una riduzione della protezione offerta da quel perimetro. Ecco alcuni esempi:

• Un progetto viene rimosso da un perimetro
• Un criterio di livello di accesso viene aggiunto a un perimetro esistente
• Uno o più servizi vengono aggiunti all'elenco dei servizi accessibili

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Defense Evasion: Modify VPC Service Control, come indicato in Esaminare i risultati. Viene visualizzato il riquadro dei dettagli del ritrovamento con la scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare il seguente campo:
     • Email principale: l'account che ha eseguito la modifica.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo della risorsa: il nome del perimetro dei Controlli di servizio VPC che è stato modificato.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties
     • properties
       • name: il nome del perimetro dei Controlli di servizio VPC modificato
       • policyLink: il link al criterio di accesso che controlla il perimetro
       • delta: le modifiche, REMOVE o ADD, a un perimetro che ha ridotto la sua protezione
       • restricted_resources: i progetti che rispettano le limitazioni di questo perimetro. La protezione è ridotta se rimuovi un progetto
       • restricted_services: i servizi la cui esecuzione è vietata dalle limitazioni di questo perimetro. La protezione è ridotta se rimuovi un servizio con limitazioni
       • allowed_services: i servizi che possono essere eseguiti in base alle limitazioni di questo perimetro. La protezione è ridotta se aggiungi un servizio consentito
       • access_levels: i livelli di accesso configurati per consentire l'accesso alle risorse all'interno del perimetro. La protezione è ridotta se aggiungi altri livelli di accesso

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Per trovare i log delle attività di amministrazione relativi alle modifiche di Controlli di servizio VPC, utilizza i seguenti filtri:
   • protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
   • protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Evasione della difesa: modifica della procedura di autenticazione.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del perimetro e della policy dei Controlli di servizio VPC.
• Valuta la possibilità di annullare le modifiche al perimetro fino al completamento dell'indagine.
• Valuta la possibilità di revocare i ruoli Gestore contesto accesso all'entità che ha modificato il perimetro fino al completamento dell'indagine.
• Scopri in che modo sono state utilizzate le protezioni ridotte. Ad esempio, se "API BigQuery Data Transfer Service" è abilitata o aggiunta come servizio consentito, controlla chi ha iniziato a utilizzare il servizio e cosa sta trasferendo.

Defense Evasion: Potential Kubernetes Pod Masquerading

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile ai carichi di lavoro predefiniti che GKE crea per il normale funzionamento del cluster. Questa tecnica è chiamata mascheramento. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose da parte del Pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Discovery: Can get sensitive Kubernetes object check

Un utente potenzialmente malintenzionato ha tentato di determinare su quali oggetti sensibili in GKE può eseguire query utilizzando il comando kubectl auth can-i get. Nello specifico, l'attore ha eseguito uno dei seguenti comandi:

• kubectl auth can-i get '*'
• kubectl auth can-i get secrets
• kubectl auth can-i get clusterroles/cluster-admin

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilievo Discovery: Can get sensitive Kubernetes object check come indicato in Esaminare i rilievi.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi:

   • In Che cosa è stato rilevato:
     • Revisioni accessi Kubernetes: le informazioni richieste per la revisione dell'accesso, basate sulla risorsa k8s SelfSubjectAccessReview.
     • Email principale: l'account che ha effettuato la chiamata.
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • In Link correlati:
     • URI Cloud Logging: link alle voci di Logging.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Nella pagina che viene caricata, controlla se sono state intraprese altre azioni dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Rilevamento
2. Conferma la sensibilità dell'oggetto sottoposto a query e determina se ci sono altri indicatori di attività dannose da parte dell'entità nei log.

3. Se l'account che hai visto nella riga Email dell'entità nei dettagli del risultato non è un account di servizio, contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.

   Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine della revisione dell'accesso per determinarne la legittimità.

4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha creato un pod contenente comandi o argomenti comunemente associati a una shell inversa. Gli autori di attacchi utilizzano le shell reverse per espandere o mantenere il proprio accesso iniziale a un cluster e per eseguire comandi arbitrari. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Conferma che il Pod abbia un motivo legittimo per specificare questi comandi e argumenti.
2. Determina se esistono altri indicatori di attività dannose da parte del Pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica la legittimità del motivo per cui il account di servizio ha eseguito questa azione
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Execution: Suspicious Exec or Attach to a System Pod

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha utilizzato i comandi exec o attach per ottenere una shell o eseguire un comando su un contenitore in esecuzione nello spazio dei nomi kube-system. Questi metodi vengono talvolta utilizzati per scopi di debug legittimi. Tuttavia, kube-system namespace è destinato agli oggetti di sistema creati da Kubernetes e deve essere esaminata l'esecuzione di comandi o la creazione di shell impreviste. Per maggiori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina gli audit log in Cloud Logging per determinare se si trattava di un'attività prevista dall'entità.
2. Determina se esistono altri indicatori di attività dannose da parte dell'entità nei log.

Esamina le indicazioni per l'utilizzo del principio del privilegio minimo per i ruoli RBAC e i ruoli del cluster che hanno consentito questo accesso.

Exfiltration: BigQuery Data Exfiltration

I risultati restituiti da Exfiltration: BigQuery Data Exfiltration contengono una di due possibili sottoregole. Ogni regola secondaria ha un'intensità diversa:

• Regola secondaria exfil_to_external_table con gravità = HIGH:
  • Una risorsa è stata salvata al di fuori della tua organizzazione o del tuo progetto.
• Regola secondaria vpc_perimeter_violation con gravità = LOW:
  • I Controlli di servizio VPC hanno bloccato un'operazione di copia o un tentativo di accedere alle risorse BigQuery.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Exfiltration: BigQuery Data Exfiltration come indicato in Esaminare i rilevamenti.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato:
     • Gravità: la gravità è HIGH per la regola secondariaexfil_to_external_table o LOW per la regola secondariavpc_perimeter_violation.
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo della risorsa: il nome completo della risorsa del progetto, della cartella o dell'organizzazione da cui sono stati esfiltrati i dati.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Fai clic sulla scheda Proprietà dell'origine e controlla i campi visualizzati, in particolare:

   • detectionCategory:
     • subRuleName: exfil_to_external_table o vpc_perimeter_violation.
   • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • properties
     • dataExfiltrationAttempt
       • jobLink: il link al job BigQuery che ha eseguito la fuoriuscita di dati.
       • query: la query SQL eseguita sul set di dati BigQuery.

4. Se vuoi, fai clic sulla scheda JSON per l'elenco completo delle proprietà JSON del rilevamento.

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'unica sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

Puoi utilizzare Google SecOps solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati di Event Threat Detection.

4. Nella tabella, fai clic su un Exfiltration: BigQuery Data Exfiltration risultato in category. Si apre il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui indagini in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON del risultato.

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in Indirizzo email principale e controlla le autorizzazioni assegnate all'account.

Passaggio 4: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Per trovare i log delle attività di amministrazione relativi ai job BigQuery, utilizza i seguenti filtri:

   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 5: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per userEmail fino al completamento dell'indagine.
• Per interrompere l'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources e exfiltration.targets).
• Per eseguire la scansione dei set di dati interessati alla ricerca di informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: BigQuery Data Extraction

L'esfiltrazione di dati da BigQuery viene rilevata esaminando i log di controllo per due scenari:

• Una risorsa viene salvata in un bucket Cloud Storage esterno alla tua organizzazione.
• Una risorsa viene salvata in un bucket Cloud Storage accessibile pubblicamente di proprietà della tua organizzazione.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Exfiltration: BigQuery Data Extraction rilevamento, come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono stati archiviati i dati esfiltrati.
   • Risorsa interessata:
     • Nome completo della risorsa: il nome della risorsa BigQuery di cui sono stati esfiltrati i dati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nel riquadro dei dettagli del rilevamento, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che ha eseguito la fuoriuscita di dati

Passaggio 2: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON del risultato (dal passaggio 1).

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in Indirizzo email principale (dal passaggio 1) e controlla le autorizzazioni assegnate all'account.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Per trovare i log delle attività amministrative relativi ai job BigQuery, utilizza i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per il principale indicato nella riga Email principale della scheda Riepilogo dei dettagli del risultato fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati identificati nel campo Origini di esfiltrazione della scheda Riepilogo dei dettagli del ritrovato.
• Per eseguire la scansione dei set di dati interessati alla ricerca di informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Se sei il proprietario del bucket, valuta la possibilità di revocare le autorizzazioni di accesso pubblico.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: BigQuery Data to Google Drive

L'esfiltrazione dei dati da BigQuery viene rilevata esaminando gli audit log per il seguente scenario:

• Una risorsa viene salvata in una cartella di Google Drive.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Exfiltration: BigQuery Data to Google Drive, come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, tra cui:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulla tabella BigQuery da cui sono stati esfiltrati i dati.
     • Target di esfiltrazione: dettagli sulla destinazione in Google Drive.
   • Risorsa interessata, tra cui:
     • Nome completo della risorsa: il nome della risorsa BigQuery di cui sono stati esfiltrati i dati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Per ulteriori informazioni, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
     • properties:
       • extractionAttempt:
       • jobLink: il link al job BigQuery che ha esfiltrato i dati

Passaggio 2: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectId nel JSON del risultato (dal passaggio 1).

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in access.principalEmail (dal passaggio 1) e controlla le autorizzazioni assegnate all'account.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Per trovare i log delle attività amministrative relativi ai job BigQuery, utilizza i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo nella stessa istanza e nella stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per il principale nel campo access.principalEmail fino al completamento dell'indagine.
• Per interrompere l'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi ai set di dati BigQuery interessati (exfiltration.sources).
• Per eseguire la scansione dei set di dati interessati alla ricerca di informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. A seconda della quantità di informazioni, i costi di Sensitive Data Protection possono essere significativi. Segui le best practice per mantenere sotto controllo i costi di Sensitive Data Protection.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: Cloud SQL Data Exfiltration

L'esfiltrazione dei dati da Cloud SQL viene rilevata esaminando i log di controllo per due scenari:

• Dati delle istanze attive esportati in un bucket Cloud Storage al di fuori dell'organizzazione.
• Dati delle istanze in tempo reale esportati in un bucket Cloud Storage di proprietà dell'organizzazione e accessibile pubblicamente.

Sono supportati tutti i tipi di istanze Cloud SQL.

Per le attivazioni a livello di progetto del livello Security Command Center Premium, questo risultato è disponibile solo se il livello Standard è abilitato nell'organizzazione principale.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Exfiltration: Cloud SQL Data Exfiltration, come indicato nella sezione Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale : l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'istanza Cloud SQL di cui sono stati esfiltrati i dati.
     • Destinatari dell'esfiltrazione: dettagli sul bucket Cloud Storage in cui sono stati esportati i dati.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa Cloud SQL cuyos dati sono stati trafugati.
     • Nome completo del progetto: il progetto Google Cloud che contiene i dati Cloud SQL di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

4. Nel file JSON del rilevamento, prendi nota dei seguenti campi:

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene l'istanza Cloud SQL di origine.
     • properties
     • bucketAccess: indica se il bucket Cloud Storage è accessibile pubblicamente o esterno all'organizzazione
     • exportScope: la quantità di dati esportati, ad esempio l'intera istanza, uno o più database, una o più tabelle o un sottoinsieme specificato da una query.

Passaggio 2: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto dell'istanza elencato nel projectId campo nel file JSON del rilevamento (dal passaggio 1).

3. Nella pagina visualizzata, inserisci l'indirizzo email elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del rilevamento (dal passaggio 1) nella casella Filtro. Controlla quali autorizzazioni sono assegnate all'account.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging (dal passaggio 1). La pagina Logs Explorer include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati descritta nel passaggio 1. I risultati correlati hanno lo stesso tipo di risultato nella stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni per access.principalEmail fino al completamento dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi criteri IAM restrittivi alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso all'API Cloud SQL Admin e all'esportazione da questa, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: Cloud SQL Restore Backup to External Organization

L'esfiltrazione di dati da un backup di Cloud SQL viene rilevata esaminando gli audit log per determinare se i dati del backup sono stati ripristinati in un'istanza Cloud SQL al di fuori dell'organizzazione o del progetto. Sono supportati tutti i tipi di istanze e backup Cloud SQL.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Exfiltration: Cloud SQL Restore Backup to External Organization risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'istanza Cloud SQL da cui è stato creato il backup.
     • Destinatari di esfiltrazione: dettagli sull'istanza Cloud SQL in cui sono stati ripristinati i dati di backup.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa del backup che è stato ripristinato.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL da cui è stato creato il backup.

3. Link correlati, in particolare i seguenti campi:

   • URI Cloud Logging: link alle voci di Logging.
   • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
   • Risultati correlati: link a eventuali risultati correlati.

4. Fai clic sulla scheda JSON.

5. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • parent_name: il nome della risorsa dell'istanza Cloud SQL da cui è stato creato il backup
   • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • properties:
     • restoreToExternalInstance:
       • backupId: l'ID dell'esecuzione del backup ripristinata

Passaggio 2: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto dell'istanza elencato nel campo projectId nel file JSON del rilevamento (dal passaggio 1).

3. Nella pagina visualizzata, nella casella Filtra, inserisci l'indirizzo email elencato in Indirizzo email principale (dal passaggio 1) e controlla le autorizzazioni assegnate all'account.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging (dal passaggio 1). La pagina Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web: esfiltrazione in Cloud Storage.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati. (dal passaggio 1). I risultati correlati hanno lo stesso tipo di risultato nella stessa istanza Cloud SQL.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con i dati trafugati.
• Valuta la possibilità di revocare le autorizzazioni dell'entità elencata nella riga Email principale della scheda Riepilogo dei dettagli del risultato fino al termine dell'indagine.
• Per interrompere l'esfiltrazione, aggiungi criteri IAM restrittivi alle istanze Cloud SQL interessate.
  • MySQL
  • PostgreSQL
  • SQL Server
• Per limitare l'accesso all'API Cloud SQL Admin, utilizza Controlli di servizio VPC.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Exfiltration: Cloud SQL Over-Privileged Grant

Rileva quando tutti i privilegi su un database PostgreSQL (o tutte le funzioni o procedure in un database) vengono concessi a uno o più utenti del database.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Exfiltration: Cloud SQL Over-Privileged Grant risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza PostgreSQL Cloud SQL interessata.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query sul database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi eccessivi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza PostgreSQL Cloud SQL interessata.
     • Nome completo della risorsa padre: il nome della risorsa dell'istanza PostgreSQL Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza PostgreSQL Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: esamina i privilegi del database

1. Connettiti al database PostgreSQL.
2. Elenca e mostra i privilegi di accesso per quanto segue:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi sono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati per le funzioni o le procedure nel database elencato in Nome visualizzato del database (passaggio 1).

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging (dal passaggio 1). La pagina Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario dell'istanza con concessioni con privilegi eccessivi.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie ai beneficiari (da Beneficiari del database del Passaggio 1.

Initial Access: Database Superuser Writes to User Tables

Rileva quando l'account superutente del database Cloud SQL (postgres per PostgreSQL e root per MySQL) scrive nelle tabelle degli utenti. In genere, il super user (un ruolo con accesso molto esteso) non deve essere utilizzato per scrivere nelle tabelle utente. Per le normali attività quotidiane deve essere utilizzato un account utente con accesso più limitato. Quando un superutente scrive in una tabella utente, potrebbe indicare che un malintenzionato ha eseguito l'escalation dei privilegi o ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali, ma non sicure.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Initial Access: Database Superuser Writes to User Tables risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza MySQL o PostgreSQL Cloud SQL interessata.
     • Nome utente del database: il superutente.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome della risorsa dell'istanza Cloud SQL interessata.
     • Nome completo padre: il nome della risorsa dell'istanza Cloud SQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza Cloud SQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in cloudLoggingQueryURI (dal passaggio 1). La pagina Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. Controlla i log pgaudit di PostgreSQL o i log di controllo di Cloud SQL per MySQL, che contengono le query eseguite dal superutente, utilizzando i seguenti filtri:
   • protoPayload.request.user="SUPERUSER"

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Controlla gli utenti autorizzati a connettersi al database.

  • Per PostgreSQL, consulta Creare e gestire gli utenti
  • Per MySQL, consulta Gestire gli utenti con l'autenticazione integrata

• Valuta la possibilità di cambiare la password del superutente.

  • Per PostgreSQL, consulta Impostare la password per l'utente predefinito
  • Per MySQL, consulta Impostare la password per l'utente predefinito

• Valuta la possibilità di creare un nuovo utente con accesso limitato per i diversi tipi di query utilizzati nell'istanza.

  • Concedi al nuovo utente solo le autorizzazioni necessarie per eseguire le sue query.

    • Per PostgreSQL, consulta Grant (comando)
    • Per MySQL, consulta Controllo dell'accesso e gestione dell'account

  • Aggiorna le credenziali per i client che si connettono all'istanza Cloud SQL

Initial Access: Anonymous GKE resource created from the internet

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando un attore potenzialmente malintenzionato ha utilizzato uno dei seguenti gruppi di utenti o utenti predefiniti di Kubernetes per creare una nuova risorsa Kubernetes nel cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi. Un'associazione del controllo dell'accesso basato sui ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione per creare queste risorse nel cluster.

Esamina la risorsa creata e l'associazione RBAC associata per assicurarti che l'associazione sia necessaria. Se la associazione non è necessaria, rimuovila. Per maggiori dettagli, consulta il messaggio di log relativo a questo rilevamento.

Per attenuare il problema, consulta Evitare ruoli e gruppi predefiniti.

Initial Access: GKE resource modified anonymously from the internet

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando un attore potenzialmente malintenzionato ha utilizzato uno dei seguenti gruppi di utenti o utenti predefiniti di Kubernetes per modificare una risorsa Kubernetes nel cluster:

• system:anonymous
• system:authenticated
• system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi. Un'associazione del controllo degli accessi basato su ruoli (RBAC) nel cluster ha concesso all'utente l'autorizzazione a modificare queste risorse nel cluster.

Esamina la risorsa modificata e l'associazione RBAC associata per assicurarti che l'associazione sia necessaria. Se la associazione non è necessaria, rimuovila. Per maggiori dettagli, consulta il messaggio di log relativo a questo rilevamento.

Per attenuare il problema, consulta Evitare ruoli e gruppi predefiniti.

Initial Access: Dormant Service Account Action

Rileva gli eventi in cui un account di servizio gestito dall'utente inattivo ha attivato un'azione. In questo contesto, un account di servizio è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Dormant Service Account Action risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email entità: l'account di servizio inattivo che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza gli strumenti per gli account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Initial Access: Dormant Service Account Key Created

Rileva gli eventi in cui viene creata una chiave per un account di servizio gestito dall'utente inattivo. In questo contesto, un account di servizio è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Dormant Service Account Key Created risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email entità: l'utente che ha creato la chiave dell'account di servizio

   In Risorsa interessata:

   • Nome visualizzato della risorsa: la chiave del account di servizio inattivo appena creata
   • Nome completo del progetto: il progetto in cui risiede l'account di servizio inattivo

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza gli strumenti per gli account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Indirizzo email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Annullare la chiave dell'account di servizio appena creata nella pagina Account di servizio.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il consigliere IAM.

Initial Access: Leaked Service Account Key Used

Rileva gli eventi in cui viene utilizzata una chiave dell'account di servizio compromessa per autenticare l'azione. In questo contesto, una chiave account di servizio divulgata è una chiave che è stata pubblicata su internet pubblico. Ad esempio, le chiavi dei account di servizio vengono spesso pubblicate per errore sul repository GitHub pubblico.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Leaked Service Account Key Used risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email entità: l'account di servizio utilizzato in questa azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il nome del metodo dell'azione
   • Nome chiave dell'account di servizio: la chiave dell'account di servizio divulgata utilizzata per autenticare questa azione
   • Descrizione: la descrizione di ciò che è stato rilevato, inclusa la posizione su internet pubblico in cui è possibile trovare la chiave dell'account di servizio

   In Risorsa interessata:

   • Nome visualizzato della risorsa: la risorsa coinvolta nell'azione

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto o l'organizzazione.

3. Nella pagina caricata, trova i log correlati utilizzando il seguente filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"

   Sostituisci PRINCIPAL_EMAIL con il valore annotato nel campo Email principale nei dettagli del rilevamento. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore annotato nel campo Nome chiave dell'account di servizio nei dettagli del rilevamento.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Revoca immediatamente la chiave dell'account di servizio nella pagina Account di servizio.
• Rimuovi la pagina web o il repository GitHub in cui è pubblicata la chiave dell'account di servizio.
• Valuta la possibilità di eliminare l'account di servizio compromesso.
• Esegui la rotazione ed elimina tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima dell'eliminazione, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.

Initial Access: Excessive Permission Denied Actions

Rileva gli eventi in cui un principale attiva ripetutamente errori di autorizzazione negata su più metodi e servizi.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Initial Access: Excessive Permission Denied Actions risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Indirizzo email dell'entità: l'entità che ha attivato più errori di autorizzazione negata
   • Nome del servizio: il nome dell'API del servizio Google Cloud in cui si è verificato l'ultimo errore di autorizzazione negata
   • Nome metodo: il metodo chiamato quando si è verificato l'ultimo errore di autorizzazione negata

3. Nei dettagli del rilevamento, nella scheda Proprietà di origine, prendi nota dei valori dei seguenti campi nel file JSON:

   • properties.failedActions: gli errori di autorizzazione negata che si sono verificati. Per ogni voce, i dettagli includono il nome del servizio, il nome del metodo, il numero di tentativi non riusciti e l'ora dell'ultima occorrenza dell'errore. Vengono visualizzate al massimo 10 voci.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto.

3. Nella pagina caricata, trova i log correlati utilizzando il seguente filtro:

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
   • protoPayload.status.code=7

   Sostituisci PRINCIPAL_EMAIL con il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario dell'account nel campo Indirizzo email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse del progetto create dall'account, ad esempio istanze Compute Engine, snapshot, service account e utenti IAM sconosciuti e così via.
• Contatta il proprietario del progetto con l'account e, se necessario, elimina o disattiva l'account.

Brute Force: SSH

Rilevamento di un attacco di forza bruta SSH riuscito su un host. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Brute Force: SSH come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • IP chiamante: l'indirizzo IP da cui è stato lanciato l'attacco.
     • Nome utente: l'account che ha eseguito l'accesso.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • sourceProperties:
     • evidence:
       • sourceLogId: l'ID progetto e il timestamp per identificare la voce di log
       • projectId: il progetto che contiene il risultato
     • properties:
       • attempts:
       • Attempts: il numero di tentativi di accesso
         • username: l'account che ha eseguito l'accesso
         • vmName: il nome della macchina virtuale
         • authResult: il risultato dell'autenticazione SSH

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

Puoi utilizzare Google SecOps solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic su un Brute Force: SSH risultato in category. Viene visualizzato il riquadro dei dettagli del risultato.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui indagini in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Eseguire indagini su un indirizzo IP
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai a Dashboard.

   Vai alla dashboard

2. Seleziona il progetto specificato in projectId.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM corrispondente al nome e alla zona in vmName. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva le regole del firewall eccessivamente permissive sulla porta 22.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging.
2. Nella pagina caricata, individua i log di flusso VPC relativi all'indirizzo IP elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del rilevamento utilizzando il seguente filtro:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Passaggio 5: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Account validi: account locali.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il tentativo di forza bruta riuscito.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.
• Valuta la possibilità di disattivare l'accesso SSH alla VM. Per informazioni su come disattivare le chiavi SSH, consulta Limitare le chiavi SSH dalle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi valuta le esigenze della tua organizzazione prima di procedere.
• Utilizza l'autenticazione SSH solo con chiavi autorizzate.
• Blocca gli indirizzi IP dannosi aggiornando le regole del firewall o utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda della quantità di informazioni, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Credential Access: External Member Added To Privileged Group

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Rileva quando un membro esterno viene aggiunto a un gruppo Google con privilegi (un gruppo a cui sono stati concessi ruoli o autorizzazioni sensibili). Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Credential Access: External Member Added To Privileged Group risultato, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nel riquadro dei dettagli, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • externalMember: il membro esterno appena aggiunto
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo

Passaggio 2: controlla i membri del gruppo

1. Vai a Google Gruppi.

   Vai a Google Gruppi

2. Fai clic sul nome del gruppo che vuoi esaminare.

3. Nel menu di navigazione, fai clic su Membri.

4. Se il membro esterno appena aggiunto non deve far parte di questo gruppo, fai clic sulla casella di controllo accanto al nome del membro e seleziona Rimuovi membro o Banna membro.

   Per rimuovere o aggiungere membri, devi essere un amministratore di Google Workspace o disporre del ruolo Proprietario o Gestore nel gruppo Google. Per saperne di più, consulta Assegnare ruoli ai membri di un gruppo.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il progetto.

   

3. Nella pagina visualizzata, controlla i log per le modifiche all'appartenenza ai gruppi Google utilizzando i seguenti filtri:

   • protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha tentato di approvare manualmente una richiesta di firma del certificato (CSR), ma l'azione non è riuscita. La creazione di un certificato per l'autenticazione del cluster è un metodo comune utilizzato dagli attaccanti per creare un accesso permanente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere molto privilegiate. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati alle CSR per determinare se una CSR è stata approved ed emessa e se le azioni correlate alle CSR sono attività previste dall'entità.
2. Determina se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha tentato di approvare la CSR era diversa da quella che l'ha creata?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha approvato manualmente una richiesta di firma del certificato (CSR). La creazione di un certificato per l'autenticazione del cluster è un metodo comune utilizzato dagli utenti malintenzionati per creare un accesso permanente a un cluster compromesso. Le autorizzazioni associate al certificato variano a seconda dell'oggetto incluso, ma possono essere molto privilegiate. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina gli audit log in Cloud Logging e gli avvisi aggiuntivi per altri eventi correlati alle CSR per determinare se le azioni correlate alle CSR sono attività previste dall'entità.
2. Determina se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging. Ad esempio:
   • L'entità che ha approvato la CSR era diversa da quella che l'ha creata?
   • La CSR ha specificato un firmatario integrato, ma alla fine ha dovuto essere approvata manualmente perché non soddisfaceva i criteri del firmatario?
   • L'entità ha provato a richiedere, creare, approvare o eliminare altre CSR?
3. Se non era prevista l'approvazione di una CSR o se è stata determinata come essere dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Consulta le indicazioni per eseguire una rotazione delle credenziali del cluster.

Credential Access: Privileged Group Opened To Public

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Rileva quando un gruppo Google privilegiato (un gruppo a cui sono stati concessi ruoli o autorizzazioni sensibili) viene modificato in modo da essere accessibile al pubblico in generale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Credential Access: Privileged Group Opened To Public risultato, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • sensitiveRoles: i ruoli sensibili associati a questo gruppo
   • whoCanJoin: l'impostazione di adesione al gruppo

Passaggio 2: controlla le impostazioni di accesso al gruppo

1. Vai alla Console di amministrazione di Google Gruppi. Per accedere alla console, devi essere un amministratore di Google Workspace.

   Vai alla Console di amministrazione

2. Nel riquadro di navigazione, fai clic su Directory e poi seleziona Gruppi.

3. Fai clic sul nome del gruppo che vuoi esaminare.

4. Fai clic su Impostazioni di accesso e poi, in Chi può iscriversi al gruppo, esamina l'impostazione di adesione al gruppo.

5. Se necessario, modifica l'impostazione di unione nel menu a discesa.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il progetto.

   

3. Nella pagina visualizzata, controlla i log per le modifiche alle impostazioni di Google Gruppi utilizzando i seguenti filtri:

   • protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Credential Access: Secrets Accessed in Kubernetes Namespace

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva quando un default account di servizio Kubernetes di un pod è stato utilizzato per accedere agli oggetti Secret nel cluster. L'account di servizio Kubernetes default non deve avere accesso agli oggetti Secret, a meno che non lo abbia concesso esplicitamente con un oggetto Role o ClusterRole.

Credential Access: Sensitive Role Granted To Hybrid Group

Rileva quando autorizzazioni o ruoli sensibili vengono concessi a un gruppo Google con membri esterni. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Credential Access: Sensitive Role Granted To Hybrid Group risultato, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha apportato le modifiche, che potrebbe essere compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: la risorsa in cui è stato concesso il nuovo ruolo.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • bindingDeltas: i ruoli sensibili appena concessi a questo gruppo.

Passaggio 2: esamina le autorizzazioni del gruppo

1. Vai alla pagina IAM nella console Google Cloud.

   Vai a IAM

2. Nel campo Filtro, inserisci il nome dell'account elencato in groupName.

3. Esamina i ruoli sensibili concessi al gruppo.

4. Se il ruolo sensibile appena aggiunto non è necessario, revoca il ruolo.

   Per gestire i ruoli nella tua organizzazione o nel tuo progetto, devi disporre di autorizzazioni specifiche. Per maggiori informazioni, consulta la sezione Autorizzazioni richieste.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Se necessario, seleziona il progetto.

   

3. Nella pagina visualizzata, controlla i log per le modifiche alle impostazioni di Google Gruppi utilizzando i seguenti filtri:

   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Malware: Cryptomining Bad IP

Il malware viene rilevato esaminando i log di flusso VPC e i log Cloud DNS per verificare la presenza di connessioni a indirizzi IP e domini di comando e controllo noti. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Malware: Cryptomining Bad IP come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • IP di origine: l'indirizzo IP sospetto di criptomining.
     • Porta di origine: la porta di origine della connessione, se disponibile.
     • IP di destinazione: l'indirizzo IP di destinazione.
     • Porta di destinazione: la porta di destinazione della connessione, se disponibile.
     • Protocollo: il protocollo IANA associato alla connessione.
   • Risorsa interessata
   • Link correlati, inclusi i seguenti campi:
     • URI di Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Flow Analyzer (anteprima): link alla funzionalità Flow Analyzer di Network Intelligence Center. Questo campo viene visualizzato solo quando i log di flusso VPC sono abilitati.

3. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda Proprietà sorgente.

4. Espandi properties e prendi nota dei valori del progetto e dell'istanza nel seguente campo:

   • instanceDetails: prendi nota sia dell'ID progetto sia del nome dell'istanza Compute Engine. L'ID progetto e il nome dell'istanza vengono visualizzati come mostrato nell'esempio seguente:

     /projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME

5. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Seleziona il progetto specificato in properties_project_id.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM corrispondente a properties_sourceInstance. Esamina l'istanza potenzialmente compromessa per rilevare la presenza di malware.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva le regole firewall eccessivamente permissive.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto.

3. Nella pagina caricata, trova i log di flusso VPC relativi a Properties_ip_0 utilizzando il seguente filtro:

   • logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
   • (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Rutto delle risorse.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole del firewall o utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.

Initial Access: Log4j Compromise Attempt

Questo risultato viene generato quando vengono rilevate ricercate JNDI (Java Naming and Directory Interface) all'interno di intestazioni o parametri URL. Queste ricerche possono indicare tentativi di sfruttamento di Log4Shell. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento Initial Access: Log4j Compromise Attempt, come indicato in Esaminare i dettagli del rilevamento. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   • Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

   • Nel JSON, prendi nota dei seguenti campi.

   • properties

     • loadBalancerName: il nome del bilanciatore del carico che ha ricevuto la ricerca JNDI
     • requestUrl: l'URL della richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • requestUserAgent: lo user agent che ha inviato la richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • refererUrl: l'URL della pagina che ha inviato la richiesta HTTP. Se presente, contiene una ricerca JNDI.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI Cloud Logging del passaggio 1.

2. Nella pagina che viene caricata, controlla i campi httpRequest per verificare la presenza di token di stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Consulta CVE-2021-44228: rilevamento di exploit Log4Shell nella documentazione di Logging per trovare stringhe di esempio da cercare e una query di esempio.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Sfrutta un'applicazione rivolta al pubblico.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i consigli di Google Cloud per esaminare e rispondere alla vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza Google Cloud Armor nuovo o esistente. Per ulteriori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Active Scan: Log4j Vulnerable to RCE

Gli scanner di vulnerabilità Log4j supportati iniettano ricerche JNDI offuscate in parametri HTTP, URL e campi di testo con callback ai domini controllati dagli scanner. Questo risultato viene generato quando vengono trovate query DNS per i domini non offuscati. Queste query si verificano solo se una ricerca JNDI è andata a buon fine, indicando una vulnerabilità Log4j attiva. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento Active Scan: Log4j Vulnerable to RCE, come indicato in Rivedere i dettagli del rilevamento. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato
   • Risorsa interessata, in particolare il seguente campo:
     • Nome completo della risorsa: il nome completo della risorsa dell' istanza Compute Engine vulnerabile all'attacco RCE di Log4j.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • properties
     • scannerDomain: il dominio utilizzato dallo scanner nell'ambito della ricerca JNDI. Indica lo scanner che ha identificato la vulnerabilità.
     • sourceIp: l'indirizzo IP utilizzato per eseguire la query DNS
     • vpcName: il nome della rete nell'istanza in cui è stata eseguita la query DNS.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link nel campo URI Cloud Logging del passaggio 1.

2. Nella pagina che viene caricata, controlla i campi httpRequest per verificare la presenza di token di stringa come ${jndi:ldap:// che potrebbero indicare possibili tentativi di sfruttamento.

   Consulta CVE-2021-44228: rilevamento di exploit Log4Shell nella documentazione di Logging per trovare stringhe di esempio da cercare e una query di esempio.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Sfruttamento di servizi remoti.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Esegui l'upgrade alla versione più recente di Log4j2.
• Segui i consigli di Google Cloud per esaminare e rispondere alla vulnerabilità "Apache Log4j 2".
• Implementa le tecniche di mitigazione consigliate in Vulnerabilità di sicurezza di Apache Log4j.
• Se utilizzi Google Cloud Armor, esegui il deployment di cve-canary rule in un criterio di sicurezza Google Cloud Armor nuovo o esistente. Per ulteriori informazioni, consulta Regola WAF di Google Cloud Armor per mitigare la vulnerabilità di Apache Log4j.

Leaked credentials

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Questo rilevamento viene generato quando le credenziali dell'account di servizio Google Cloud vengono accidentalmente divulgate online o compromesse. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un rilevamento account_has_leaked_credentials, come indicato in Rivedere i dettagli del rilevamento. Il riquadro dei dettagli per il risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

• Che cosa è stato rilevato
• Risorsa interessata

1. Fai clic sulla scheda Proprietà origine e prendi nota dei seguenti campi:

   • Compromised_account: l'account di servizio potenzialmente compromesso
   • Project_identifier: il progetto che contiene le credenziali dell'account potenzialmente divulgate
   • URL: il link al repository GitHub

2. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: esamina le autorizzazioni del progetto e dell'account di servizio

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato in Project_identifier.

3. Nella pagina visualizzata, nella casella Filtra, inserisci il nome dell'account elencato in Compromised_account e controlla le autorizzazioni assegnate.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account di servizio compromesso e controlla le chiavi e le date di creazione delle chiavi dell'account di servizio.

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto.

3. Nella pagina che si carica, controlla i log per verificare la presenza di attività provenienti da risorse IAM nuove o aggiornate utilizzando i seguenti filtri:

   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
   • protoPayload.methodName="InsertProjectOwnershipInvite"
   • protoPayload.authenticationInfo.principalEmail="Compromised_account"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link in relatedFindingURI. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con le credenziali trapelate.
• Valuta la possibilità di eliminare l'account di servizio compromesso, nonché di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere alle notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.
• Apri il link URL ed elimina le credenziali compromesse. Raccogli altre informazioni sull'account compromesso e contatta il proprietario.

Malware

Il malware viene rilevato esaminando i log di flusso VPC e i log di Cloud DNS per verificare la presenza di connessioni a domini e indirizzi IP di comando e controllo noti. Attualmente, Event Threat Detection fornisce il rilevamento generale di malware (Malware: Bad IP e Malware: Bad Domain) e rilevatori in particolare per i malware correlati a Log4j (Log4j Malware: Bad IP e Log4j Malware: Bad Domain).

I passaggi riportati di seguito descrivono come effettuare accertamenti e rispondere ai risultati basati su IP. I passaggi per la correzione sono simili per i risultati basati sul dominio.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento di malware pertinente. I passaggi che seguono utilizzano il risultato Malware: Bad IP, come indicato nella sezione Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Dominio indicatore: per i risultati Bad domain, il dominio che ha attivato il risultato.
     • IP indicatore: per i risultati Bad IP, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un indirizzo IP di controllo e un comando di malware noto.
     • Porta di origine: per i risultati Bad IP, la porta di origine della connessione.
     • IP di destinazione: per i risultati Bad IP, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per i risultati Bad IP, la porta di destinazione della connessione.
     • Protocollo: per i risultati Bad IP, il numero del protocollo IANA associato alla connessione.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa dell'istanza Compute Engine interessata.
     • Nome completo del progetto: il nome completo della risorsa del progetto che contiene il rilevamento.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Chronicle: esegui il collegamento a Google SecOps.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Flow Analyzer (anteprima): link alla funzionalità Flow Analyzer di Network Intelligence Center. Questo campo viene visualizzato solo quando i log di flusso VPC sono abilitati.

   1. Fai clic sulla scheda JSON e prendi nota del seguente campo:

      • evidence:
      • sourceLogId:
        • projectID: l'ID del progetto in cui è stato rilevato il problema.
      • properties:
      • InstanceDetails: l'indirizzo della risorsa per l'istanza Compute Engine.

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

Puoi utilizzare Google SecOps solo se attivi Security Command Center a livello di organizzazione.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic sul rilevamento Malware: Bad IP in category (Categoria). Viene visualizzato il riquadro dei dettagli della ricerca.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui indagini in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire indagini su un indirizzo IP
• Esaminare un asset

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella console Google Cloud, vai alla pagina Dashboard.

   Vai alla dashboard

2. Seleziona il progetto specificato nella riga Nome completo del progetto nella scheda Riepilogo.

3. Vai alla scheda Risorse e fai clic su Compute Engine.

4. Fai clic sull'istanza VM corrispondente al nome e alla zona in Nome completo della risorsa. Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.

5. Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva le regole firewall eccessivamente permissive.

Passaggio 4: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.

2. Nella pagina caricata, individua i log di flusso VPC relativi all'indirizzo IP in IP di origine utilizzando il seguente filtro:

   • logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")

     Sostituisci quanto segue:

     • PROJECT_ID con il progetto selezionato elencato in projectId.
     • SOURCE_IP con l'indirizzo IP elencato nella riga IP di origine della scheda Riepilogo dei dettagli del rilevamento.

Passaggio 5: controlla Flow Analyzer

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Per eseguire la procedura seguente, devi attivare i log di flusso VPC.

1. Assicurati di aver eseguito l'upgrade del bucket di log per utilizzare Analisi dei log. Per istruzioni, consulta Eseguire l'upgrade di un bucket per utilizzare Analisi dei log. L'upgrade non comporta costi aggiuntivi.

2. Nella console Google Cloud, vai alla pagina Strumento di analisi dei flussi:

   Vai a Flow Analyzer

   Puoi anche accedere a Flow Analyzer tramite il link URL di Flow Analyzer nella sezione Link correlati della scheda Riepilogo del riquadro Dettagli della ricerca.

3. Per esaminare ulteriormente le informazioni relative al risultato di Event Threat Detection, utilizza il selettore dell'intervallo di tempo nella barra delle azioni per modificare il periodo di tempo. Il periodo di tempo deve riflettere la prima segnalazione del risultato. Ad esempio, se il rilevamento è stato segnalato nelle ultime 2 ore, puoi impostare il periodo di tempo su Ultime 6 ore. In questo modo, il periodo di tempo in Flow Analyzer include la data e l'ora in cui è stato segnalato il rilevamento.

4. Filtra lo strumento di analisi del flusso per visualizzare i risultati appropriati per l'indirizzo IP associato al rilevamento di IP dannosi:

   1. Nel menu Filtro nella riga Origine della sezione Query, selezionare IP.

   2. Nel campo Valore, inserisci l'indirizzo IP associato al rilevamento e fai clic su Esegui nuova query.

      Se Flow Analyzer non mostra risultati per l'indirizzo IP, elimina il filtro dalla riga Origine ed esegui di nuovo la query con lo stesso filtro nella riga Destinazione.

5. Analizza i risultati. Per ulteriori informazioni su un flusso specifico, fai clic su Dettagli nella tabella Tutti i flussi di dati per aprire il riquadro Dettagli flusso.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Dynamic Resolution e Command and Control.
2. Esamina i risultati correlati facendo clic sul link Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Controlla gli URL e i domini segnalati su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto contenente malware.
• Esamina l'istanza potenzialmente compromessa e rimuovi eventuali malware rilevati. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.
• Per monitorare le attività e le vulnerabilità che hanno consentito l'inserimento di malware, controlla i log di controllo e i log syslog associati all'istanza compromessa.
• Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.
• Blocca gli indirizzi IP dannosi aggiornando le regole del firewall o utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor nella pagina Servizi integrati di Security Command Center. A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativi. Per ulteriori informazioni, consulta la guida ai prezzi di Google Cloud Armor.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza la policy IAM Shielded VM e Immagini attendibili.

Persistence: IAM Anomalous Grant

I log di controllo vengono esaminati per rilevare l'aggiunta di concessioni di ruoli IAM (Identity Access Management) che potrebbero essere considerate sospette.

Di seguito sono riportati alcuni esempi di concessioni anomale:

• Invitare un utente esterno, ad esempio un utente gmail.com, come proprietario del progetto dalla console Google Cloud
• Un account di servizio che concede autorizzazioni sensibili
• Un ruolo personalizzato che concede autorizzazioni sensibili
• Un account di servizio aggiunto dall'esterno dell'organizzazione o del progetto

Il rilevamento IAM Anomalous Grant è unico in quanto include subregole che forniscono informazioni più specifiche su ogni istanza di questo rilevamento. La classificazione della gravità di questo risultato dipende dalla regola secondaria. Ogni regola secondaria potrebbe richiedere una risposta diversa.

L'elenco seguente mostra tutte le possibili sottoregole e le relative severità:

• external_service_account_added_to_policy:
  • HIGH, se è stato concesso un ruolo con elevata sensibilità o se è stato concesso un ruolo con media sensibilità a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli con informazioni altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, consulta Ruoli con livello di sensibilità medio.
• external_member_invited_to_policy: HIGH
• external_member_added_to_policy:
  • HIGH, se è stato concesso un ruolo con elevata sensibilità o se è stato concesso un ruolo con media sensibilità a livello di organizzazione. Per ulteriori informazioni, consulta Ruoli con informazioni altamente sensibili.
  • MEDIUM, se è stato concesso un ruolo con sensibilità media. Per ulteriori informazioni, consulta Ruoli con livello di sensibilità medio.
• custom_role_given_sensitive_permissions: MEDIUM
• service_account_granted_sensitive_role_to_member: HIGH
• policy_modified_by_default_compute_service_account: HIGH

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Persistence: IAM Anomalous Grant come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo email dell'entità: indirizzo email dell'utente o dell'account di servizio che ha assegnato il ruolo.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Fai clic sulla scheda JSON. Viene visualizzato il JSON completo del rilevamento.

4. Nel file JSON del rilevamento, prendi nota dei seguenti campi:

   • detectionCategory:
     • subRuleName: informazioni più specifiche sul tipo di assegnazione anomala che si è verificata. La regola secondaria determina la classificazione della gravità di questo risultato.
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il rilevamento.
   • properties:
     • sensitiveRoleGrant:
       • bindingDeltas:
       • Action: l'azione intrapresa dall'utente.
       • Role: il ruolo assegnato all'utente.
       • member: l'indirizzo email dell'utente che ha ricevuto il ruolo.

Passaggio 2: esegui accertamenti in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare questo risultato. Google SecOps è un servizio Google Cloud che ti consente di esaminare le minacce e passare da un'entità all'altra in un'utile sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

Non puoi esaminare i risultati di Security Command Center in Chronicle se attivi Security Command Center a livello di progetto.

1. Vai alla pagina Risultati di Security Command Center nella console Google Cloud.

   Vai a Risultati

2. Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.

3. Nella sezione Nome visualizzato dell'origine, seleziona Rilevamento minacce evento.

   La tabella viene compilata con i risultati relativi al tipo di origine selezionato.

4. Nella tabella, fai clic su un Persistence: IAM Anomalous Grant risultato in category. Si apre il riquadro dei dettagli della ricerca.

5. Nella sezione Link correlati del riquadro dei dettagli del rilevamento, fai clic su Esegui indagini in Chronicle.

6. Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.

Utilizza le seguenti guide per eseguire indagini in Google SecOps:

• Eseguire un'indagine su un utente
• Esaminare un asset

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Nella pagina che si carica, cerca le risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link nella riga Risultati correlati della scheda Riepilogo dei dettagli del risultato. I risultati correlati sono dello stesso tipo, della stessa istanza e della stessa rete.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Elimina l'account di servizio compromesso, ruota ed elimina tutte le chiavi di accesso dell'account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare l'aggiunta di utenti gmail.com, utilizza i Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Persistence: Impersonation Role Granted for Dormant Service Account

Rileva gli eventi in cui un ruolo di rappresentazione viene concesso a un entità che consente a quell'entità di rubare l'identità di un account di servizio gestito dall'utente inattivo. In questo rilevamento, l'account di servizio inattivo è la risorsa interessata e un account di servizio è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Persistence: Impersonation Role Granted for Dormant Service Account risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione
   • Offending access grants.Principal name: l'entità a cui è stato concesso il ruolo di rappresentazione

   In Risorsa interessata:

   • Nome visualizzato della risorsa: l'account di servizio inattivo come risorsa
   • Nome completo del progetto: il progetto in cui risiede l'account di servizio inattivo

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza gli strumenti per gli account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Indirizzo email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging in Link correlati per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il consigliere IAM.

Persistence: Unmanaged Account Granted Sensitive Role

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Rileva gli eventi in cui un ruolo sensibile viene concesso a un account non gestito. Gli account non gestiti non possono essere controllati dagli amministratori di sistema. Ad esempio, quando il lavoratore corrispondente ha lasciato l'azienda, l'amministratore non può eliminare l'account. Pertanto, la concessione di ruoli sensibili ad account non gestiti crea un potenziale rischio per la sicurezza dell'organizzazione.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Persistence: Unmanaged Account Granted Sensitive Role risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione
   • Offending access grants.Principal name: l'account non gestito che riceve la concessione
   • Concessioni di accesso illecite.Ruolo concesso: il ruolo sensibile concesso

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario del campo Indirizzo email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Rivolgiti al proprietario del campo Concessioni di accesso non conformi.Nome principale per comprendere l'origine dell'account non gestito.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging in Link correlati per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Rimuovi il ruolo sensibile appena concesso dall'account non gestito.
• Valuta la possibilità di convertire l'account non gestito in un account gestito utilizzando lo strumento di trasferimento e di trasferirlo sotto il controllo degli amministratori di sistema.

Persistence: New API Method

In un'organizzazione, una cartella o un progetto è stata rilevata un'attività di amministrazione anomala da parte di un utente potenzialmente malintenzionato. Le attività anomale possono essere:

• Nuova attività di un principale in un'organizzazione, una cartella o un progetto
• Attività che non vengono visualizzate da un po' di tempo da un amministratore in un'organizzazione, una cartella o un progetto

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Persistence: New API Method come indicato in Esaminare i rilevamenti.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi:

   • In Che cosa è stato rilevato:
     • Email principale: l'account che ha effettuato la chiamata
     • Nome del servizio: il nome dell'API del servizio Google Cloud utilizzato nell'azione
     • Nome metodo: il metodo chiamato
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il nome della risorsa interessata, che potrebbe essere uguale al nome dell'organizzazione, della cartella o del progetto
     • Percorso della risorsa: la posizione nella gerarchia delle risorse in cui si è verificata l'attività

Passaggio 2: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Persistenza.
2. Verifica se l'azione era giustificata nell'organizzazione, nella cartella o nel progetto e se è stata intrapresa dal proprietario legittimo dell'account. L'organizzazione, la cartella o il progetto viene visualizzato nella riga Percorso risorsa e l'account nella riga Indirizzo email principale.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Persistence: New Geography

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un utente o un account di servizio IAM accede a Google Cloud da una posizione anomala, in base alla geolocalizzazione dell'indirizzo IP richiedente.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Persistence: New Geographyrisultato come indicato nella sezione Esaminare i dettagli del risultato di questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

• Che cosa è stato rilevato, in particolare i seguenti campi:
  • Email principale: l'account utente potenzialmente compromesso.
• Risorsa interessata, in particolare i seguenti campi:
  • Nome completo del progetto: il progetto che contiene l'account utente potenzialmente compromesso.
• Link correlati, in particolare i seguenti campi:
  • URI Cloud Logging: link alle voci di Logging.
  • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
  • Risultati correlati: link a eventuali risultati correlati.

1. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

2. Nel JSON, prendi nota dei seguenti campi sourceProperties:

   • affectedResources:
     • gcpResourceName: la risorsa interessata
   • evidence:
     • sourceLogId:
     • projectId: l'ID del progetto che contiene il rilevamento.
   • properties:
     • anomalousLocation:
     • anomalousLocation: la posizione attuale stimata dell'utente.
     • callerIp: l'indirizzo IP esterno.
     • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per il comportamento normale.
     • typicalGeolocations: le posizioni in cui l'utente accede di solito alle risorse Google Cloud.

Passaggio 2: controlla le autorizzazioni del progetto e dell'account

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectID nel JSON del risultato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Indirizzo email principale e controlla i ruoli concessi.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina che si carica, controlla i log per verificare la presenza di attività provenienti da risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Controlla i campi anomalousLocation, typicalGeolocations e notSeenInLast per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitare le località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Persistence: New User Agent

Questo risultato non è disponibile per le attivazioni a livello di progetto.

Un account di servizio IAM accede a Google Cloud utilizzando software sospetto, come indicato da un agente utente anomalo.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Persistence: New User Agent risultato come indicato nella sezione Esaminare i dettagli del risultato di questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email entità: l'account di servizio potenzialmente compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo del progetto: il progetto che contiene l'account di servizio potenzialmente compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.
   2. Nel JSON, prendi nota dei seguenti campi.
   • projectId: il progetto contenente l'account di servizio potenzialmente compromesso.
   • callerUserAgent: l'user agent anomalo.
   • anomalousSoftwareClassification: il tipo di software.
   • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per il comportamento normale.

Passaggio 2: controlla le autorizzazioni del progetto e dell'account

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato in projectId.

3. Nella pagina visualizzata, nella casella Filtra, inserisci il nome dell'account elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del risultato e controlla i ruoli concessi.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro elencato nella riga Indirizzo email principale della scheda Riepilogo dei dettagli del risultato.

6. Controlla le chiavi e le date di creazione delle chiavi dell'account di servizio.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina che si carica, controlla i log per verificare la presenza di attività provenienti da risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.methodName="google.iam.admin.v1.UpdateRole"
   • protoPayload.methodName="google.iam.admin.v1.CreateRole"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di segnalazione: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Esamina i campi anomalousSoftwareClassification, callerUserAgent e behaviorPeriod per verificare se l'accesso è anomalo e se l'account è stato compromesso.
• Elimina le risorse del progetto create da account non autorizzati, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.
• Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitare le località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Recommender.

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di modificare un oggetto con controllo degli accessi basato su ruoli (RBAC) ClusterRole, RoleBinding o ClusterRoleBinding del ruolo sensibile cluster-admin utilizzando una richiesta PUT o PATCH.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Changes to sensitive Kubernetes RBAC objects risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
     • Associazioni Kubernetes: l'associazione Kubernetes o ClusterRoleBinding sensibile che è stata modificata.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nella sezione Che cosa è stato rilevato, fai clic sul nome della associazione nella riga Associazioni Kubernetes. Vengono visualizzati i dettagli dell'associazione.

4. Prendi nota dei dettagli dell'associazione nella associazione visualizzata.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.

2. Se il valore in Nome metodo era un metodo PATCH, controlla il corpo della richiesta per vedere quali proprietà sono state modificate.

   Nelle chiamate update (PUT), l'intero oggetto viene inviato nella richiesta, pertanto le modifiche non sono così chiare.

3. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi
2. Conferma la sensibilità dell'oggetto sottoposto a query e se la modifica è giustificata.
3. Per le associazioni, puoi controllare l'oggetto e verificare se ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannose da parte dell'entità nei log.

5. Se l'email dell'entità non è un account di servizio, contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.

   Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine della modifica per determinarne la legittimità.

6. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Create Kubernetes CSR for master cert

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha creato una richiesta di firma del certificato (CSR) master di Kubernetes, che gli consente di accedere con il ruolo cluster-admin.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Create Kubernetes CSR for master cert risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta di firma del certificato specifica.

3. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Esamina se la concessione dell'accesso a cluster-admin era giustificata.

3. Se l'email dell'entità non è un account di servizio, contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.

   Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.

4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Creation of sensitive Kubernetes bindings

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di creare un nuovo oggetto RoleBinding o ClusterRoleBinding per il ruolo cluster-admin.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Creation of sensitive Kubernetes bindings risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Associazioni Kubernetes: l'associazione o il ClusterRoleBinding Kubernetes sensibile che è stato creato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.

2. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Conferma la sensibilità dell'associazione creata e se i ruoli sono necessari per i soggetti.
3. Per le associazioni, puoi controllare l'oggetto e verificare se ha bisogno del ruolo a cui è associato.
4. Determina se esistono altri indicatori di attività dannose da parte dell'entità nei log.

5. Se l'email dell'entità non è un account di servizio, contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.

   Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.

6. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha creato un'associazione RBAC che fa riferimento a uno dei seguenti utenti o gruppi:

• system:anonymous
• system:authenticated
• system:unauthenticated

Questi utenti e gruppi sono effettivamente anonimi e devono essere evitati quando si creano associazioni di ruoli o associazioni di ruoli del cluster a qualsiasi ruolo RBAC. Controlla la associazione per assicurarti che sia necessaria. Se il vincolo non è necessario, rimuovilo. Per ulteriori dettagli, consulta il messaggio di log relativo a questo rilevamento.

1. Esamina le eventuali associazioni create che hanno concesso le autorizzazioni all'utente system:anonymous, al gruppo system:unauthenticated group o al gruppo system:authenticated.
2. Determina se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging.

Se ci sono segni di attività dannose, consulta le indicazioni per indagare e rimuovere le associazioni che hanno consentito questo accesso.

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha eseguito una query per ottenere una richiesta di firma del certificato (CSR) con il comando kubectl utilizzando credenziali di bootstrap compromesse.

Di seguito è riportato un esempio di comando rilevato da questa regola:

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Nome metodo: il metodo chiamato.
   • In Risorsa interessata:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: controlla i log

Se il nome del metodo, che hai annotato nel campo Nome metodo nei dettagli del rilevamento, è un metodo GET:

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.
2. Controlla il valore nel campo protoPayload.resourceName per identificare la richiesta di firma del certificato specifica.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Se la CSR specifica è disponibile nella voce di log, esamina la sensibilità del certificato e se l'azione era giustificata.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Launch of privileged Kubernetes container

Un utente potenzialmente malintenzionato ha creato un pod contenente container con privilegi o con funzionalità di escalation dei privilegi.

Il campo privileged di un container con privilegi è impostato su true. Il campo allowPrivilegeEscalation di un container con funzionalità di escalation dei privilegi è impostato su true. Per ulteriori informazioni, consulta il riferimento dell'API principale SecurityContext v1 nella documentazione Kubernetes.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Launch of privileged Kubernetes container risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email principale: l'account che ha effettuato la chiamata.
     • Pod Kubernetes: il pod appena creato con container con privilegi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il cluster Kubernetes in cui si è verificata l'azione.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

3. Nella scheda JSON, prendi nota dei valori dei campi del rilevamento:

   • findings.kubernetes.pods[].containers: il container con privilegi attivato nel pod.

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del rilevamento nella console Google Cloud, vai a Logs Explorer facendo clic sul link nel campo URI di Cloud Logging.

2. Controlla se sono state intraprese altre azioni dal principale utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nel campo Nome visualizzato della risorsa nei dettagli del rilevamento.

   • PRINCIPAL_EMAIL: il valore annotato nel campo Email principale nei dettagli del rilevamento.

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Escalation dei privilegi.
2. Conferma che il contenitore creato richieda l'accesso alle risorse dell'host e alle funzionalità del kernel.
3. Determina se esistono altri indicatori di attività dannose da parte dell'entità nei log.

4. Se l'email dell'entità non è un account di servizio, contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.

   Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.

5. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.

Privilege Escalation: Dormant Service Account Granted Sensitive Role

Rileva gli eventi in cui un ruolo IAM sensibile viene concesso a un account di servizio gestito dall'utente inattivo. In questo contesto, un account di servizio è considerato inattivo se è rimasto inattivo per più di 180 giorni.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: Dormant Service Account Granted Sensitive Role risultato come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email principale: l'utente che ha eseguito l'azione di concessione
   • Concessioni di accesso illecite.Nome principale: l'account di servizio inattivo che ha ricevuto il ruolo sensibile
   • Concessioni di accesso non conformi.Ruolo concesso: il ruolo IAM sensibile assegnato

   In Risorsa interessata:

   • Nome visualizzato della risorsa: l'organizzazione, la cartella o il progetto in cui il ruolo IAM sensibile è stato concesso all'account di servizio inattivo.

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza gli strumenti per gli account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio inattivo.
2. Contatta il proprietario del campo Indirizzo email principale. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging in Link correlati per aprire Esplora log.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'indirizzo email principale se è compromesso.
• Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondere a eventuali notifiche dell'assistenza clienti Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il consigliere IAM.

Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity

La simulazione anomala dell'identità del service account viene rilevata esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud.
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. L'entità in fondo all'elenco è l'autore della richiesta di simulazione dell'identità.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica se l'azione è stata eseguita dal proprietario legittimo.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity

Anomalous Multistep Service Account Delegation viene rilevato esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud.
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. L'entità in fondo all'elenco è l'autore della richiesta di simulazione dell'identità.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica se l'azione è stata eseguita dal proprietario legittimo.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access

Anomalous Multistep Service Account Delegation viene rilevato esaminando i log di controllo dell'accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di furto d'identità dell'account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
     • Nome metodo: il metodo chiamato
     • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica se l'azione è stata eseguita dal proprietario legittimo.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity

Anomalous Service Account Impersonator viene rilevato esaminando i log di controllo dell'attività di amministrazione per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilevamento Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
     • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
     • Nome metodo: il metodo chiamato
     • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica se l'azione è stata eseguita dal proprietario legittimo.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: Anomalous Service Account Impersonator for Data Access

Il simulatore anomalo dell'identità di un account di servizio viene rilevato esaminando i log di controllo dell'accesso ai dati per verificare se si è verificata un'anomalia in una richiesta di simulazione dell'identità di un account di servizio.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il rilievo Privilege Escalation: Anomalous Service Account Impersonator for Data Access, come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Indirizzo email principale: l'account di servizio finale nella richiesta di furto d'identità utilizzato per accedere a Google Cloud
   • Nome del servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di furto d'identità
   • Nome metodo: il metodo chiamato
   • Informazioni sulla delega per l'account di servizio: dettagli degli account di servizio nella catena di delega. Il principale in fondo all'elenco è l'autore della richiesta di rappresentazione

Passaggio 2: cerca metodi di attacco e risposta

1. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Esamina i principali nella catena di delega per verificare se la richiesta è anomala e se è stato compromesso un account.
3. Contatta il proprietario dell'utente che ha eseguito l'attacco di appropriazione d'identità nell'elenco Informazioni sulla delega dell'account di servizio. Verifica se l'azione è stata eseguita dal proprietario legittimo.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.
• Per limitare chi può creare account di servizio, utilizza il servizio di criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza il motore per suggerimenti IAM.

Privilege Escalation: ClusterRole with Privileged Verbs

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha creato un oggetto ClusterRole RBAC contenente i verbi bind, escalate o impersonate. Un soggetto associato a un ruolo con questi verbi può assumere l'identità di altri utenti con privilegi superiori, associarsi ad altri oggetti Role o ClusterRole contenenti autorizzazioni aggiuntive o modificare le proprie autorizzazioni ClusterRole. Ciò potrebbe portare questi soggetti a ottenere i privilegicluster-admin. Per ulteriori dettagli, consulta il messaggio di log per questo avviso.

1. Esamina il ClusterRole e il ClusterRoleBindings associato per verificare se i soggetti richiedono effettivamente queste autorizzazioni.
2. Se possibile, evita di creare ruoli che coinvolgano i verbi bind, escalate o impersonate.
3. Determina se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging.
4. Quando si assegnano le autorizzazioni in un ruolo RBAC, utilizza il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. L'utilizzo del principio del privilegio minimo riduce il rischio di escalation dei privilegi qualora il cluster venga compromesso, nonché la probabilità che un accesso eccessivo causi un incidente di sicurezza.

Privilege Escalation: ClusterRoleBinding to Privileged Role

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha creato un ClusterRoleBinding RBAC che fa riferimento al system:controller:clusterrole-aggregation-controller ClusterRole predefinito. Questo ClusterRole predefinito ha il verbo escalate, che consente ai soggetti di modificare i privilegi dei propri ruoli, consentendo la escalation dei privilegi. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina tutti i ClusterRoleBinding che fanno riferimento al system:controller:clusterrole-aggregation-controller ClusterRole.
2. Esamina eventuali modifiche al system:controller:clusterrole-aggregation-controller ClusterRole.
3. Determina se esistono altri indicatori di attività dannose da parte dell'entità che ha creato il ClusterRoleBinding negli audit log in Cloud Logging.

Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella degli strumenti comuni utilizzati per le uscite dal contenitore o per eseguire altri attacchi sul cluster. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose da parte del Pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Privilege Escalation: Workload Created with a Sensitive Host Path Mount

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha creato un workload che contiene un montaggio del volume hostPath in un percorso sensibile sul file system del nodo host. L'accesso a questi percorsi sul file system dell'host può essere utilizzato per accedere a informazioni privilegiate o sensibili sul nodo e per le uscite dal contenitore. Se possibile, non consentire volumi hostPath nel cluster. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Esamina il carico di lavoro per determinare se questo volume hostPath è necessario per la funzionalità prevista. Se la risposta è "Sì", assicurati che il percorso sia relativo alla directory più specifica possibile Ad esempio, /etc/myapp/myfiles anziché / o /etc.
2. Determina se esistono altri indicatori di attività dannose relativi a questo workload negli audit log in Cloud Logging.

Per bloccare i montaggi dei volumi hostPath nel cluster, consulta le indicazioni per l'applicazione degli standard di sicurezza dei Pod.

Privilege Escalation: Workload with shareProcessNamespace enabled

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha eseguito il deployment di un carico di lavoro con l'opzione shareProcessNamespace impostata su true, consentendo a tutti i container di condividere lo stesso spazio dei nomi dei processi Linux. Ciò potrebbe consentire a un contenitore non attendibile o compromesso di eseguire la riassegnazione dei privilegi accedendo e controllando le variabili di ambiente, la memoria e altri dati sensibili dei processi in esecuzione in altri contenitori. Alcuni carichi di lavoro potrebbero richiedere il funzionamento di questa funzionalità per motivi legittimi, ad esempio la gestione dei log dei container sidecar o dei container di debug. Per ulteriori dettagli, consulta il messaggio del log per questo avviso.

1. Conferma che il workload richiede effettivamente l'accesso a uno spazio dei nomi di processo condiviso per tutti i container nel workload.
2. Verifica se esistono altri indicatori di attività dannose da parte dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se ha eseguito l'azione.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identificate la legittimità del motivo per cui il account di servizio ha eseguito questa azione.

Service account self-investigation

Viene utilizzata una credenziale dell'account di servizio per esaminare i ruoli e le autorizzazioni associati allo stesso account di servizio. Questo risultato indica che le credenziali dell'account di servizio potrebbero essere compromesse e che è necessario intervenire immediatamente.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Discovery: Service Account Self-Investigation risultato come indicato nella sezione Esaminare i dettagli del risultato di questa pagina. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Gravità: il livello di rischio assegnato al risultato. La gravità è HIGH se la chiamata API che ha attivato questo rilevamento non è stata autorizzata: l'account di servizio non ha l'autorizzazione per eseguire query sulle proprie autorizzazioni IAM con l'API projects.getIamPolicy.
     • Email entità: l'account di servizio potenzialmente compromesso.
     • IP chiamante: l'indirizzo IP interno o esterno
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa:
     • Nome completo del progetto: il progetto che contiene le credenziali dell'account potenzialmente divulgate.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
   1. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: esamina le autorizzazioni del progetto e dell'account di servizio

1. Nella console Google Cloud, vai alla pagina IAM.

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectID del JSON del risultato.

3. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account elencato in Indirizzo email principale e controlla le autorizzazioni assegnate.

4. Nella console Google Cloud, vai alla pagina Account di servizio.

   Vai ad Account di servizio

5. Nella pagina visualizzata, nella casella Filtro, inserisci il nome dell'account di servizio compromesso e controlla le chiavi e le date di creazione delle chiavi dell'account di servizio.

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, fai clic sul link URI Cloud Logging per aprire Esplora log.
2. Se necessario, seleziona il progetto.
3. Nella pagina che si carica, controlla i log per verificare la presenza di attività provenienti da risorse IAM nuove o aggiornate utilizzando i seguenti filtri:
   • proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
   • protoPayload.methodName="SetIamPolicy"
   • protoPayload.authenticationInfo.principalEmail="principalEmail"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Scoperta gruppi di autorizzazioni: gruppi cloud.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con l'account compromesso.
• Elimina l'account di servizio compromesso, ruota ed elimina tutte le chiavi di accesso dell'account di servizio per il progetto compromesso. Dopo l'eliminazione, le risorse che utilizzano l'account di servizio per l'autenticazione perdono l'accesso.
• Elimina le risorse del progetto create dall'account compromesso, ad esempio istanze Compute Engine, snapshot, account di servizio e utenti IAM sconosciuti.

Inhibit System Recovery: Deleted Google Cloud Backup and DR host

Event Threat Detection esamina i log di controllo per rilevare l'eliminazione di host su cui vengono eseguite applicazioni protette dal servizio di backup e DR. Una volta eliminato un host, non è possibile eseguire il backup delle applicazioni associate.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Inhibit System Recovery: Deleted Google Cloud Backup and DR host risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome dell'applicazione: il nome di un database o di una VM connessa a Backup e RE
     • Nome host: il nome di un host connesso a Backup and RE
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato l'host
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Verifica che l'host eliminato non sia più presente nell'elenco di host di backup e RE.
3. Seleziona l'opzione Aggiungi host per aggiungere nuovamente l'host eliminato.

Inhibit System Recovery: Google Cloud Backup and DR remove plan

Security Command Center esamina gli audit log per rilevare l'eliminazione anomala di un piano di backup del servizio Backup e DR utilizzato per applicare i criteri di backup a un'applicazione.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Inhibit System Recovery: Google Cloud Backup and DR remove plan risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome dell'applicazione: il nome di un database o di una VM connessa a Backup e RE
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati delle applicazioni e delle VM
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione dei backup
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il piano
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestore app, individua le applicazioni interessate che non sono più protette e controlla i criteri di backup per ciascuna.

Inhibit System Recovery: Google Cloud Backup and DR delete template

Security Command Center esamina i log di controllo per rilevare l'eliminazione anomala di un modello. Un modello è una configurazione di base per i backup che può essere applicata a più applicazioni.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Inhibit System Recovery: Google Cloud Backup and DR delete template risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione dei backup
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il modello
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata intrapresa l'azione, vai alla console di gestione.
2. Nella scheda Gestore app, individua le applicazioni interessate che non sono più protette e controlla i criteri di backup per ciascuna.
3. Per aggiungere di nuovo un modello, vai alla scheda Piani di backup, seleziona Modelli e poi l'opzione Crea modello.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

Gli audit log vengono esaminati per rilevare l'eliminazione di un criterio. Un criterio definisce come viene eseguito un backup e dove viene archiviato.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Inhibit System Recovery: Google Cloud Backup and DR delete policy risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio, che definisce la frequenza, la pianificazione e il tempo di conservazione dei backup.
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il criterio
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, seleziona l'applicazione interessata e controlla le impostazioni dei Criteri applicate all'applicazione.

Inhibit System Recovery: Google Cloud Backup and DR delete profile

Gli audit log vengono esaminati per rilevare l'eliminazione di un profilo. Un profilo definisce i pool di archiviazione utilizzati per archiviare i backup.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete profile, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati delle applicazioni e delle VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il profilo
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Piani di backup, seleziona Profili per un elenco di tutti i profili. 3. Esamina i profili per verificare che siano presenti tutti i profili richiesti. 4. Se il profilo eliminato è stato rimosso per errore, seleziona Crea profilo per definire le destinazioni di archiviazione per le appliance di backup e RE.

Inhibit System Recovery: Google Cloud Backup and DR delete storage pool

I log di controllo vengono esaminati per rilevare l'eliminazione di un pool di archiviazione. Un pool di archiviazione associa un bucket Cloud Storage a Backup e RE.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR delete storage pool, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome pool di archiviazione: il nome dei bucket di archiviazione in cui vengono archiviati i backup
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato il pool di archiviazione
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestisci, seleziona Pool di archiviazione per visualizzare un elenco di tutti i pool di archiviazione. 3. Esamina le associazioni dei pool di archiviazione con le appliance di backup. 4. Se un'appliance attiva non ha un pool di archiviazione associato, seleziona Aggiungi pool OnVault per aggiungerlo di nuovo.

Data Destruction: Google Cloud Backup and DR expire image

Un utente potenzialmente malintenzionato ha richiesto di eliminare un'immagine di backup.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire image, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio che definisce la frequenza, la pianificazione e il tempo di conservazione dei backup.
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione dei backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati delle applicazioni e delle VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'immagine di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitor e seleziona Job per esaminare lo stato del job di eliminazione del backup. 3. Se un job di eliminazione non è autorizzato, vai alle autorizzazioni IAM per esaminare gli utenti con accesso ai dati di backup.

Data Destruction: Google Cloud Backup and DR expire all images

Un attore potenzialmente malintenzionato ha richiesto di eliminare tutte le immagini di backup associate a un'applicazione.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR expire all images, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome criterio: il nome di un singolo criterio che definisce la frequenza, la pianificazione e il tempo di conservazione dei backup.
     • Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione dei backup
     • Nome profilo: specifica la destinazione di archiviazione per i backup dei dati delle applicazioni e delle VM
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui sono state eliminate le immagini di backup
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitor e seleziona Job per esaminare lo stato del job di eliminazione del backup. 3. Se un job di eliminazione non è autorizzato, vai alle autorizzazioni IAM per esaminare gli utenti con accesso ai dati di backup.

Data Destruction: Google Cloud Backup and DR remove appliance

I log di controllo vengono esaminati per rilevare la rimozione di un'appliance di backup e ripristino. Un'appliance di backup e ripristino è un componente fondamentale per le operazioni di backup.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Inhibit System Recovery: Google Cloud Backup and DR remove appliance, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome dell'appliance: il nome di un database o di una VM collegata a Backup e RE
     • Soggetto principale: un utente che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stato eliminato l'appliance
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK
     • URI di Logging: link per aprire Esplora log

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestore app, individua le applicazioni interessate che non sono più protette ed esamina i criteri di backup per ciascuna. 3. Per creare una nuova appliance e applicare nuovamente le protezioni alle app non protette, vai a Backup e RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o di recupero. 4. Nel menu Archiviazione, configura ogni nuovo appliance con una destinazione di archiviazione. Dopo aver configurato un'appliance, questa viene visualizzata come opzione quando crei un profilo per le tue applicazioni.

Impact: Google Cloud Backup and DR reduced backup expiration

Event Threat Detection esamina i log di controllo per rilevare se la data di scadenza per un backup su un'appliance di servizio di backup e DR è stata ridotta.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Impact: Google Cloud Backup and DR reduced backup expiration risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Descrizione: informazioni sul rilevamento
     • Oggetto entità: un account utente o di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata ridotta la scadenza del backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Oggetto entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestione app, individua l'applicazione interessata per la quale è stata ridotta la scadenza del backup e verifica che la scadenza sia stata intenzionale da parte del principale.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Impact: Google Cloud Backup and DR reduced backup frequency

Event Threat Detection esamina i log di controllo per rilevare se il piano di backup è stato modificato per ridurre la frequenza dei backup.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Impact: Google Cloud Backup and DR reduced backup frequency risultato, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.
2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Descrizione: informazioni sul rilevamento
     • Oggetto entità: un account utente o di servizio che ha eseguito correttamente un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui è stata ridotta la frequenza del backup.
   • Link correlati, in particolare i seguenti campi:
     • Metodo MITRE ATTACK: link alla documentazione di MITRE ATT&CK.
     • URI di Logging: link per aprire Esplora log.

Passaggio 2: cerca metodi di attacco e risposta

Contatta il proprietario dell'account di servizio nel campo Oggetto entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo rilevamento. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
2. Nella scheda Gestore app, individua l'applicazione interessata per la quale è stata ridotta la frequenza del backup e verifica che la modifica sia stata intenzionale da parte del principale.
3. Per avviare un nuovo backup dell'applicazione, seleziona Gestisci configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.

Impact: Suspicious Kubernetes Container Names - Coin Mining

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Qualcuno ha disegnato un pod con una convenzione di denominazione simile a quella dei comuni miner di monete virtuali. Potrebbe trattarsi di un tentativo da parte di un malintenzionato che ha ottenuto l'accesso iniziale al cluster di utilizzare le risorse del cluster per il mining di criptovaluta. Per ulteriori dettagli, consulta il messaggio di log relativo a questo avviso.

1. Verifica che il Pod sia legittimo.
2. Determina se esistono altri indicatori di attività dannose da parte del Pod o dell'entità negli audit log in Cloud Logging.
3. Se l'entità non è un account di servizio (IAM o Kubernetes), contatta il proprietario dell'account per confermare se l'azione è stata eseguita dal legittimo proprietario.
4. Se l'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne la legittimità.
5. Se il pod non è legittimo, rimuovilo insieme a eventuali associazioni RBAC e service account associati utilizzati dal workload e che ne hanno consentito la creazione.

Lateral Movement: Modified Boot Disk Attached to Instance

I log di controllo vengono esaminati per rilevare movimenti sospetti dei dischi tra le risorse delle istanze Compute Engine. Un disco di avvio potenzialmente modificato è stato collegato a Compute Engine.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato Lateral Movement: Modify Boot Disk Attaching to Instance, come descritto in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, prendi nota dei valori dei seguenti campi.

   In Che cosa è stato rilevato:

   • Email entità: l'account di servizio che ha eseguito l'azione
   • Nome servizio: il nome dell'API del servizio Google Cloud a cui è stato eseguito l'accesso dall'account di servizio
   • Nome metodo: il metodo chiamato

Passaggio 2: cerca metodi di attacco e risposta

1. Utilizza gli strumenti per gli account di servizio, come Activity Analyzer, per esaminare l'attività dell'account di servizio associato.
2. Contatta il proprietario dell'account di servizio nel campo Email dell'entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di utilizzare Secure Boot per le tue istanze VM Compute Engine.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, di ruotare ed eliminare tutte le chiavi di accesso dell'account di servizio per il progetto potenzialmente compromesso. Dopo l'eliminazione, le applicazioni che utilizzano l'account di servizio per l'autenticazione perdono l'accesso. Prima di procedere, il team di sicurezza deve identificare tutte le applicazioni interessate e collaborare con i relativi proprietari per garantire la continuità aziendale.
• Collabora con il tuo team di sicurezza per identificare risorse non familiari, tra cui istanze Compute Engine, snapshot, account di servizio e utenti IAM. Elimina le risorse non create con account autorizzati.
• Rispondi a eventuali notifiche dell'Assistenza Google Cloud.

Privilege Escalation: AlloyDB Over-Privileged Grant

Rileva quando tutti i privilegi su un database AlloyDB per PostgreSQL (o su tutte le funzioni o procedure di un database) vengono concessi a uno o più utenti del database.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il Privilege Escalation: AlloyDB Over-Privileged Grant risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza AlloyDB per PostgreSQL interessato.
     • Nome utente del database: l'utente PostgreSQL che ha concesso privilegi in eccesso.
     • Query sul database: la query PostgreSQL eseguita che ha concesso i privilegi.
     • Beneficiari database: i beneficiari dei privilegi eccessivi.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo principale: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.

3. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: esamina i privilegi del database

1. Connettiti all'istanza AlloyDB per PostgreSQL.
2. Elenca e mostra i privilegi di accesso per quanto segue:
   • Database. Utilizza il metacomando \l o \list e controlla quali privilegi sono assegnati per il database elencato in Nome visualizzato del database (dal passaggio 1).
   • Funzioni o procedure. Utilizza il metacomando \df e controlla quali privilegi sono assegnati per le funzioni o le procedure nel database elencato in Nome visualizzato del database (passaggio 1).

Passaggio 3: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in URI Cloud Logging (dal passaggio 1). La pagina Esploratore dei log include tutti i log relativi all'istanza Cloud SQL pertinente.
2. In Esplora log, controlla i log pgaudit di PostgreSQL, che registrano le query eseguite nel database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario dell'istanza con concessioni con privilegi eccessivi.
• Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari del database fino al completamento dell'indagine.
• Per limitare l'accesso al database (da Nome visualizzato del database del Passaggio 1, revoca le autorizzazioni non necessarie ai beneficiari (da Beneficiari del database del Passaggio 1.

Privilege Escalation: AlloyDB Database Superuser Writes to User Tables

Rileva quando l'account super user del database AlloyDB per PostgreSQL (postgres) scrive nelle tabelle utente. In genere, il super user (un ruolo con accesso molto esteso) non deve essere utilizzato per scrivere nelle tabelle utente. Per le normali attività quotidiane deve essere utilizzato un account utente con accesso più limitato. Quando un superutente scrive in una tabella dell'utente, potrebbe indicare che un utente malintenzionato ha eseguito l'escalation dei privilegi o ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche indicare pratiche normali, ma non sicure.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Privilege Escalation: AlloyDB Database Superuser Writes to User Tables risultato come indicato in Esaminare i risultati.

2. Nella scheda Riepilogo del riquadro dei dettagli del rilevamento, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato del database: il nome del database nell'istanza AlloyDB per PostgreSQL interessato.
     • Nome utente del database: il superutente.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa dell'istanza AlloyDB per PostgreSQL interessata.
     • Nome completo principale: il nome della risorsa dell'istanza AlloyDB per PostgreSQL.
     • Nome completo del progetto: il progetto Google Cloud che contiene l'istanza AlloyDB per PostgreSQL.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.

3. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic sul link in cloudLoggingQueryURI (dal passaggio 1). La pagina Esplora log include tutti i log relativi all'istanza AlloyDB per PostgreSQL pertinente.
2. Controlla i log di pgaudit di PostgreSQL, che contengono le query eseguite dal superutente, utilizzando i seguenti filtri:
   • protoPayload.request.user="postgres"

Passaggio 3: cerca i metodi di attacco e risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di rilevamento: Esfiltrazione tramite servizio web.
2. Per determinare se sono necessari ulteriori passaggi di correzione, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 4: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Esamina gli utenti autorizzati a connettersi al database.
• Valuta la possibilità di cambiare la password del superutente.
• Valuta la possibilità di creare un nuovo utente con accesso limitato per i diversi tipi di query utilizzati nell'istanza.
  • Concedere al nuovo utente solo le autorizzazioni necessarie per eseguire le query.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Rilevamento dei metadati di amministrazione di Compute Engine

Persistence: GCE Admin Added SSH Key

Descrizione	Azioni
La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata in un'istanza stabilita.	La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata in un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un avversario per introdurre nuovi accessi alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" (protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" ) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: INSTANCE_ID: il gceInstanceId indicato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1098/004/

Persistence: GCE Admin Added Startup Script

Descrizione	Azioni
La chiave dei metadati dell'istanza Compute Engine startup-script o startup-script-url è stata modificata in un'istanza stabilita.	La chiave dei metadati dell'istanza Compute Engine startup-script o startup-script-url è stata modificata in un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un avversario per introdurre nuovi accessi alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.instance_id=INSTANCE_ID protoPayload.serviceName="compute.googleapis.com" ((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" ) OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" )) logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: INSTANCE_ID: il gceInstanceId indicato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1098/004/

Rilevamento dei log di Google Workspace

Se condividi i log di Google Workspace con Cloud Logging, Event Threat Detection genera risultati per diverse minacce di Google Workspace. Poiché i log di Google Workspace sono a livello di organizzazione, Event Threat Detection può scansionarli solo se attivi Security Command Center a livello di organizzazione.

Event Threat Detection arricchisce gli eventi dei log e scrive i risultati in Security Command Center. La tabella seguente contiene le minacce di Google Workspace, le voci pertinenti del framework MITRE ATT&CK e i dettagli sugli eventi che attivano i risultati. Puoi anche controllare i log utilizzando filtri specifici e combinare tutte le informazioni per rispondere alle minacce a Google Workspace.

Initial Access: Disabled Password Leak

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'account di un membro è stato disattivato perché è stata rilevata una fuga di password.	Reimposta le password per gli account interessati e consiglia ai membri di utilizzare password efficaci e univoche per gli account aziendali.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

Initial Access: Suspicious Login Blocked

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
È stato rilevato e bloccato un accesso sospetto all'account di un membro.	Questo account potrebbe essere preso di mira dagli avversari. Assicurati che l'account utente rispetti le linee guida per la sicurezza della tua organizzazione relative a password complesse e autenticazione a più fattori.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'account di un membro è stato sospeso a causa di attività sospette.	Questo account è stato compromesso. Reimposta la password dell'account e incoraggia gli utenti a creare password efficaci e univoche per gli account aziendali.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

Impair Defenses: Two Step Verification Disabled

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Un membro ha disattivato la verifica in due passaggi.	Verifica se l'utente intendeva disattivare la verifica in due passaggi. Se la tua organizzazione richiede la verifica in due passaggi, assicurati che l'utente la attivi tempestivamente.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

Initial Access: Government Based Attack

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Alcuni soggetti vicini a un governo potrebbero aver cercato di compromettere un account o un computer di un abbonato.	Questo account potrebbe essere preso di mira dagli avversari. Assicurati che l'account utente rispetti le linee guida per la sicurezza della tua organizzazione relative a password complesse e autenticazione a più fattori.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1078/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

Persistence: SSO Enablement Toggle

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
L'impostazione Abilita SSO (Single Sign-On) sull'account amministratore è stata disattivata.	Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un avversario per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: DOMAIN_NAME: il domainName indicato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1098/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
Le impostazioni del Single Sign-On per l'account amministratore sono state modificate.	Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementata da un avversario per introdurre un nuovo accesso alla tua organizzazione.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" protopayload.metadata.event.parameter.value=DOMAIN_NAME logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci quanto segue: DOMAIN_NAME: il domainName indicato nel risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1098/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

Impair Defenses: Strong Authentication Disabled

Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.

Descrizione	Azioni
La verifica in due passaggi è stata disattivata per l'organizzazione.	La verifica in due passaggi non è più obbligatoria per la tua organizzazione. Scopri se si tratta di una modifica intenzionale delle norme da parte di un amministratore o se si tratta di un tentativo da parte di un avversario di semplificare il furto di account.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Esegui ricerche sugli eventi che attivano questo rilevamento: MITRE: https://attack.mitre.org/techniques/T1562/ Dettagli sugli eventi di Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Rispondere alle minacce a Google Workspace

I risultati per Google Workspace sono disponibili solo per le attivazioni di Security Command Center a livello di organizzazione. Non è possibile eseguire la scansione dei log di Google Workspace per rilevare le attivazioni a livello di progetto.

Se sei un amministratore di Google Workspace, puoi utilizzare gli strumenti di sicurezza del servizio per risolvere queste minacce:

• Centro notifiche di Google Workspace
• Centro per la sicurezza di Google Workspace

Gli strumenti includono avvisi, una dashboard di sicurezza, consigli per la sicurezza e possono aiutarti a esaminare e risolvere le minacce.

Se non sei un amministratore di Google Workspace, svolgi i seguenti passaggi:

• Se riesci ad accedere al tuo account, cambia o reimposta la password e attiva la verifica in due passaggi.
• Contatta l'amministratore di Google Workspace o il team della tua azienda che gestisce il tuo account Google Workspace. Utilizza questi risultati come indicazione che un account potrebbe essere compromesso.

Rilevamento delle minacce Cloud IDS

Cloud IDS: THREAT_ID

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

I risultati di Cloud IDS vengono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico verso e da le tue risorse Google Cloud per rilevare eventuali minacce. Quando Cloud IDS rileva una minaccia, invia informazioni sulla minaccia, ad esempio l'indirizzo IP di origine, l'indirizzo di destinazione e il numero di porta, a Event Threat Detection, che emette un rilevamento di minaccia.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri la verifica Cloud IDS: THREAT_ID, come indicato in Esaminare i risultati.

2. Nei dettagli del risultato, nella scheda Riepilogo, esamina i valori elencati nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Protocollo: il protocollo di rete utilizzato
     • Ora evento: l'ora in cui si è verificato l'evento
     • Descrizione: ulteriori informazioni sul risultato
     • Gravità: la gravità dell'avviso
     • IP di destinazione: l'IP target del traffico di rete
     • Porta di destinazione: la porta di destinazione del traffico di rete
     • IP di origine: l'IP di origine del traffico di rete
     • Porta di origine: la porta di origine del traffico di rete
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il progetto contenente la rete con la minaccia
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di logging di Cloud IDS, che contengono le informazioni necessarie per eseguire ricerche in Threat Vault di Palo Alto Networks
   • Detection Service
     • Categoria risultati Il nome della minaccia Cloud IDS

3. Per visualizzare il JSON completo del rilevamento, fai clic sulla scheda JSON.

Passaggio 2: cerca i metodi di attacco e risposta

Dopo aver esaminato i dettagli del rilevamento, consulta la documentazione di Cloud IDS sull'analisi degli avvisi di minaccia per determinare una risposta appropriata.

Puoi trovare ulteriori informazioni sull'evento rilevato nella voce del log originale facendo clic sul link nel campo URI Cloud Logging nei dettagli del rilevamento.

Risposte di Container Threat Detection

Per scoprire di più su Container Threat Detection, consulta come funziona Container Threat Detection.

Added Binary Executed

È stato eseguito un file binario che non faceva parte dell'immagine container originale. Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Garantire l'immutabilità dei contenitori è una best practice importante. Si tratta di un esito di bassa gravità, perché la tua organizzazione potrebbe non seguire questa best practice. Esistono risultati corrispondenteExecution: Added Malicious Binary Executed quando l'hash del codice binario è un indicatore di compromissione (IoC) noto. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Added Binary Executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario aggiunto.
     • Argomenti: gli argomenti forniti quando viene chiamato il file binario aggiunto.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • resource:
     • project_display_name: il nome del progetto che contiene il cluster.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore di cui viene eseguito il deployment.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

4. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario aggiunto eseguendo:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con il percorso di un file locale per archiviare il file binario aggiunto.

6. Connettiti all'ambiente del contenitore eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, API nativa.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Se il file binario doveva essere incluso nel contenitore, ricostruisci l'immagine del contenitore con il file binario incluso. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Added Library Loaded

È stata caricata una libreria che non faceva parte dell'immagine contenitore originale. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Garantire l'immutabilità dei contenitori è una best practice importante. Si tratta di un rilevamento di bassa gravità, perché la tua organizzazione potrebbe non seguire questa best practice. Esistono risultati Execution: Added Malicious Library Loaded corrispondenti quando l'hash del file binario è un indicatore noto di compromissione (IoC). Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Added Library Loaded come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Raccolte: i dettagli della raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • resource:
     • project_display_name: il nome del progetto che contiene la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

4. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. I risultati correlati potrebbero indicare che questa attività era dannosa, anziché un mancato rispetto delle best practice.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupera la libreria aggiunta eseguendo:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con il percorso di un file locale per archiviare la libreria aggiunta.

6. Connettiti all'ambiente del contenitore eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, Moduli condivisi.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Se la raccolta doveva essere inclusa nel contenitore, ricostruisci l'immagine del contenitore con la raccolta inclusa. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Added Malicious Binary Executed

È stato eseguito un file binario dannoso che non faceva parte dell'immagine container originale. Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Added Malicious Binary Executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario aggiunto.
     • Argomenti: gli argomenti forniti quando viene chiamato il file binario aggiunto.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il programma binario dannoso aggiunto:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per memorizzare il file binario dannoso aggiunto.

6. Connettiti all'ambiente del contenitore:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, API nativa.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Added Malicious Library Loaded

È stata caricata una libreria dannosa che non faceva parte dell'immagine del contenitore originale. I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Added Malicious Library Loaded come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Raccolte: i dettagli della raccolta aggiunta.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupera la libreria dannosa aggiunta:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare la libreria malevola aggiunta.

6. Connettiti all'ambiente del contenitore:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, Moduli condivisi.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Built in Malicious Binary Executed

Un file binario che è stato eseguito, con il file binario:

• Inclusi nell'immagine del contenitore originale.
• Identificato come dannoso in base alle informazioni di Threat Intelligence.

L'attaccante ha il controllo del repository delle immagini container o della pipeline di creazione, dove il codice binario dannoso viene inserito nell'immagine container. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Built in Malicious Binary Executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del programma binario integrato.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario integrato.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso integrato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il file binario dannoso di Tin compilato.

6. Connettiti all'ambiente del contenitore:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, API nativa.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Malicious Python executed

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Un modello di machine learning ha identificato il codice Python eseguito come dannoso. Gli attaccanti possono utilizzare Python per trasferire strumenti ed eseguire comandi senza file binari. Garantire l'immutabilità dei contenitori è una best practice importante. L'utilizzo di script per il trasferimento di strumenti può imitare la tecnica di trasferimento di strumenti di ingresso dell'attaccante e comportare rilevamenti indesiderati.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Malicious Python executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: dettagli sull'interprete che ha richiamato lo script.
     • Script: percorso assoluto del nome dello script sul disco. Questo attributo viene visualizzato solo per gli script scritti sul disco, non per l'esecuzione di script letterali, ad esempio python3 -c.
     • Argomenti: gli argomenti forniti al momento dell'invocazione dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: i contenuti dello script eseguito, che potrebbero essere troncati per motivi di rendimento; questo può aiutarti nella tua indagine
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Ad esempio, se lo script inserisce un file binario, controlla se sono presenti risultati correlati al file binario.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminal.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Comando e scripting Interprete, Trasferimento di strumenti di ingresso.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Se Python stava apportando modifiche intenzionali al contenitore, ricostruisci l'immagine del contenitore in modo che non siano necessarie modifiche. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Modified Malicious Binary Executed

Un file binario che è stato eseguito, con il file binario:

• Inclusi nell'immagine del contenitore originale.
• Modificati durante il runtime del container.
• Identificato come dannoso in base alle informazioni di Threat Intelligence.

Gli aggressori installano comunemente malware e strumenti di sfruttamento dopo la compromissione iniziale. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Modified Malicious Binary Executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso assoluto del file binario modificato.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario modificato.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic su JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project project_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project project_name
   

   Sostituisci quanto segue:

   • cluster_name: il cluster elencato in resource.labels.cluster_name
   • location: la località indicata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il programma binario dannoso modificato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per memorizzare il file binario dannoso modificato.

6. Connettiti all'ambiente del contenitore:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, API nativa.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Execution: Modified Malicious Library Loaded

Una raccolta caricata, con la raccolta:

• Inclusi nell'immagine del contenitore originale.
• Modificati durante il runtime del container.
• Identificato come dannoso in base alle informazioni di Threat Intelligence.

I malintenzionati potrebbero caricare librerie dannose in programmi esistenti per aggirare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere a questo risultato:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Modified Malicious Library Loaded come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: il percorso completo del programma binario che ha caricato la biblioteca.
     • Librerie: i dettagli della libreria modificata.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Contenitori: il nome del contenitore interessato.
     • URI dei container: il nome dell'immagine del container di cui viene eseguito il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato nella riga Nome completo della risorsa della scheda Riepilogo dei dettagli del rilevamento e nello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Recupera la libreria dannosa modificata:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare la libreria malevola modificata.

6. Connettiti all'ambiente del contenitore:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso, Moduli condivisi.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Malicious Script Executed

Un modello di machine learning ha identificato il codice Bash eseguito come dannoso. Gli attaccanti possono utilizzare Bash per trasferire strumenti ed eseguire comandi senza binari. Garantire l'immutabilità dei contenitori è una best practice importante. L'utilizzo di script per il trasferimento di strumenti può imitare la tecnica di trasferimento di strumenti di ingresso dell'attaccante e comportare rilevamenti indesiderati.

Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Malicious Script Executed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Programma binario: dettagli sull'interprete che ha richiamato lo script.
     • Script: percorso assoluto del nome dello script sul disco. Questo attributo viene visualizzato solo per gli script scritti sul disco, non per l'esecuzione di script letterali, ad esempio bash -c.
     • Argomenti: gli argomenti forniti al momento dell'invocazione dello script.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa del cluster, inclusi il numero del progetto, la posizione e il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • finding:
     • processes:
     • script:
       • contents: i contenuti dello script eseguito, che potrebbero essere troncati per motivi di rendimento; questo può aiutarti nella tua indagine
       • sha256: l'hash SHA-256 di script.contents
   • resource:
     • project_display_name: il nome del progetto che contiene la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

5. Identifica altri risultati che si sono verificati in un momento simile per questo contenitore. Ad esempio, se lo script inserisce un file binario, controlla se sono presenti risultati correlati al file binario.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminal.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Command and Scripting Interpreter, Ingress Tool Transfer.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Se lo script stava apportando modifiche intenzionali al contenitore, ricostruisci l'immagine del contenitore in modo che non siano necessarie modifiche. In questo modo, il contenitore può essere immutabile.
• In caso contrario, contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Malicious URL Observed

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Container Threat Detection ha rilevato un URL dannoso nell'elenco degli argomenti di un processo eseguibile. Gli aggressori possono caricare malware o librerie dannose tramite URL dannosi.

Per rispondere a questo riscontro, svolgi i seguenti passaggi.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Malicious URL Observed come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • URI: l'URI dannoso osservato.
     • File binario aggiunto: il percorso completo del file binario del processo che ha ricevuto gli argomenti contenenti l'URL dannoso.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Variabili di ambiente: le variabili di ambiente attive al momento dell'invocazione del file binario del processo.
     • Containers: il nome del contenitore.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo risorsa: il nome completo della risorsa del cluster. Il nome completo della risorsa include le seguenti informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Il nome del cluster: projects/CLUSTER_NAME
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Nella scheda JSON, nell'attributo sourceProperties, tieni presente il valore della proprietà VM_Instance_Name.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto visualizzato in Nome completo della risorsa (resource.name), se necessario. Il nome del progetto viene visualizzato dopo /projects/ nel nome completo della risorsa.

3. Fai clic sul nome del cluster che hai annotato in Nome visualizzato della risorsa (resource.display_name) del riepilogo del rilevamento. Viene visualizzata la pagina Cluster.

4. Nella sezione Metadati della pagina **Dettagli cluster, prendi nota di eventuali informazioni definite dall'utente che potrebbero essere utili per risolvere la minaccia, ad esempio informazioni che identificano il proprietario del cluster.

5. Fai clic sulla scheda Nodi.

6. Dai nodi elencati, seleziona quello corrispondente al valore di VM_Instance_Name che hai annotato nel file JSON del rilevamento in precedenza.

7. Nella scheda Dettagli della pagina Dettagli nodo, nella sezione Annotazioni, prendi nota del valore dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel nome completo della risorsa (resource.name) del cluster nel riepilogo dei risultati, se necessario.

3. Fai clic su Mostra workload del sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo della risorsa (resource.name) del riepilogo del rilevamento e, se necessario, allo Spazio dei nomi (kubernetes.pods.ns) del pod che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore della proprietà VM_Instance_Name che hai annotato nel file JSON del rilevamento in precedenza. Viene visualizzata la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota di eventuali informazioni sul pod che potrebbero aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto visualizzato in Nome completo della risorsa (resource.name), se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log del pod per il tuo pod (kubernetes.pods.name) utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION"
      • resource.labels.cluster_name="CLUSTER_NAME"
      • resource.labels.namespace_name="NAMESPACE_NAME"
      • resource.labels.pod_name="POD_NAME"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="PROJECT_ID"
      • resource.labels.location="LOCATION_OR_ZONE"
      • resource.labels.cluster_name="CLUSTER_NAME/var>"
      • POD_NAME
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="INSTANCE_ID"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Fai clic sul nome del cluster mostrato in resource.labels.cluster_name.

3. Nella pagina Cluster, fai clic su Connetti e poi su Esegui in Cloud Shell.

   Cloud Shell avvia e aggiunge comandi per il cluster nel terminal.

4. Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.

5. Connettiti all'ambiente del contenitore eseguendo il seguente comando:

     kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
   

   Sostituisci CONTAINER_NAME con il nome del contenitore che hai annotato nel riepilogo del risultato in precedenza.

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

Passaggio 6: cerca metodi di attacco e risposta

1. Controlla lo stato del sito di Navigazione sicura per avere informazioni dettagliate sul motivo per cui l'URL è classificato come dannoso.
2. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Trasferimento di strumenti di ingresso.
3. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
4. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Reverse Shell

È stato avviato un processo di reindirizzamento dello stream a una socket connessa da remoto. L'attivazione di una shell connessa alla rete può consentire a un malintenzionato di eseguire azioni arbitrarie dopo una compromissione iniziale limitata. Per rispondere a questo riscontro:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Reverse Shell rilevamento come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • File binario del programma: il percorso assoluto del processo avviato con il reindirizzamento dello stream a una socket remota.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa del cluster.
     • Nome completo del progetto: il progetto Google Cloud interessato.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Nella visualizzazione dettagliata del rilevamento, fai clic sulla scheda JSON.

4. Nel JSON, prendi nota dei seguenti campi.

   • resource:
     • project_display_name: il nome del progetto che contiene la risorsa.
   • sourceProperties:
     • Pod_Namespace: il nome dello spazio dei nomi Kubernetes del pod.
     • Pod_Name: il nome del pod GKE.
     • Container_Name: il nome del contenitore interessato.
     • VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.
     • Reverse_Shell_Stdin_Redirection_Dst_Ip: l'indirizzo IP remoto della connessione
     • Reverse_Shell_Stdin_Redirection_Dst_Port: la porta remota
     • Reverse_Shell_Stdin_Redirection_Src_Ip: l'indirizzo IP locale della connessione
     • Reverse_Shell_Stdin_Redirection_Src_Port: la porta locale
     • Container_Image_Uri: il nome dell'immagine del contenitore in esecuzione.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Filtra in base al cluster elencato in resource.name e allo spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di eventuali metadati relativi al pod e al suo proprietario.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster di zona:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Avvia una shell nell'ambiente del contenitore eseguendo:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

   Per visualizzare tutti i processi in esecuzione nel contenitore, esegui il seguente comando nella shell del contenitore:

     ps axjf
   

   Questo comando richiede che nel contenitore sia installato /bin/ps.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Command and Scripting Interpreter, Ingress Tool Transfer.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Unexpected Child Shell

Container Threat Detection ha rilevato un processo che ha generato inaspettatamente un processo shell secondario. Questo evento potrebbe indicare che un malintenzionato sta tentando di utilizzare in modo improprio comandi e script shell.

Per rispondere a questo riscontro, svolgi i seguenti passaggi.

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Unexpected Child Shell come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Processo principale: il processo che ha creato in modo imprevisto il processo shell secondario.
     • Procedura figlio: il processo shell secondario.
     • Argomenti: gli argomenti forniti al file binario del processo shell secondario.
     • Variabili di ambiente: le variabili di ambiente del file binario del processo di shell secondario.
     • Containers: il nome del contenitore.
     • URI dei container: l'URI dell'immagine del container.
     • Pod Kubernetes: il nome e lo spazio dei nomi del pod.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome visualizzato della risorsa: il nome della risorsa interessata.
     • Nome completo risorsa: il nome completo della risorsa del cluster. Il nome completo della risorsa include le seguenti informazioni:
       • Il progetto che contiene il cluster: projects/PROJECT_ID
       • La località in cui si trova il cluster: zone/ZONE o locations/LOCATION
       • Il nome del cluster: projects/CLUSTER_NAME
   • Link correlati, in particolare i seguenti campi:
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.

3. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

+processes: un array contenente tutti i processi correlati al rilevamento. Questo array include il processo shell secondario e il processo principale. +resource: +project_display_name: il nome del progetto che contiene le risorse. +sourceProperties: +VM_Instance_Name: il nome del nodo GKE in cui è stato eseguito il pod.

Passaggio 2: controlla il cluster e il nodo

1. Nella console Google Cloud, vai alla pagina Cluster Kubernetes.

   Vai ai cluster Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name, se necessario.

3. Seleziona il cluster elencato in resource.name. Prendi nota di eventuali metadati relativi al cluster e al relativo proprietario.

4. Fai clic sulla scheda Nodi. Seleziona il nodo elencato in VM_Instance_Name.

5. Fai clic sulla scheda Dettagli e prendi nota dell'annotazione container.googleapis.com/instance_id.

Passaggio 3: rivedi il pod

1. Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.

   Vai a Carichi di lavoro Kubernetes

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel nome completo della risorsa (resource.name) del cluster nel riepilogo dei risultati, se necessario.

3. Fai clic su Mostra workload del sistema.

4. Filtra l'elenco dei carichi di lavoro in base al nome del cluster che hai annotato in Nome completo della risorsa (resource.name) del riepilogo del rilevamento e, se necessario, nello Spazio dei nomi (kubernetes.pods.ns) del pod che hai annotato.

5. Fai clic sul nome del carico di lavoro che corrisponde al valore della proprietà VM_Instance_Name che hai annotato nel file JSON del rilevamento in precedenza. Viene visualizzata la pagina Dettagli pod.

6. Nella pagina Dettagli pod, prendi nota di eventuali informazioni sul pod che potrebbero aiutarti a risolvere la minaccia.

Passaggio 4: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name.

3. Imposta Seleziona intervallo di tempo sul periodo di interesse.

4. Nella pagina che si carica, segui questi passaggi:

   1. Trova i log dei pod per Pod_Name utilizzando il seguente filtro:
      • resource.type="k8s_container"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • resource.labels.namespace_name="Pod_Namespace"
      • resource.labels.pod_name="Pod_Name"
   2. Trova i log di controllo del cluster utilizzando il seguente filtro:
      • logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
      • resource.type="k8s_cluster"
      • resource.labels.project_id="resource.project_display_name"
      • resource.labels.location="location"
      • resource.labels.cluster_name="cluster_name"
      • Pod_Name
   3. Trova i log della console del nodo GKE utilizzando il seguente filtro:
      • resource.type="gce_instance"
      • resource.labels.instance_id="instance_id"

Passaggio 5: esamina il contenitore in esecuzione

Se il contenitore è ancora in esecuzione, potrebbe essere possibile esaminare direttamente l'ambiente del contenitore.

1. Vai alla console Google Cloud.

   Apri la console Google Cloud

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in resource.project_display_name.

3. Fai clic su Attiva Cloud Shell.

4. Ottieni le credenziali GKE per il tuo cluster eseguendo i seguenti comandi.

   Per i cluster zonali, esegui il seguente comando:

     gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
   

   Per i cluster a livello di regione, esegui il seguente comando:

     gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
   

5. Per avviare una shell nell'ambiente del contenitore, esegui il seguente comando:

     kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
   

   Questo comando richiede che nel contenitore sia installata una shell in /bin/sh.

   Per visualizzare tutti i processi in esecuzione nel contenitore, esegui il seguente comando nella shell del contenitore:

     ps axjf
   

   Questo comando richiede che nel contenitore sia installato /bin/ps.

Passaggio 6: cerca metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di rilevamento: Interprete di comandi e script: shell Unix.
2. Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.
3. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE e l'analisi di VirusTotal.

Passaggio 7: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

• Contatta il proprietario del progetto con il contenitore compromesso.
• Interrompi o elimina il contenuto compromesso e sostituiscilo con un nuovo contenuto.

Risposta di VM Threat Detection

Per scoprire di più su VM Threat Detection, consulta la Panoramica di VM Threat Detection.

Defense Evasion: Rootkit

VM Threat Detection ha rilevato una combinazione di indicatori che corrispondono a un rootkit in modalità kernel noto in un'istanza VM di Compute Engine.

La categoria di risultati Defense Evasion: Rootkit è un superinsieme delle seguenti categorie di risultati. Pertanto, questa sezione si applica anche a queste categorie di risultati.

• Defense Evasion: Unexpected ftrace handler (Anteprima)
• Defense Evasion: Unexpected interrupt handler (Anteprima)
• Defense Evasion: Unexpected kernel code modification (Anteprima)
• Defense Evasion: Unexpected kernel modules (Anteprima)
• Defense Evasion: Unexpected kernel read-only data modification (Anteprima)
• Defense Evasion: Unexpected kprobe handler (Anteprima)
• Defense Evasion: Unexpected processes in runqueue (Anteprima)
• Defense Evasion: Unexpected system call handler (Anteprima)

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri il risultato come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Nome del rootkit kernel: il nome della famiglia del rootkit rilevato, ad esempio Diamorphine.
     • Pagine di codice kernel impreviste: indica se le pagine di codice kernel sono presenti in regioni di codice kernel o modulo in cui non sono previste.
     • Gestore chiamate di sistema imprevisto: indica se i gestori chiamate di sistema sono presenti in regioni di codice del kernel o del modulo in cui non sono previsti.

   • Risorsa interessata, in particolare il seguente campo:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Ad esempio, controlla la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella scheda Riepilogo dei dettagli del rilevamento, fai clic sul link nel campo Nome completo della risorsa.
2. Esamina i dettagli dell'istanza VM, tra cui le impostazioni di rete e di accesso.

Passaggio 4: ispeziona la VM interessata

Segui le istruzioni riportate in Controllare una VM per rilevare segni di manomissione della memoria del kernel.

Passaggio 5: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per la fuga dalla difesa.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 6: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Contatta il proprietario della VM.

2. Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.

3. Per l'analisi forense, ti consigliamo di eseguire il backup delle macchine virtuali e dei dischi permanenti. Per ulteriori informazioni, consulta le opzioni di protezione dei dati nella documentazione di Compute Engine.

4. Elimina l'istanza VM.

5. Per ulteriori accertamenti, ti consigliamo di utilizzare servizi di risposta agli incidenti come Mandiant.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection ha rilevato attività di mining di criptovalute abbinando gli hash della memoria dei programmi in esecuzione agli hash della memoria di software di mining di criptovalute noti.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un Execution: Cryptocurrency Mining Hash Match rilevamento, come indicato in Esaminare i rilevamenti. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Famiglia binaria: l'applicazione di criptovaluta rilevata.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Nomi dei processi: il nome del processo in esecuzione nell'istanza VM associato alle corrispondenze delle firme rilevate.

     VM Threat Detection è in grado di riconoscere le build del kernel delle principali distribuzioni Linux. Se riesce a riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del rilevamento. Se il Rilevamento minacce VM non riesce a riconoscere il kernel, ad esempio se il kernel è personalizzato, il campo processes del rilevamento non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

   • indicator
     • signatures:
       • memory_hash_signature: una firma corrispondente agli hash delle pagine della memoria.
       • detections
         • binary: il nome del file binario dell'applicazione di criptovaluta, ad esempio linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0.
         • percent_pages_matched: la percentuale di pagine in memoria che corrispondono a pagine di applicazioni di criptovalute note nel database di hash di pagine.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Ad esempio, controlla se ci sono attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella scheda Riepilogo dei dettagli del rilevamento, fai clic sul link nel campo Nome completo della risorsa.
2. Esamina i dettagli dell'istanza VM, tra cui le impostazioni di rete e di accesso.

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.

1. Contatta il proprietario della VM.

2. Verifica se l'applicazione è un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso del file binario dell'applicazione rilevata, esamina i valori nelle righe File binario del programma, Argomenti e Nomi processi nella scheda Riepilogo dei dettagli del rilevamento nella tua indagine.

   • Se i dettagli della procedura non sono disponibili, controlla se il nome binario della firma dell'hash della memoria può fornire indizi. Prendiamo in considerazione un file binario chiamato linux-x86-64_xmrig_2.14.1. Puoi utilizzare il comando grep per cercare file importanti nello spazio di archiviazione. Utilizza una parte significativa del nome binario nel pattern di ricerca, in questo caso xmrig. Esamina i risultati di ricerca.

   • Esamina i processi in esecuzione, in particolare quelli con un utilizzo elevato della CPU, per vedere se ce ne sono che non riconosci. Determina se le applicazioni associate sono applicazioni di miner.

   • Cerca nei file archiviati le stringhe comuni utilizzate dalle applicazioni di estrazione, ad esempio btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la documentazione relativa a ciascun software elencato.

3. Se stabilisci che l'applicazione è un'applicazione di mining e il relativo processo è ancora in esecuzione, interrompilo. Individua il file eseguibile in formato binario dell'applicazione nello spazio di archiviazione della VM ed eliminalo.

4. Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova.

Execution: Cryptocurrency Mining YARA Rule

VM Threat Detection ha rilevato attività di mining di criptovalute abbinando schemi di memoria, come le costanti proof-of-work, noti per essere utilizzati dal software di mining di criptovalute.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri un risultato Execution: Cryptocurrency Mining YARA Rule, come indicato in Esaminare i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:

     • Nome regola YARA: la regola attivata per i rilevatori YARA.
     • Programma binario: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti quando viene richiamato il file binario del processo.
     • Nomi dei processi: il nome dei processi in esecuzione nell'istanza VM associato alle corrispondenze delle firme rilevate.

     VM Threat Detection è in grado di riconoscere le build del kernel delle principali distribuzioni Linux. Se riesce a riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo processes del rilevamento. Se il Rilevamento minacce VM non riesce a riconoscere il kernel, ad esempio se il kernel è personalizzato, il campo processes del rilevamento non viene compilato.

   • Risorsa interessata, in particolare i seguenti campi:

     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

   • Link correlati, in particolare i seguenti campi:

     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione di MITRE ATT&CK.
     • Risultati correlati: link a eventuali risultati correlati.
     • Indicatore VirusTotal: link alla pagina di analisi di VirusTotal.
     • Chronicle: esegui il collegamento a Google SecOps.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Ad esempio, controlla se ci sono attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella scheda Riepilogo dei dettagli del rilevamento, fai clic sul link nel campo Nome completo della risorsa.
2. Esamina i dettagli dell'istanza VM, tra cui le impostazioni di rete e di accesso.

Passaggio 4: cerca i metodi di attacco e risposta

1. Esamina le voci del framework MITRE ATT&CK per Esecuzione.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca di MITRE.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta agli endpoint.

1. Contatta il proprietario della VM.

2. Verifica se l'applicazione è un'applicazione di mining:

   • Se sono disponibili il nome del processo e il percorso del file binario dell'applicazione rilevata, esamina i valori nelle righe File binario del programma, Argomenti e Nomi processi nella scheda Riepilogo dei dettagli del rilevamento nella tua indagine.

   • Esamina i processi in esecuzione, in particolare quelli con un utilizzo elevato della CPU, per vedere se ce ne sono che non riconosci. Determina se le applicazioni associate sono applicazioni di miner.

   • Cerca nei file archiviati le stringhe comuni utilizzate dalle applicazioni di estrazione, ad esempio btc.com, ethminer, xmrig, cpuminer e randomx. Per altri esempi di stringhe che puoi cercare, consulta Nomi di software e regole YARA e la documentazione relativa a ciascun software elencato.

3. Se stabilisci che l'applicazione è un'applicazione di mining e il relativo processo è ancora in esecuzione, interrompilo. Individua il file eseguibile in formato binario dell'applicazione nello spazio di archiviazione della VM ed eliminalo.

4. Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova.

Execution: cryptocurrency mining combined detection

Il rilevamento delle minacce VM ha rilevato più categorie di risultati in un solo giorno da una singola fonte. Una singola applicazione può attivare contemporaneamente Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Per rispondere a un rilevamento combinato, segui le istruzioni per la risposta sia per Execution: Cryptocurrency Mining YARA Rule sia per Execution: Cryptocurrency Mining Hash Match findings.

Malware: Malicious file on disk (YARA)

VM Threat Detection ha rilevato un file potenzialmente dannoso analizzando i dischi permanenti di una VM per rilevare firme di malware note.

Per rispondere a questi risultati:

Passaggio 1: esamina i dettagli del rilevamento

1. Apri la verifica Malware: Malicious file on disk (YARA) come indicato in Esaminare le verifiche. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.

2. Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome regola YARA: la regola YARA a cui è stata trovata una corrispondenza.
     • Files: l'UUID della partizione e il percorso relativo del file potenzialmente dannoso rilevato.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa dell'istanza VM interessata, incluso l'ID del progetto che la contiene.

3. Per visualizzare il JSON completo di questo rilevamento, fai clic sulla scheda JSON nella visualizzazione dettagliata del rilevamento.

4. Nel JSON, prendi nota dei seguenti campi:

   • indicator
     • signatures:
       • yaraRuleSignature: una firma corrispondente alla regola YARA che è stata trovata.

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log.

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che contiene l'istanza VM, come specificato nella riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del rilevamento.

3. Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Ad esempio, controlla se ci sono attività sospette o sconosciute e segni di credenziali compromesse.

Passaggio 3: controlla le autorizzazioni e le impostazioni

1. Nella scheda Riepilogo dei dettagli del rilevamento, fai clic sul link nel campo Nome completo della risorsa.
2. Esamina i dettagli dell'istanza VM, tra cui le impostazioni di rete e di accesso.

Passaggio 4: cerca i metodi di attacco e risposta

Controlla il valore dell'hash SHA-256 del file binario segnalato come dannoso su VirusTotal facendo clic sul link nell'indicatore VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file, URL, domini e indirizzi IP potenzialmente dannosi.

Passaggio 5: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato, ma potrebbe anche influire sulle operazioni. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i problemi rilevati.

1. Contatta il proprietario della VM.

2. Se necessario, individua ed elimina il file potenzialmente dannoso. Per ottenere l'UUID della partizione e il percorso relativo del file, fai riferimento al campo File nella scheda Riepilogo dei dettagli del rilevamento. Per facilitare il rilevamento e la rimozione, utilizza una soluzione di rilevamento e risposta degli endpoint.

3. Se necessario, interrompi l'istanza compromessa e sostituiscila con una nuova istanza.

   Nota: con il livello Security Command Center Enterprise, puoi eseguire questa azione anche tramite un playbook di risposta alle minacce.

4. Per l'analisi forense, ti consigliamo di eseguire il backup delle macchine virtuali e dei dischi permanenti. Per ulteriori informazioni, consulta le opzioni di protezione dei dati nella documentazione di Compute Engine.

5. Per ulteriori accertamenti, ti consigliamo di utilizzare servizi di risposta agli incidenti come Mandiant.

Risolvere le vulnerabilità correlate

Per evitare che le minacce si ripetano, rivedi e correggi i risultati relativi a vulnerabilità ed errori di configurazione correlati.

Per trovare eventuali risultati correlati:

1. Nella console Google Cloud, vai alla pagina Risultati del Security Command Center.

   Vai a Risultati

2. Esamina il rilevamento di minacce e copia il valore di un attributo che è probabile che venga visualizzato in qualsiasi rilevamento di vulnerabilità o di configurazione errata correlato, ad esempio l'indirizzo email principale o il nome della risorsa interessata.

3. Nella pagina Risultati, apri l'editor query facendo clic su Modifica query.

4. Fai clic su Aggiungi filtro. Si apre il menu Seleziona filtro.

5. Dall'elenco delle categorie di filtro sul lato sinistro del menu, seleziona la categoria contenente l'attributo che hai annotato nel rilevamento delle minacce.

   Ad esempio, se hai annotato il nome completo della risorsa interessata, seleziona Risorsa. I tipi di attributi della categoria Risorsa sono visualizzati nella colonna a destra, incluso l'attributo Nome completo.

6. Dagli attributi visualizzati, seleziona il tipo di attributo che hai rilevato nel rilevamento della minaccia. A destra si apre un riquadro di ricerca per i valori degli attributi che mostra tutti i valori trovati del tipo di attributo selezionato.

7. Nel campo Filtro, incolla il valore dell'attributo che hai copiato dal risultato della minaccia. L'elenco dei valori visualizzato viene aggiornato in modo da mostrare solo i valori corrispondenti al valore incollato.

8. Nell'elenco dei valori visualizzati, seleziona uno o più valori e fai clic su Applica. Il riquadro Risultati della query sui risultati si aggiorna per mostrare solo i risultati corrispondenti.

9. Se i risultati sono numerosi, filtrali selezionando filtri aggiuntivi dal riquadro Filtri rapidi.

   Ad esempio, per visualizzare solo i risultati della classe Vulnerability e Misconfiguration che contengono i valori degli attributi selezionati, scorri verso il basso fino alla sezione Classe di risultati del riquadro Filtri rapidi e seleziona Vulnerabilità e Configurazione errata.

Oltre agli indicatori di compromissione forniti da Google, gli utenti che sono clienti di Palo Alto Networks possono integrare l'intelligence sulle minacce di AutoFocus di Palo Alto Networks con Event Threat Detection. AutoFocus è un servizio di threat intelligence che fornisce informazioni sulle minacce alla rete. Per scoprire di più, visita la pagina AutoFocus nella console Google Cloud.

Risolvere le minacce

Risolvere i risultati di Event Threat Detection e Container Threat Detection non è semplice come correggere le configurazioni errate e le vulnerabilità identificate da Security Command Center.

Gli errori di configurazione e le violazioni della conformità identificano i punti deboli delle risorse che potrebbero essere sfruttati. In genere, gli errori di configurazione hanno correzioni note e facilmente implementabili, come l'attivazione di un firewall o la rotazione di una chiave di crittografia.

Le minacce differiscono dalle vulnerabilità in quanto sono dinamiche e indicano un possibile exploit attivo contro una o più risorse. Un consiglio di rimedio potrebbe non essere efficace per proteggere le tue risorse perché i metodi esatti utilizzati per realizzare lo sfruttamento potrebbero non essere noti.

Ad esempio, un rilevamento Added Binary Executed indica che un file binario non autorizzato è stato avviato in un contenitore. Un consiglio di base per la correzione potrebbe essere di mettere in quarantena il contenitore ed eliminare il file binario, ma ciò potrebbe non risolvere la causa alla base che ha consentito all'utente malintenzionato di eseguire il file binario. Per correggere l'exploit, devi scoprire in che modo l'immagine del container è stata danneggiata. Per determinare se il file è stato aggiunto tramite una porta configurata in modo errato o con altri mezzi, è necessaria un'indagine approfondita. Un analista con conoscenza approfondita del tuo sistema potrebbe dover esaminarlo per rilevare eventuali punti deboli.

Gli utenti malintenzionati attaccano le risorse utilizzando tecniche diverse, pertanto l'applicazione di una correzione per un exploit specifico potrebbe non essere efficace contro le varianti di quell'attacco. Ad esempio, in risposta a un Brute Force: SSH, potresti abbassare i livelli di autorizzazione per alcuni account utente per limitare l'accesso alle risorse. Tuttavia, le password deboli potrebbero comunque fornire un percorso di attacco.

L'ampiezza dei vettori di attacco rende difficile fornire passaggi di correzione che funzionino in tutte le situazioni. Il ruolo di Security Command Center nel tuo piano di sicurezza del cloud è identificare le risorse interessate quasi in tempo reale, indicarti le minacce che stai affrontando e fornire prove e contesto per aiutarti nelle indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni dettagliate dei risultati di Security Command Center per determinare i modi migliori per risolvere i problemi e proteggere le risorse da attacchi futuri.

Passaggi successivi

• Consulta la panoramica di Event Threat Detection per saperne di più sul servizio e sulle minacce che rileva.

• Consulta la panoramica di Container Threat Detection per scoprire come funziona il servizio.

• Consulta la panoramica di Virtual Machine Threat Detection per saperne di più sul servizio e sulle minacce che rileva.