Questo argomento offre indicazioni informali per aiutarti a indagare e a rispondere alle e utilizzare risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguendo questa procedura puoi capire cosa è successo durante una potenziale attaccare e sviluppare possibili risposte per le risorse interessate.
Non è garantito che le tecniche illustrate in questa pagina siano efficaci contro qualsiasi minacce precedenti, attuali o future che devi affrontare. Consulta la sezione Risoluzione dei problemi. per capire perché Security Command Center non forniscono indicazioni ufficiali di correzione per le minacce.
Prima di iniziare
Per visualizzare o modificare i ruoli IAM (Identity and Access Management) necessari, devi disporre di ruoli adeguati risultati e log e modificare le risorse Google Cloud. Se riscontri l'accesso in Security Command Center, chiedi assistenza all'amministratore e verifica Controllo dell'accesso per scoprire di più sui ruoli. A risolvere gli errori relativi alle risorse, leggere la documentazione relativa ai prodotti interessati.
Comprensione dei risultati delle minacce
Rilevamento delle minacce di eventi produce risultati sulla sicurezza abbinando gli eventi nel tuo log di Cloud Logging i flussi di dati agli indicatori di compromissione noti (IoC). IoC, sviluppati da sviluppatori interni Le origini della sicurezza di Google identificano potenziali vulnerabilità e attacchi. Event Threat Detection individua anche le minacce identificando avversari noti tattiche, tecniche e procedure nel flusso di logging e rilevando deviazioni dal comportamento passato della tua organizzazione o del tuo progetto. Se attivi Livello Premium di Security Command Center a livello di organizzazione, Event Threat Detection può anche analizzare i log di Google Workspace.
Rilevamento delle minacce di container genera risultati raccogliendo e analizzando i comportamenti osservati di basso livello il kernel guest dei container.
I risultati vengono scritti in Security Command Center. Se attivi Nel livello Premium di Security Command Center a livello di organizzazione, puoi anche configurare i risultati da scrivere in Cloud Logging.
Esame dei risultati
Per esaminare i risultati relativi alle minacce nella console Google Cloud, segui questi passaggi:
Nella console Google Cloud, vai alla pagina Risultati di Security Command Center.
Se necessario, seleziona il progetto, la cartella o dell'organizzazione.
Nella sezione Filtri rapidi, fai clic sul filtro appropriato da visualizzare il risultato di cui hai bisogno nella tabella Risultati della query dei risultati. Per Ad esempio, se selezioni Event Threat Detection o Container Threat Detection nella sottosezione Nome visualizzato origine, solo i risultati della e il servizio selezionato vengono visualizzati nei risultati.
La tabella viene completata con i risultati per l'origine selezionata.
Per visualizzare i dettagli di un risultato specifico, fai clic sul suo nome sotto
Category
Il riquadro dei dettagli del risultato si espande per visualizzare un riepilogo dei dettagli del risultato.Per visualizzare la definizione JSON del risultato, fai clic sulla scheda JSON.
I risultati forniscono i nomi e gli identificatori numerici delle risorse coinvolte in un incidente, insieme a variabili di ambiente e proprietà degli asset. Puoi utilizzare la modalità per isolare rapidamente le risorse interessate e determinare l'ambito potenziale di un evento.
Per aiutarti nella tua indagine, i risultati delle minacce contengono anche link alle le seguenti risorse esterne:
- ATTACCA ATTACCO del framework di destinazione. Il framework spiega le tecniche per gli attacchi al cloud risorse e fornisce indicazioni sulla correzione.
- VirusTotal un servizio di proprietà di Alphabet che fornisce il contesto sulle minacce file, URL, domini e indirizzi IP.
Le sezioni seguenti descrivono le potenziali risposte alle scoperte delle minacce.
Disattivazione dei risultati delle minacce
Dopo aver risolto un problema che ha attivato il rilevamento di una minaccia,
Security Command Center non imposta automaticamente lo stato del risultato
a INACTIVE
. Lo stato del risultato di una minaccia rimane ACTIVE
, a meno che tu non
impostare manualmente la proprietà state
su INACTIVE
.
Per un falso positivo, valuta la possibilità di lasciare lo stato del risultato
ACTIVE
e disattiva invece il risultato.
Per falsi positivi permanenti o ricorrenti, crea una regola di disattivazione. L'impostazione di una regola di disattivazione può ridurre il numero di risultati necessari da gestire, il che rende più facile identificare una vera minaccia quando si verifica.
Per una minaccia reale, prima di impostare lo stato del risultato su INACTIVE
,
eliminare la minaccia e completare un'indagine approfondita
rilevata la minaccia, la portata dell'intrusione e qualsiasi altro risultato correlato
e problemi.
Per disattivare un risultato o modificarne lo stato, consulta i seguenti argomenti:
Risposte di Event Threat Detection
Per saperne di più su Event Threat Detection, consulta come funziona Event Threat Detection.
Questa sezione non contiene risposte per i risultati generati da 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 le modifiche ai servizi Google Cloud che hanno avuto origine dalla indirizzi IP proxy, come gli indirizzi IP Tor.
Per rispondere a questi risultati, segui questi passaggi:
Passaggio 1: esamina i dettagli dei risultati
- Apri un risultato di
Evasion: Access from Anonymizing Proxy
, come indicato in Analisi dei risultati. Il riquadro per il risultato dei dettagli, in cui è visualizzata la scheda Riepilogo. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le elencati i valori nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email principale: l'account che ha apportato le modifiche (un account compromesso).
- IP: l'indirizzo IP del proxy dove vengono condotte le modifiche. da cui proviene.
- Risorsa interessata
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Se vuoi, fai clic sulla scheda JSON per visualizzare altri campi dei risultati.
Passaggio 2: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Proxy: proxy multi-hop.
- Contatta il proprietario dell'account nel campo
principalEmail
. Conferma se l'azione è stata condotta dal legittimo proprietario. - Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
Defense Evasion: Breakglass Workload Deployment Created
La metrica Breakglass Workload Deployment Created
viene rilevata esaminando Cloud Audit Logs
per vedere se esistono deployment per carichi di lavoro che usano il flag di deployment di emergenza per eseguire l'override
Controlli di Autorizzazione binaria.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Defense Evasion: Breakglass Workload Deployment Created
, come indicato in Revisione dei risultati. Il riquadro per dei dettagli dei risultati, con la scheda Riepilogo. 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: nome del pod e spazio dei nomi.
- Risorsa interessata, in particolare il seguente campo:
- .
- Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui in cui è stato eseguito il deployment.
- Link correlati:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
- Controlla il valore nel campo
protoPayload.resourceName
per identificare il una richiesta di firma del certificato specifica. Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Elusione della difesa: deployment di emergenza del carico di lavoro.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
Defense Evasion: Breakglass Workload Deployment Updated
La metrica Breakglass Workload Deployment Updated
viene rilevata esaminando Cloud Audit Logs
per vedere se ci sono aggiornamenti ai carichi di lavoro che usano il flag di deployment di emergenza per eseguire l'override.
Controlli di Autorizzazione binaria.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Defense Evasion: Breakglass Workload Deployment Updated
, come indicato in Revisione dei risultati. Il riquadro per dei dettagli dei risultati, con la scheda Riepilogo. 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: nome del pod e spazio dei nomi.
- Risorsa interessata, in particolare il seguente campo:
- .
- Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui è stato eseguito l'aggiornamento.
- Link correlati:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
- Controlla il valore nel campo
protoPayload.resourceName
per identificare il una richiesta di firma del certificato specifica. Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Elusione della difesa: deployment di emergenza del carico di lavoro.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
Defense Evasion: Manually Deleted Certificate Signing Request (CSR)
Qualcuno ha eliminato manualmente una richiesta di firma di certificato (CSR). I CSR sono rimossi automaticamente da un controller di garbage collection, ma i malintenzionati potrebbe eliminarli manualmente per eludere il rilevamento. Se il CSR eliminato riguardava un approvato e rilasciato, l’aggressore potenzialmente malintenzionato ora dispone di un metodo di autenticazione aggiuntivo per accedere al cluster. Le autorizzazioni associati al certificato variano in base all'argomento trattato. ma che possono avere grandi privilegi. Kubernetes non supporta i certificati revoca. Per maggiori dettagli, consulta il messaggio di log per questo avviso.
- Esamina gli audit log in Cloud Logging e avvisi aggiuntivi per altri
eventi correlati a questa CSR per determinare se la CSR era
approved
e Era prevista un'attività di creazione CSR da parte dell'entità. - Determina se esistono altri segnali di attività dannosa da parte del
nell'audit log di Cloud Logging. Ad esempio:
- L'entità che ha eliminato la richiesta di firma del certificato è diversa da quella che ha creato? o approvato?
- L'entità ha provato a richiedere, creare, approvare o eliminare altri CSR?
- Se non era prevista l'approvazione della CSR, o se viene considerata dannosa, un cluster richiederà la rotazione delle credenziali per invalidare il certificato. Rivedi 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.
Gli audit log vengono esaminati per rilevare modifiche ai perimetri dei Controlli di servizio VPC che comporterebbe una riduzione della protezione offerta da quel perimetro. La Ecco alcuni esempi:
- Un progetto viene rimosso da un perimetro
- Un criterio relativo al livello di accesso viene aggiunto a un perimetro esistente
- Uno o più servizi vengono aggiunti all'elenco di servizi accessibili
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Defense Evasion: Modify VPC Service Control
, come indicato in Analisi dei risultati. Il riquadro per il risultato dei dettagli, in cui è visualizzata la scheda Riepilogo. 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 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare il seguente campo:
Fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
sourceProperties
properties
name
: il nome del perimetro Controlli di servizio VPC che è stato modificatopolicyLink
: il link al criterio di accesso che controlla il perimetrodelta
: le modifiche,REMOVE
oADD
, a un perimetro che ha ridotto la sua protezionerestricted_resources
: i progetti che seguono le restrizioni di su questo perimetro. La protezione viene ridotta se rimuovi un progettorestricted_services
: i servizi a cui è vietata l'esecuzione dalle restrizioni di questo perimetro. La protezione viene ridotta se rimuovi un servizio limitatoallowed_services
: i servizi che possono essere eseguiti in base a questa limitazioni del perimetro. La protezione viene ridotta se aggiungi un servizio consentitoaccess_levels
: i livelli di accesso configurate per consentire l'accesso alle risorse all'interno del perimetro. Se aggiungi altri livelli di accesso, la protezione viene ridotta
Passaggio 2: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Trova i log delle attività di amministrazione relativi alle modifiche dei Controlli di servizio VPC utilizzando
i seguenti filtri:
protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: evasione della difesa: modifica del processo di autenticazione.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del criterio e del perimetro dei Controlli di servizio VPC.
- Valuta la possibilità di ripristinare le modifiche apportate al perimetro finché l'indagine completata.
- Valuta la possibilità di revocare i ruoli di Gestore contesto accesso sull'entità che ha modificato il perimetro finché l'indagine completata.
- Analizzare come sono state utilizzate le protezioni ridotte. Ad esempio, se "API BigQuery Data Transfer Service" attivato o aggiunto come servizio consentito, controlla chi ha iniziato a usare il servizio e cosa sta trasferendo.
Defense Evasion: Potential Kubernetes Pod Masquerading
Un utente ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella dei carichi di lavoro predefiniti creato da GKE per il normale funzionamento del cluster. Questa tecnica è chiamata mascheramento. Per ulteriori dettagli, vedi il messaggio di log per questo avviso.
- Verifica che il Pod sia legittimo.
- Determina se esistono altri segnali di attività dannosa dal pod o nell'audit log di Cloud Logging.
- Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
- Se l'entità è un account di servizio (IAM o Kubernetes), identificare l'origine dell'azione per determinarne la legittimità.
- Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.
Discovery: Can get sensitive Kubernetes object check
Un utente potenzialmente malintenzionato ha tentato di determinare quali oggetti sensibili
GKE su cui possono eseguire query utilizzando il comando kubectl
auth can-i get
. In particolare,
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 dei risultati
- Apri il risultato
Discovery: Can get sensitive Kubernetes object check
come di cui alla sezione Analisi dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di seguenti campi:
- Nella sezione Che cosa è stato rilevato:
- .
- Revisioni degli accessi Kubernetes: informazioni richieste per la revisione degli accessi,
in base alla
SelfSubjectAccessReview
: e la risorsa k8s. - Email principale: l'account che ha effettuato la chiamata.
- Revisioni degli accessi Kubernetes: informazioni richieste per la revisione degli accessi,
in base alla
- In Risorsa interessata:
- .
- Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
- In Link correlati:
- .
- URI Cloud Logging: link alle voci di Logging.
- Nella sezione Che cosa è stato rilevato:
Passaggio 2: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Nella pagina visualizzata, controlla se ci sono altre azioni intraprese 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Scoperta
- Confermare la sensibilità dell'oggetto sottoposto a query e determinare se sono presenti altri indicatori di attività dannose da parte dell'entità nei log.
Se l'account che hai annotato nella riga Email entità nella trovare i dettagli non è un account di servizio, contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine della revisione dell'accesso per determinarne legittimità.
Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments
Un utente ha creato un pod contenente comandi o argomenti comunemente associati con una shell inversa. Aggressori e utilizzare le shell inverse per espandere o mantenere l'accesso iniziale a un cluster per eseguire comandi arbitrari. Per ulteriori dettagli, consulta il messaggio di log relativo avviso.
- Verifica che il pod abbia un motivo legittimo per specificare questi comandi argomenti.
- Determina se esistono altri segnali di attività dannosa dal pod o nell'audit log di Cloud Logging.
- Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
- Se l'entità è un account di servizio (IAM o Kubernetes), identificare la legittimità di ciò che ha provocato l'esecuzione di questa operazione da parte dell'account di servizio azione
- Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.
Execution: Suspicious Exec or Attach to a System Pod
Qualcuno ha utilizzato i comandi exec
o attach
per ottenere una shell o eseguire un comando
su un container in esecuzione nello spazio dei nomi kube-system
. Questi metodi sono
utilizzate per scopi legittimi di debug. Tuttavia, kube-system
namespace
è destinato a oggetti di sistema creati da Kubernetes e
l'esecuzione del comando o la creazione della shell. Per ulteriori dettagli, vedi
il messaggio di log per questo avviso.
- Esamina gli audit log in Cloud Logging per determinare se era previsto attività dell'entità.
- Determina se esistono altri segnali di attività dannosa da parte del nei log.
Consulta le linee guida per l'utilizzo del principio del privilegio minimo per i ruoli RBAC e i ruoli dei cluster che hanno consentito questo accesso.
Exfiltration: BigQuery Data Exfiltration
I risultati restituiti da Exfiltration: BigQuery
Data Exfiltration
contengono una delle due possibili sottoregole. Ogni regola secondaria ha un
gravità diversa:
- Regola secondaria
exfil_to_external_table
con gravità =HIGH
:- .
- Una risorsa è stata salvata all'esterno dell'organizzazione o del progetto.
- Regola secondaria
vpc_perimeter_violation
con gravità =LOW
:- .
- I Controlli di servizio VPC hanno bloccato un'operazione di copia o un tentativo di accesso di risorse BigQuery.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Exfiltration: BigQuery Data Exfiltration
, come indicato in Analisi dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le elencati i valori nelle seguenti sezioni:
- Che cosa è stato rilevato:
- .
- Gravità: la gravità è
HIGH
per la regola secondaria.exfil_to_external_table
oLOW
per la regola secondariavpc_perimeter_violation
, - Email principale: l'account utilizzato per esfiltrare i dati.
- Origini di esfiltrazione: dettagli sulle tabelle da cui i dati è stato esfiltrato.
- Target di esfiltrazione: dettagli sulle tabelle in cui sono state esfiltrate sono stati archiviati.
- Gravità: la gravità è
- Risorsa interessata:
- .
- Nome completo risorsa: il nome completo della risorsa del progetto, una cartella o un'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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Chronicle: link a Google SecOps.
- Che cosa è stato rilevato:
Fai clic sulla scheda Proprietà sorgente ed esamina i campi visualizzati. in particolare:
detectionCategory
:subRuleName
:exfil_to_external_table
ovpc_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 esfiltrati.query
: la query SQL eseguita sul set di dati BigQuery.
Se vuoi, fai clic sulla scheda JSON per visualizzare l'elenco completo dei Proprietà JSON del risultato.
Passaggio 2: esamina in Google Security Operations
Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indaga sulle minacce e passa attraverso le entità correlate in un 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.
Vai alla pagina Risultati di Security Command Center nella console Google Cloud.
Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.
Nella sezione Nome visualizzato origine, seleziona Event Threat Detection.
La tabella si compila con i risultati di Event Threat Detection.
Nella tabella, sotto categoria, fai clic su un
Exfiltration: BigQuery Data Exfiltration
risultato. Il riquadro dei dettagli per il risultato si apre.Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Esegui indagini in Chronicle.
Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.
Utilizza le seguenti guide per condurre indagini in Google SecOps:
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina IAM .
Se necessario, seleziona il progetto elencato nel campo
projectId
nella alla ricerca di JSON.Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencate in Email entità e controlla quali autorizzazioni sono assegnate all'account.
Passaggio 4: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando i seguenti filtri:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Passaggio 5: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con dati esfiltrati.
- Valuta la possibilità di revocare le autorizzazioni per
userEmail
fino al termine dell'indagine. - Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi all'entità interessata
Set di dati BigQuery (
exfiltration.sources
eexfiltration.targets
). - Per scansionare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. In base alla quantità di informazioni, I costi di Sensitive Data Protection possono essere significativi. Segui le best practice per conservazione dei costi di Sensitive Data Protection sotto controllo.
- Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Exfiltration: BigQuery Data Extraction
L'esfiltrazione di dati da BigQuery viene rilevata esaminando l'audit per due scenari:
- Una risorsa viene salvata in un bucket Cloud Storage all'esterno della 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 Premium di Security Command Center: questo risultato è disponibile solo se il livello Standard è abilitato nella dell'organizzazione principale.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un risultato di
Exfiltration: BigQuery Data Extraction
, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le elencati i valori nelle seguenti sezioni:
- Che cosa è stato rilevato:
- .
- Email principale: l'account utilizzato per esfiltrare i dati.
- Origini di esfiltrazione: dettagli sulle tabelle da cui i dati è stato esfiltrato.
- Target di esfiltrazione: dettagli sulle tabelle in cui sono state esfiltrate sono stati archiviati.
- Risorsa interessata:
- .
- Nome completo risorsa: il nome della risorsa BigQuery. risorsa i cui dati sono stati esfiltrati.
- 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato:
Nel riquadro dei dettagli del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i 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 dati esfiltrati
Passaggio 2: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina IAM .
Se necessario, seleziona il progetto elencato nel campo
projectId
nella trovare JSON (dal Passaggio 1).Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencato in Email principale (dal Passaggio 1) e controllare quali autorizzazioni sono assegnate all'account.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando
i seguenti filtri:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
- Esamina i risultati correlati facendo clic sul link della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con dati esfiltrati.
- Valuta la possibilità di revocare le autorizzazioni per l'entità elencata nella riga Email entità nella Riepilogo dei dettagli dei risultati fino al completamento dell'indagine.
- Per fermare un'ulteriore esfiltrazione, aggiungere criteri IAM restrittivi ai set di dati BigQuery interessati, identificati nel campo Origini di esfiltrazione della scheda Riepilogo della trovare i dettagli.
- Per scansionare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. In base alla quantità di informazioni, I costi di Sensitive Data Protection possono essere significativi. Segui le best practice per conservazione dei costi di Sensitive Data Protection sotto controllo.
- Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
- Se sei il proprietario del bucket, valuta la possibilità di revocarlo come pubblico autorizzazioni di accesso.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Exfiltration: BigQuery Data to Google Drive
L'esfiltrazione di dati da BigQuery viene rilevata esaminando l'audit log per il seguente scenario:
- Una risorsa viene salvata in una cartella di Google Drive.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un risultato di
Exfiltration: BigQuery Data to Google Drive
, come di cui alla sezione Analisi dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, 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 su BigQuery tabella da cui sono stati esfiltrati i dati.
- Target di esfiltrazione: dettagli della destinazione su Google Drive.
- Risorsa interessata, tra cui:
- .
- Nome completo risorsa: il nome della risorsa BigQuery i cui dati erano esfiltrato.
- 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, tra cui:
Per ulteriori informazioni, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i 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 è stato esfiltrato dati
Passaggio 2: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina IAM .
Se necessario, seleziona il progetto elencato nel campo
projectId
nella trovare JSON (dal Passaggio 1).Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencato in
access.principalEmail
(dal Passaggio 1) e controllare quali autorizzazioni sono assegnate all'account.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando
i seguenti filtri:
protoPayload.methodName="Jobservice.insert"
protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato nella stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con dati esfiltrati.
- Valuta la possibilità di revocare le autorizzazioni per il
nel campo
access.principalEmail
fino al completamento dell'indagine. - Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi all'entità interessata
Set di dati BigQuery (
exfiltration.sources
). - Per scansionare i set di dati interessati per individuare informazioni sensibili, utilizza Sensitive Data Protection. Puoi anche inviare i dati di Sensitive Data Protection a Security Command Center. In base alla quantità di informazioni, I costi di Sensitive Data Protection possono essere significativi. Segui le best practice per conservazione dei costi di Sensitive Data Protection sotto controllo.
- Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Exfiltration: Cloud SQL Data Exfiltration
L'esfiltrazione di dati da Cloud SQL viene rilevata esaminando l'audit per due scenari:
- Dati dell'istanza live esportati in un bucket Cloud Storage all'esterno all'interno dell'organizzazione.
- I dati dell'istanza in tempo reale esportati in un bucket Cloud Storage di proprietà dell'organizzazione ed è accessibile pubblicamente.
Sono supportati tutti i tipi di istanza Cloud SQL.
Per le attivazioni a livello di progetto del livello Premium di Security Command Center: questo risultato è disponibile solo se il livello Standard è abilitato nella dell'organizzazione principale.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un risultato di
Exfiltration: Cloud SQL Data Exfiltration
, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo. 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'API Cloud SQL i cui dati sono stati esfiltrati.
- Destinazioni di esfiltrazione: dettagli sul Cloud Storage nel bucket in cui sono stati esportati i dati.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome della risorsa Cloud SQL i cui dati sono stati esfiltrati.
- 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON.
Nel JSON per il risultato, tieni presente i seguenti campi:
sourceProperties
:evidence
:sourceLogId
:projectId
: il progetto Google Cloud che contiene l'istanza Cloud SQL di origine.
properties
bucketAccess
: se il bucket Cloud Storage è pubblico accessibile o esterno all'organizzazioneexportScope
: 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
Nella console Google Cloud, vai alla pagina IAM .
Se necessario, seleziona il progetto dell'istanza elencato nella
projectId
nel file JSON dei risultati (dal Passaggio 1).Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencata nella riga Email principale nella scheda Riepilogo dell' dei risultati (dal Passaggio 1). Controlla cosa autorizzazioni assegnate all'account.
Passaggio 3: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging (dal passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. descritta nel Passaggio 1). Correlate i risultati hanno lo stesso tipo di risultato sullo stesso Cloud SQL in esecuzione in un'istanza Compute Engine.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con dati esfiltrati.
- Valuta la possibilità di revocare le autorizzazioni per
access.principalEmail
fino al termine dell'indagine. - Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alla delle istanze Cloud SQL interessate.
- Per limitare l'accesso e l'esportazione dall'API Cloud SQL Admin, utilizza Controlli di servizio VPC.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Exfiltration: Cloud SQL Restore Backup to External Organization
L'esfiltrazione di dati da un backup di Cloud SQL viene rilevata esaminando log di controllo per determinare se i dati dal backup sono stati ripristinati all'esterno dell'organizzazione o del progetto. Tutti Sono supportati i tipi di backup e istanza Cloud SQL.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un
Exfiltration: Cloud SQL Restore Backup to External Organization
come indicato in Revisione dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, 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.
- Destinazioni 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 risorsa: il nome della risorsa del backup che è stata ripristinato.
- Nome completo del progetto: il progetto Google Cloud che contiene dall'istanza Cloud SQL da cui è stato creato il backup.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Link correlati, in particolare i seguenti campi:
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
Fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
resource
:parent_name
: il nome della risorsa 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
Nella console Google Cloud, vai alla pagina IAM .
Se necessario, seleziona il progetto dell'istanza elencato nella Campo
projectId
nel JSON del risultato (dal Passaggio 1).Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencato in Email principale (dal Passaggio 1) e controllare quali autorizzazioni sono assegnate all'account.
Passaggio 3: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging (da Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Esfiltrazione da servizi web: esfiltrazione nello spazio di archiviazione Cloud.
- Per esaminare i risultati correlati, fai clic sul link nella riga Risultati correlati. (da Passaggio 1). I risultati correlati hanno lo stesso tipo di risultato su per la stessa istanza Cloud SQL.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con dati esfiltrati.
- Valuta la possibilità di revocare le autorizzazioni per l'entità elencato nella riga Email principale della scheda Riepilogo dei dettagli dei risultati fino al completamento dell'indagine.
- Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alla delle istanze Cloud SQL interessate.
- Per limitare l'accesso all'API Cloud SQL Admin, utilizza Controlli di servizio VPC.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Exfiltration: Cloud SQL Over-Privileged Grant
Rileva quando tutti i privilegi su un database PostgreSQL (o tutti funzioni o procedure in un database) vengono concesse a uno o più database utenti.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Exfiltration: Cloud SQL Over-Privileged Grant
come indicato in Revisione dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome visualizzato database: il nome del database nella Istanza Cloud SQL PostgreSQL interessata.
- Nome utente database: l'utente PostgreSQL che ha concesso i privilegi in eccesso.
- Query sul database: la query PostgreSQL eseguita che ha concesso ai privilegiati.
- Beneficiari database: i beneficiari dei privilegi overbroad.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome della risorsa Cloud SQL Istanza PostgreSQL interessata.
- Nome completo padre: il nome della risorsa Cloud SQL PostgreSQL.
- Nome completo del progetto: il progetto Google Cloud che contiene per l'istanza PostgreSQL di Cloud SQL.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: rivedi i privilegi del database
- Connettiti al database PostgreSQL.
- Elencare e mostrare i privilegi di accesso
per:
- .
- Database. Usa il metacomando
\l
o\list
e controllare quali privilegi sono assegnati al database elencato in Nome visualizzato del database (dal Passaggio 1). - Funzioni o procedure. Usa il metacomando
\df
e controllare quali privilegi sono assegnati per funzioni o procedure database elencato in Nome visualizzato del database (da Passaggio 1).
- Database. Usa il metacomando
Passaggio 3: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging (da Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
- In Esplora log, controlla i log PostgreSQL
pgaudit
, che registrano query eseguite sul database, utilizzando i seguenti filtri:protoPayload.request.database="var class="edit">database"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi web.
- Per determinare se sono necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
- Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari database fino al termine dell'indagine.
- Per limitare l'accesso al database (da Nome visualizzato del database di Passaggio 1, revoca non necessario delle autorizzazioni dei beneficiari (da Beneficiari database Passaggio 1.
Initial Access: Database Superuser Writes to User Tables
Rileva quando l'account super user del database Cloud SQL (postgres
)
per PostgreSQL e root
per MySQL) scrive sull'utente
tabelle. Il super user (un ruolo con un accesso molto ampio) in genere non dovrebbe
utilizzato per scrivere nelle tabelle degli utenti. È necessario utilizzare un account utente con accesso più limitato
per la normale attività quotidiana. Quando un super user scrive in una tabella utente, potrebbe
indicano che un aggressore ha aumentato i privilegi o ha compromesso
predefinito e sta modificando i dati. Potrebbe anche indicare normale,
pratiche non sicure.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un
Initial Access: Database Superuser Writes to User Tables
come indicato in Revisione dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome visualizzato database: il nome del database nella Istanza Cloud SQL PostgreSQL o MySQL interessata.
- Nome utente database: il super user.
- 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 Cloud SQL interessata.
- Nome completo padre: il nome della risorsa Cloud SQL in esecuzione in un'istanza Compute Engine.
- Nome completo del progetto: il progetto Google Cloud che contiene per 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su
il link in
cloudLoggingQueryURI
(dal Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL. - Controlla i log per i log pgaudit PostgreSQL o l'audit di Cloud SQL per MySQL
contenenti le query eseguite dal super user, usando i seguenti filtri:
protoPayload.request.user="SUPERUSER"
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi web.
- Per determinare se sono necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.
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 risultati.
Controlla gli utenti autorizzati a connettersi al database.
- Per PostgreSQL, consulta Creare e gestire utenti
- Per MySQL, consulta Gestire gli utenti con l'autenticazione integrata
Valuta la possibilità di cambiare la password del super user.
- 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 Concedi (comando)
- Per MySQL, consulta Controllo degli accessi 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
Rileva quando un utente potenzialmente malintenzionato ha usato uno dei seguenti elementi Kubernetes utenti o gruppi di utenti predefiniti per creare una nuova risorsa Kubernetes nel cluster:
system:anonymous
system:authenticated
system:unauthenticated
Questi utenti e gruppi sono generalmente anonimi. Un accesso basato sui ruoli l'associazione di controllo (RBAC) nel tuo cluster ha concesso all'utente l'autorizzazione a creare a queste risorse nel cluster.
Esamina la risorsa creata e l'associazione RBAC associata per assicurarti che l'associazione è necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori informazioni vedi il messaggio di log per questo risultato.
Per risolvere il problema, consulta Evita ruoli e gruppi predefiniti.
Initial Access: GKE resource modified anonymously from the internet
Rileva quando un utente potenzialmente malintenzionato ha usato uno dei seguenti elementi Kubernetes a utenti o gruppi di utenti predefiniti per modificare una risorsa Kubernetes nel cluster:
system:anonymous
system:authenticated
system:unauthenticated
Questi utenti e gruppi sono generalmente anonimi. Un accesso basato sui ruoli l'associazione di controllo (RBAC) nel tuo cluster ha concesso all'utente l'autorizzazione di modifica a queste risorse nel cluster.
Esamina la risorsa modificata e l'associazione RBAC associata per assicurarti che l'associazione è necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori informazioni vedi il messaggio di log per questo risultato.
Per risolvere il problema, consulta Evita ruoli e gruppi predefiniti.
Initial Access: Dormant Service Account Action
Rileva gli eventi in cui un servizio gestito dall'utente inattivo account ha attivato un'azione. In questo contesto, un account di servizio viene considerata inattiva se è rimasta inattiva per più di 180 giorni.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Initial Access: Dormant Service Account Action
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione 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 ha eseguito l'accesso dall'account di servizio.
- Nome metodo: il metodo chiamato
Passaggio 2: ricerca i metodi di attacco e di risposta
- Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
- Contatta il proprietario dell'account di servizio nel campo Email 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Initial Access: Dormant Service Account Key Created
Rileva gli eventi in cui un servizio gestito dall'utente inattivo dell'account. In questo contesto, un account di servizio viene considerata inattiva se è rimasta inattiva per più di 180 giorni.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Initial Access: Dormant Service Account Key Created
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione 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 dell'account di servizio inattivo appena creata
- Nome completo del progetto: il progetto in cui si trova l'account di servizio inattivo
Passaggio 2: ricerca i metodi di attacco e di risposta
- Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
- Contatta il proprietario del campo Email 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
- Annulla la convalida della chiave dell'account di servizio appena creata nel Pagina Account di servizio.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dall'assistenza clienti Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.
Initial Access: Leaked Service Account Key Used
Rileva gli eventi in cui una chiave dell'account di servizio divulgata viene utilizzata per autenticare un'azione. In questo contesto, una chiave dell'account di servizio divulgata è quella che è stata pubblicata nella rete internet pubblica. Ad esempio, spesso le chiavi degli account di servizio vengono pubblicate nel repository pubblico GitHub.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Initial Access: Leaked Service Account Key Used
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione Che cosa è stato rilevato:
- Email principale: l'account di servizio utilizzato in questa azione.
- Nome servizio: il nome dell'API del servizio Google Cloud a cui ha eseguito l'accesso dall'account di servizio.
- Nome metodo: il nome del metodo dell'azione
- Nome chiave 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 sulla rete internet pubblica 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
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging.
- Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto o la tua organizzazione.
Nella pagina visualizzata, 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 che hai annotato nella Campo Email entità nei dettagli del risultato. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore che hai annotato in Nel campo Nome chiave account di servizio nei dettagli del risultato.
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 risultati.
- Revocare immediatamente la chiave dell'account di servizio Pagina Account di servizio.
- Rimuovi la pagina web o il repository GitHub in cui è pubblicata la chiave dell'account di servizio.
- Potresti eliminare l'account di servizio compromesso.
- Ruota ed elimina tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dall'assistenza clienti Google Cloud.
Initial Access: Excessive Permission Denied Actions
Rileva gli eventi in cui un'entità attiva ripetutamente l'autorizzazione Autorizzazione negata in vari metodi e servizi.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Initial Access: Excessive Permission Denied Actions
come indicato in Revisione dei risultati. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori del parametro campi seguenti.
Nella sezione Che cosa è stato rilevato:
- Email entità: l'entità che ha generato più errori di autorizzazione negata.
- Nome 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
Nei dettagli del risultato, nella scheda Proprietà sorgente, prendi nota dei valori di nei campi JSON seguenti:
- 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 numero di tentativi non riusciti e l'ora in cui si è verificato l'ultimo errore. Vengono visualizzate al massimo 10 voci.
Passaggio 2: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging.
- Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.
Nella pagina visualizzata, trova i log correlati utilizzando il seguente filtro:
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
protoPayload.status.code=7
Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nella Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario dell'account nel campo Email entità. Conferma se l'azione è stata eseguita dal legittimo proprietario.
- Elimina le risorse di progetto create da quell'account, ad esempio quelle sconosciute Istanze Compute Engine, snapshot, account di servizio, utenti IAM e così via.
- Contatta il proprietario del progetto con l'account ed eventualmente eliminarlo o disattivarlo l'account.
Brute Force: SSH
Rilevamento della forza bruta di SSH su un host. Per rispondere ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un risultato di
Brute Force: SSH
, come indicato in Analisi dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:
Che cosa è stato rilevato, in particolare i seguenti campi:
- IP chiamante: l'indirizzo IP che ha 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Chronicle: link a Google SecOps.
Fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
sourceProperties
:evidence
:sourceLogId
: l'ID progetto e il timestamp per identificare la voce di logprojectId
: il progetto contenente il risultato
properties
:attempts
:Attempts
: il numero di tentativi di accessousername
: l'account che ha eseguito l'accessovmName
: il nome della macchina virtualeauthResult
: il risultato dell'autenticazione SSH
Passaggio 2: esamina in Google Security Operations
Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra le entità correlate in un 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.
Vai alla pagina Risultati di Security Command Center nella console Google Cloud.
Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.
Nella sezione Nome visualizzato origine, seleziona Event Threat Detection.
La tabella viene completata con i risultati per il tipo di origine selezionato.
Nella tabella, sotto categoria, fai clic su un risultato
Brute Force: SSH
. Si apre il riquadro dei dettagli del risultato.Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Esegui indagini in Chronicle.
Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.
Utilizza le seguenti guide per condurre indagini in Google SecOps:
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla Dashboard.
Seleziona il progetto specificato
projectId
.Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde al nome e alla zona in
vmName
. Rivedi ai dettagli dell'istanza, incluse le impostazioni di rete e accesso.Nel riquadro di navigazione, fai clic su Rete VPC, quindi su Firewall. Rimuovi o disattiva le regole firewall eccessivamente permissive sulla porta 22.
Passaggio 4: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging.
- Nella pagina visualizzata, trova i log di flusso VPC correlati all'IP
indicato nella riga Email entità nella sezione
Scheda Riepilogo dei dettagli dei risultati utilizzando il seguente filtro:
- .
logName="projects/projectId/logs/syslog"
labels."compute.googleapis.com/resource_name"="vmName"
Passaggio 5: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account locali.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati nella riga Risultati correlati della scheda Riepilogo dei dettagli dei risultati. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto a cui è stato eseguito il tentativo di forza bruta riuscito.
- Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disabilitazione delle chiavi SSH, consulta l'articolo Limitare le chiavi SSH da delle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi considera le esigenze della tua organizzazione prima di procedere.
- Usa l'autenticazione SSH solo con indirizzi autorizzati chiave.
- Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor in Security Command Center integrato Servizi . A seconda della quantità di informazioni, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
Credential Access: External Member Added To Privileged Group
Questo risultato non è disponibile per le attivazioni a livello di progetto.
Rileva l'aggiunta di un membro esterno a un gruppo Google con privilegi (un gruppo concessi autorizzazioni o ruoli sensibili). Per rispondere ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un
Credential Access: External Member Added To Privileged Group
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nel riquadro dei dettagli, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
groupName
: il gruppo Google in cui sono state apportate le modificheexternalMember
: il membro esterno appena aggiuntosensitiveRoles
: i ruoli sensibili associati a questo gruppo
Passaggio 2: esamina i membri del gruppo
Vai a Google Gruppi.
Fai clic sul nome del gruppo che vuoi esaminare.
Nel menu di navigazione, fai clic su Membri.
Se il membro esterno appena aggiunto non deve essere in questo gruppo, fai clic su la casella di controllo accanto al nome del membro, quindi seleziona
Rimuovi membro oppure Escludi membro.Per rimuovere i membri, devi essere un amministratore di Google Workspace oppure devi essere stato assegnato Con il ruolo Proprietario o Gestore nel gruppo Google. Per ulteriori informazioni, vedi Assegnare ruoli ai membri di un gruppo.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Se necessario, seleziona il progetto.
Nella pagina visualizzata, controlla i log per verificare la presenza di 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: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
- Per determinare se sono necessarie ulteriori azioni correttive, combina il tuo i risultati dell'indagine con la ricerca MITRE.
Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)
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 metodo utilizzato dagli hacker per creare un accesso permanente a un cluster compromesso. La le autorizzazioni associate al certificato variano a seconda dell'oggetto inclusi, ma che possono avere maggiori privilegi. Per maggiori dettagli, vedi il messaggio di log per questo avviso.
- Esamina gli audit log in Cloud Logging e altri avvisi per altri CSR
eventi correlati per determinare se la richiesta di firma del certificato è stata
approved
ed è stata emessa e se è stata emessa una richiesta CSR le azioni correlate sono attività previste dall'entità. - Determina se esistono altri segnali di attività dannosa da parte del
nell'audit log di Cloud Logging. Ad esempio:
- L'entità che ha tentato di approvare la CSR è diversa da quella chi li ha creati?
- L'entità ha provato a richiedere, creare, approvare o eliminare altri CSR?
- Se non era prevista l'approvazione della CSR, o se viene considerata dannosa, un cluster richiederà la rotazione delle credenziali per invalidare il certificato. Rivedi le indicazioni per eseguire una rotazione delle credenziali del cluster.
Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)
Una richiesta di firma di un certificato (CSR) è stata approvata manualmente da un utente. La creazione di un l'autenticazione del cluster è un metodo comune per consentire a utenti malintenzionati di creano un accesso permanente a un cluster compromesso. Le autorizzazioni associate certificati variano a seconda dell'argomento trattato, ma possono essere privilegiati. Per maggiori dettagli, consulta il messaggio di log per questo avviso.
- Esamina gli audit log in Cloud Logging e altri avvisi per altri CSR per determinare se le azioni relative a CSR sono attività previste l'entità.
- Determina se esistono altri segnali di attività dannosa da parte del
nell'audit log di Cloud Logging. Ad esempio:
- L'entità che ha approvato la richiesta di firma del certificato è diversa da quella che ha creato? ?
- Il CSR ha specificato un firmatario integrato? La richiesta approvata perché non soddisfaceva i criteri del firmatario?
- L'entità ha provato a richiedere, creare, approvare o eliminare altri CSR?
- Se non era prevista un'approvazione CSR o se viene stabilito che è dannosa, il cluster richiederà una rotazione delle credenziali per invalidare il certificato. Rivedi 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 con privilegi (un gruppo a cui sono stati concessi ruoli sensibili o autorizzazioni) è diventano accessibili al pubblico. Per rispondere a questo risultato, le seguenti:
Passaggio 1: esamina i dettagli dei risultati
Apri un
Credential Access: Privileged Group Opened To Public
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Fai clic sulla scheda JSON.
- Nel file JSON, tieni presente i seguenti campi.
groupName
: il gruppo Google in cui sono state apportate le modifichesensitiveRoles
: i ruoli sensibili associati a questo gruppowhoCanJoin
: l'impostazione relativa alla partecipazione del gruppo
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: esamina le impostazioni di accesso ai gruppi
Vai alla Console di amministrazione di Google Gruppi. Devi essere un account Google amministratore di Workspace per accedere alla console.
Nel riquadro di navigazione, fai clic su Directory, quindi seleziona Gruppi.
Fai clic sul nome del gruppo che vuoi esaminare.
Fai clic su Impostazioni di accesso quindi, in Chi può iscriversi al gruppo, rivedere l'impostazione di partecipazione del gruppo.
Nel menu a discesa, se necessario, modifica l'impostazione di partecipazione.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Se necessario, seleziona il progetto.
Nella pagina visualizzata, controlla i log per verificare la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:
protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
- Per determinare se sono necessarie ulteriori azioni correttive, combina il tuo i risultati dell'indagine con la ricerca MITRE.
Credential Access: Secrets Accessed in Kubernetes Namespace
Rileva quando un pod
default
Account di servizio Kubernetes
è stato utilizzato per accedere agli oggetti Secret nel cluster. Il cluster default
di Kubernetes
l'account di servizio non deve avere accesso agli oggetti Secret a meno che non
ha concesso l'accesso con un oggetto Role o un oggetto ClusterRole.
Credential Access: Sensitive Role Granted To Hybrid Group
Rileva la concessione di autorizzazioni o ruoli sensibili a un Gruppo Google con membri esterni. Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un
Credential Access: Sensitive Role Granted To Hybrid Group
come indicato in Revisione dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Fai clic sulla scheda JSON.
- Nel file JSON, tieni presente i seguenti campi.
groupName
: il gruppo Google in cui sono state apportate le modifichebindingDeltas
: i ruoli sensibili appena concessi a questo gruppo.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: esamina le autorizzazioni del gruppo
Vai alla pagina IAM nella console Google Cloud.
Nel campo Filtro, inserisci il nome dell'account indicato in
groupName
.Esamina i ruoli sensibili concessi al gruppo.
Se il ruolo sensibile appena aggiunto non è necessario, revocalo.
Devi disporre di autorizzazioni specifiche per gestire i ruoli nella tua organizzazione o nel tuo progetto. Per Per saperne di più, consulta Autorizzazioni obbligatorie.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Se necessario, seleziona il progetto.
Nella pagina visualizzata, controlla i log per verificare la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
- Per determinare se sono necessarie ulteriori azioni correttive, combina il tuo i risultati dell'indagine con la ricerca MITRE.
Malware: Cryptomining Bad IP
Il malware viene rilevato esaminando i log di flusso VPC e Cloud DNS log per le connessioni a indirizzi IP e domini di comando e controllo noti. A rispondi a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Malware: Cryptomining Bad IP
, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- IP di origine: il sospetto indirizzo IP del cryptomining.
- 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 disponibili.
- Protocollo: IANA di indirizzi IP associati 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella visualizzazione dettagliata del risultato, fai clic sulla scheda Proprietà sorgente.
Espandi le proprietà e annota i valori di progetto e istanza nella campo seguente:
instanceDetails
: prendi nota sia dell'ID progetto sia del nome del di Compute Engine. Vengono visualizzati l'ID progetto e il nome dell'istanza come mostrato nell'esempio seguente:/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato
properties_project_id
.Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde a
properties_sourceInstance
. Indaga l'istanza potenzialmente compromessa per verificare la presenza di malware.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
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.
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: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Compromissione delle risorse.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto che contiene malware.
- Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.
- Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
Initial Access: Log4j Compromise Attempt
Questo risultato viene generato quando Java Naming and Directory Interface (JNDI) ricerche all'interno delle intestazioni o dei parametri URL. Queste ricerche potrebbero indicare tentativi di sfruttamento di Log4Shell. Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Initial Access: Log4j Compromise Attempt
, come indicato in Revisione dei dettagli dei risultati. I dettagli del risultato si apre nella scheda Riepilogo.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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
properties
loadBalancerName
: il nome del bilanciatore del carico che ha ricevuto la ricerca JNDIrequestUrl
: 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 contiene una ricerca JNDI.
Passaggio 2: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nel campo URI Cloud Logging del passaggio 1.
Nella pagina visualizzata, verifica la presenza di token di stringa nei campi
httpRequest
. come${jndi:ldap://
, che potrebbero indicare possibili tentativi di sfruttamento.Vedi CVE-2021-44228: rilevamento dell'exploit Log4Shell nella documentazione di Logging per visualizzare esempi di stringhe da cercare per una query di esempio.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Sfruttare un'applicazione pubblica.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato la stessa istanza e la stessa rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Esegui l'upgrade all'ultima versione di Log4j2.
- Segui i suggerimenti di Google Cloud per indagare e rispondere su "Apache Log4j 2" vulnerabilità.
- Implementare le tecniche di mitigazione consigliate Vulnerabilità di sicurezza di Apache Log4j.
- Se utilizzi Google Cloud Armor, esegui il deployment di
cve-canary rule
in una nuova o un criterio di sicurezza di Google Cloud Armor esistente. Per ulteriori informazioni, vedi Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j.
Active Scan: Log4j Vulnerable to RCE
Gli scanner di vulnerabilità Log4j supportati inseriscono ricerche JNDI offuscate in HTTP parametri, URL e campi di testo con callback ai domini controllati scanner. Questo risultato viene generato quando eseguono query DNS per i domini non offuscati disponibili. Queste query si verificano solo se una ricerca JNDI ha avuto esito positivo, indicando è presente una vulnerabilità Log4j attiva. Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Active Scan: Log4j Vulnerable to RCE
, come indicato in Revisione dei dettagli dei risultati. I dettagli del risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato
- Risorsa interessata, in particolare il seguente campo:
- .
- Nome completo risorsa: nome completo della risorsa Istanza di Compute Engine vulnerabile all'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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
properties
scannerDomain
: il dominio utilizzato dallo scanner nell'ambito della JNDI . Indica quale scanner ha identificato la vulnerabilità.sourceIp
: l'indirizzo IP utilizzato per eseguire la query DNSvpcName
: il nome della rete nell'istanza in cui la query DNS è stato eseguito.
Passaggio 2: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nel campo URI Cloud Logging del passaggio 1.
Nella pagina visualizzata, verifica la presenza di token di stringa nei campi
httpRequest
. come${jndi:ldap://
, che potrebbero indicare possibili tentativi di sfruttamento.Vedi CVE-2021-44228: rilevamento dell'exploit Log4Shell nella documentazione di Logging per visualizzare esempi di stringhe da cercare per una query di esempio.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Sfruttamento di Servizi remoti.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Esegui l'upgrade all'ultima versione di Log4j2.
- Segui i suggerimenti di Google Cloud per indagare e rispondere su "Apache Log4j 2" vulnerabilità.
- Implementare le tecniche di mitigazione consigliate Vulnerabilità di sicurezza di Apache Log4j.
- Se utilizzi Google Cloud Armor, esegui il deployment di
cve-canary rule
in una nuova o un criterio di sicurezza di Google Cloud Armor esistente. Per ulteriori informazioni, vedi Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j.
Leaked credentials
Questo risultato non è disponibile per le attivazioni a livello di progetto.
Questo risultato viene generato quando si utilizzano le credenziali dell'account di servizio Google Cloud sono trapelati accidentalmente online o compromessi. Per rispondere a questo risultato, le seguenti:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
account_has_leaked_credentials
, come indicato in Revisione dei dettagli dei risultati. Riquadro dei dettagli del risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato
- Risorsa interessata
Fai clic sulla scheda Proprietà sorgente e prendi nota dei seguenti campi:
Compromised_account
: l'account di servizio potenzialmente compromessoProject_identifier
: il progetto che contiene la risorsa potenzialmente divulgata credenziali dell'accountURL
: il link al repository GitHub
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: rivedi le autorizzazioni del progetto e dell'account di servizio
Nella console Google Cloud, vai alla pagina IAM.
Se necessario, seleziona il progetto elencato in
Project_identifier
.Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencato in
Compromised_account
e controlla le autorizzazioni assegnate.Nella console Google Cloud, vai alla pagina Account di servizio.
Nella pagina visualizzata, nella casella Filtro, inserisci il nome del compromesso l'account di servizio e controlla le chiavi e la chiave date di creazione.
Passaggio 3: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il tuo progetto.
Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate. alle risorse IAM 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: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
- Esamina i risultati correlati facendo clic sul link in
relatedFindingURI
. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete. - Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con credenziali divulgate.
- Valuta la possibilità di eliminare l'account di servizio compromesso, esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli 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 proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere alle notifiche dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
- Apri il link
URL
ed elimina le credenziali divulgate. Raccogli di più informazioni sull'account compromesso e contattare il proprietario.
Malware
Il malware viene rilevato esaminando i log di flusso VPC e
Log di Cloud DNS per le connessioni a domini di comando e controllo noti
e gli indirizzi IP esterni. Attualmente, Event Threat Detection offre il rilevamento generale del malware
(Malware: Bad IP
e Malware: Bad Domain
) e rilevatori
in particolare per il malware correlato a Log4j (Log4j Malware: Bad IP
e
Log4j Malware: Bad Domain
).
I passaggi seguenti spiegano come indagare e per rispondere ai risultati basati sull'IP. I passaggi per la correzione sono simili per i risultati.
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato di malware pertinente. I passaggi seguenti utilizzano
Malware: Bad IP
risultato, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Dominio indicatore: per
Bad domain
risultati, il dominio che ha attivato il risultato. - IP indicatore: per
Bad IP
risultati, l'indirizzo IP che ha attivato il risultato. - IP di origine: per i risultati
Bad IP
, un comando malware noto e di controllo dell'indirizzo IP. - Porta di origine: per
Bad IP
risultati, la porta di origine della connessione. - IP di destinazione: per
Bad IP
risultati, l'indirizzo IP di destinazione del malware. - Porta di destinazione: per
Bad IP
risultati, la porta di destinazione della connessione. - Protocollo: per
Bad IP
risultati, il valore Protocollo IANA associato alla connessione.
- Dominio indicatore: per
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo della risorsa: il nome completo della risorsa interessata di Compute Engine.
- Nome completo del progetto: il nome completo della risorsa del progetto che che contiene il risultato.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Chronicle: link a Google SecOps.
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
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
: indirizzo della risorsa per Compute Engine in esecuzione in un'istanza Compute Engine.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: esamina in Google Security Operations
Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra le entità correlate in un 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.
Vai alla pagina Risultati di Security Command Center nella console Google Cloud.
Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.
Nella sezione Nome visualizzato origine, seleziona Event Threat Detection.
La tabella viene completata con i risultati per il tipo di origine selezionato.
Nella tabella, sotto categoria, fai clic sul risultato
Malware: Bad IP
. Si apre il riquadro dei dettagli per il risultato.Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Esegui indagini in Chronicle.
Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.
Utilizza le seguenti guide per condurre indagini in Google SecOps:
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato nella riga Nome completo del progetto nella scheda Riepilogo.
Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde al nome e alla zona Nome completo risorsa: Esamina i dettagli dell'istanza, incluse le impostazioni di rete e di accesso.
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
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Nella pagina visualizzata, trova i log di flusso VPC correlati all'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
selezionando il progetto in elenco nel mese diprojectId
.SOURCE_IP
con l'indirizzo IP indicato su alla riga IP di origine nella scheda Riepilogo dei dettagli del risultato.
Passaggio 5: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Dynamic Risoluzione e Comando e controllo.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
- Controlla gli URL e i domini segnalati su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto che contiene malware.
- Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Per tenere traccia delle attività e delle vulnerabilità che hanno consentito l’inserimento di malware, e controllare gli audit log e i syslog associati all'istanza compromessa.
- Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.
- Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
- Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza Shielded VM e Trusted IAM delle immagini .
Malware: Outgoing DoS
Event Threat Detection rileva il potenziale utilizzo di un'istanza per avviare un rifiuto di servizio (DoS) analizzando i log di flusso VPC. Per rispondere ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Malware: Outgoing DoS
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato
- .
- IP di origine: l'indirizzo IP di origine dell'attività DoS.
- Porta di origine: la porta di origine della connessione.
- IP di destinazione: l'indirizzo IP di destinazione dell'attività DoS.
- Porta di destinazione: la porta di destinazione della connessione.
- Risorsa interessata
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
- Nel file JSON, tieni presente i seguenti campi.
sourceInstanceDetails
: l'istanza VM di Compute Engine interessata
- Che cosa è stato rilevato
Passaggio 2: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato
sourceInstanceDetails
.Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde al nome e alla zona dell'istanza
sourceInstanceDetails
. Rivedi i dettagli dell'istanza, inclusa la rete e accedere alle impostazioni.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
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
Nella pagina visualizzata, trova i log di flusso VPC correlati all'IP indirizzo IP in
srcIP
utilizzando il seguente filtro:logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="srcIP" OR jsonPayload.connection.dest_ip="destIP")
Sostituisci quanto segue:
PROJECT_ID
con l'ID del progetto in cui è stato rilevato il problema.SOURCE_IP
con l'indirizzo IP elencato nel camposrcIP
nel file JSON del risultato.DESTINATION_IP
con l'indirizzo IP elencato nel campodestIp
nel file JSON del risultato.
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: denial of service di rete.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. della riga Risultati correlati della scheda Riepilogo del trovare i dettagli. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto che sta riscontrando traffico DoS in uscita.
- Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Per tenere traccia delle attività e delle vulnerabilità che hanno consentito l’inserimento di malware, e controllare gli audit log e i syslog associati all'istanza compromessa.
- Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.
- Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
- Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza Shielded VM e Trusted IAM delle immagini .
Persistence: IAM Anomalous Grant
Gli audit log vengono esaminati per rilevare l'aggiunta di IAM concessioni di ruoli (IAM) 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 risultato IAM Anomalous Grant
è unico in quanto include
regole secondarie che forniscono informazioni più specifiche su ciascuna istanza
di questo risultato. La classificazione della gravità di questo risultato dipende
sulla regola secondaria. Ogni regola secondaria potrebbe richiedere una risposta diversa.
Il seguente elenco mostra tutte le possibili regole secondarie e le relative gravità:
external_service_account_added_to_policy
:HIGH
, se è stato concesso un ruolo altamente sensibile o se è stata concessa una sensibilità media è stato concesso a livello di organizzazione. Per ulteriori informazioni, vedi Ruoli altamente sensibili.MEDIUM
, se è stato concesso un ruolo di sensibilità media. Per ulteriori informazioni, vedi Ruoli a sensibilità media.
external_member_invited_to_policy
:HIGH
external_member_added_to_policy
:HIGH
, se è stato concesso un ruolo altamente sensibile o se è stata concessa una sensibilità media è stato concesso a livello di organizzazione. Per ulteriori informazioni, vedi Ruoli altamente sensibili.MEDIUM
, se è stato concesso un ruolo di sensibilità media. Per ulteriori informazioni, vedi Ruoli a sensibilità media.
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 risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Persistence: IAM Anomalous Grant
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email principale: l'indirizzo email dell'account utente o di servizio che a cui è stato 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Chronicle: link a Google SecOps.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON. Viene visualizzato il file JSON completo del risultato.
Nel JSON per il risultato, tieni presente i seguenti campi:
detectionCategory
:subRuleName
: informazioni più specifiche sul tipo di si è verificata una concessione anomala. La regola secondaria determina la gravità classificazione di questo risultato.
evidence
:sourceLogId
:projectId
: l'ID del progetto che contiene il risultato.
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: esamina in Google Security Operations
Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra le entità correlate in un 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.
Vai alla pagina Risultati di Security Command Center nella console Google Cloud.
Nel riquadro Filtri rapidi, scorri verso il basso fino a Nome visualizzato dell'origine.
Nella sezione Nome visualizzato origine, seleziona Event Threat Detection.
La tabella viene completata con i risultati per il tipo di origine selezionato.
Nella tabella, sotto category, fai clic su un
Persistence: IAM Anomalous Grant
risultato. Il riquadro dei dettagli per si apre il risultato.Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su Esegui indagini in Chronicle.
Segui le istruzioni nell'interfaccia utente guidata di Google SecOps.
Utilizza le seguenti guide per condurre indagini in Google SecOps:
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Nella pagina visualizzata, cerca i ruoli IAM nuovi o aggiornati.
di risorse mediante i seguenti filtri:
protoPayload.methodName="SetIamPolicy"
protoPayload.methodName="google.iam.admin.v1.UpdateRole"
protoPayload.methodName="google.iam.admin.v1.CreateRole"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
- Esamina i risultati correlati facendo clic sul link in Risultati correlati. riga nella scheda Riepilogo dei dettagli del risultato. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e la rete.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con l'account compromesso.
- Elimina l'account di servizio compromesso, ruota ed elimina a tutte le chiavi di accesso degli 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 di progetto create da account non autorizzati, ad esempio quelli sconosciuti di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
- Per limitare l'aggiunta di utenti gmail.com, utilizza i Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Persistence: Impersonation Role Granted for Dormant Service Account
Rileva gli eventi in cui a un'entità viene concesso un ruolo di rappresentazione che consente che l'entità si spaccia per un servizio gestito dall'utente inattivo Google Cloud. In questo risultato, l'account di servizio inattivo è risorsa e un account di servizio è considerato inattivo se ha sono stati inattivi per più di 180 giorni.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Persistence: Impersonation Role Granted for Dormant Service Account
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione 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 si trova l'account di servizio inattivo
Passaggio 2: ricerca i metodi di attacco e di risposta
- Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
- Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati Fai clic sul link URI Cloud Logging 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
- Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dall'assistenza clienti Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.
Persistence: Unmanaged Account Granted Sensitive Role
Rileva gli eventi in cui un ruolo sensibile è stato concesso a un account non gestito Gli account non gestiti non possono essere controllati dagli amministratori di sistema. Ad esempio, quando il dipendente corrispondente ha lasciato l'azienda, l'amministratore non può eliminare l'account. Di conseguenza, la concessione di ruoli sensibili agli account non gestiti crea una potenziale rischi per la sicurezza dell'organizzazione.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Persistence: Unmanaged Account Granted Sensitive Role
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione Che cosa è stato rilevato:
- Email principale: l'utente che ha eseguito l'azione di concessione.
- Nome entità dell'accesso con problemi: l'account non gestito che riceve la concessione
- Concessione di accesso con accesso con problemi.Role concesso: il ruolo sensibile concesso.
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Verifica con il proprietario del campo Offending access grants.Principal name (Nome entità dell'accesso con problemi) a capire l'origine dell'account non gestito.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati Fai clic sul link URI Cloud Logging 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
- 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 spostare questo account sotto il controllo degli amministratori di sistema.
Persistence: New API Method
È stata rilevata un'attività amministrativa anomala da parte di un utente potenzialmente malintenzionato in un un'organizzazione, una cartella o un progetto. Le attività anomale possono essere:
- Nuova attività di un'entità in un'organizzazione, una cartella o un progetto
- Attività che non è stata visualizzata da un po' di tempo da un'entità in un'organizzazione, una cartella o un progetto
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Persistence: New API Method
come indicato in Analisi dei risultati. Nei dettagli del risultato, nella scheda Riepilogo, prendi nota dei valori dei seguenti campi:
- Nella sezione Che cosa è stato rilevato:
- .
- Email principale: l'account che ha effettuato la chiamata.
- Nome 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 può corrispondere a quello dell'organizzazione, della cartella o del progetto
- Percorso della risorsa: la posizione nella gerarchia delle risorse in cui si è verificata l'attività
- Nella sezione Che cosa è stato rilevato:
Passaggio 2: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Persistence.
- Verifica se l'azione era giustificata nell'organizzazione, nella cartella o nel progetto e se l'azione è stata intrapresa dal legittimo proprietario dell'account. L'organizzazione, la cartella o il progetto sono visualizzati nella riga Percorso risorsa, mentre l'account è visualizzato nella riga Email entità.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con la ricerca MITRE.
Persistence: New Geography
Questo risultato non è disponibile per le attivazioni a livello di progetto.
Un account utente o di servizio IAM sta accedendo a Google Cloud da una posizione anomala, in base alla geolocalizzazione dell'IP richiedente .
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Persistence: New Geography
, come indicato in Esaminando i dettagli dei risultati in precedenza, . Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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 la funzione account utente compromesso.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi
sourceProperties
:affectedResources
:gcpResourceName
: la risorsa interessata
evidence
:sourceLogId
:projectId
: l'ID del progetto che contiene il risultato.
properties
:anomalousLocation
:anomalousLocation
: la posizione attuale stimata dell'utente.callerIp
: indirizzo IP esterno.notSeenInLast
: il periodo di tempo utilizzato per stabilire una base di riferimento per un comportamento normale.typicalGeolocations
: le località da cui l'utente accede solitamente dell'accesso a specifiche risorse Google Cloud.
Passaggio 2: rivedi le autorizzazioni del progetto e dell'account
Nella console Google Cloud, vai alla pagina IAM.
Se necessario, seleziona il progetto elencato nel campo
projectID
nella alla ricerca di JSON.Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencati in Email principale e controlla i ruoli concessi.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Se necessario, seleziona il progetto.
- Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate.
alle risorse IAM 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: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con l'account compromesso.
- Esamina i
anomalousLocation
,typicalGeolocations
enotSeenInLast
per verificare se l'accesso è anomalo e se l'account è stato è stato compromesso. - Elimina le risorse di progetto create da account non autorizzati, ad esempio quelli sconosciuti di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
- Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitazione delle località delle risorse.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
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 uno user agent anomalo.
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Persistence: New User Agent
, come indicato in Esaminare i dettagli dei risultati in precedenza . Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email principale: l'account di servizio potenzialmente compromesso.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo del progetto: il progetto che contiene la funzione dell'account di servizio compromesso.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
- Nel file JSON, tieni presente i seguenti campi.
projectId
: il progetto che contiene la risorsa potenzialmente compromessa l'account di servizio.callerUserAgent
: lo user agent anomalo.anomalousSoftwareClassification
: il tipo di software.notSeenInLast
: il periodo di tempo utilizzato per stabilire una base di riferimento per la normalità comportamento degli utenti.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: rivedi le autorizzazioni del progetto e dell'account
Nella console Google Cloud, vai alla pagina IAM.
Se necessario, seleziona il progetto elencato in
projectId
.Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencata nella riga Email entità nella scheda Riepilogo dei dettagli dei risultati e controllare i ruoli concessi.
Nella console Google Cloud, vai alla pagina Account di servizio.
Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencata nella riga Email entità nella scheda Riepilogo dei dettagli del risultato.
Controlla le chiavi e le date di creazione delle chiavi dell'account di servizio.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Se necessario, seleziona il progetto.
- Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate.
alle risorse IAM 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: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con l'account compromesso.
- Esamina i
anomalousSoftwareClassification
,callerUserAgent
ebehaviorPeriod
per verificare se l'accesso è anomalo e se dell'account è stato compromesso. - Elimina le risorse di progetto create da account non autorizzati, ad esempio quelli sconosciuti di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
- Per limitare la creazione di nuove risorse a regioni specifiche, consulta Limitazione delle località delle risorse.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects
Per eseguire l’escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di modificare un
Accesso basato sui ruoli ClusterRole
, RoleBinding
o ClusterRoleBinding
di controllo (RBAC) dell'oggetto cluster-admin
sensibile
utilizzando una richiesta PUT
o PATCH
.
Passaggio 1: esamina i dettagli dei risultati
Apri
Privilege Escalation: Changes to sensitive Kubernetes RBAC objects
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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: i nodi Kubernetes sensibili
associazione o
ClusterRoleBinding
modificata.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella sezione Che cosa è stato rilevato, fai clic sul nome dell'associazione. nella riga Associazioni Kubernetes. Vengono visualizzati i dettagli dell'associazione.
Prendi nota dei relativi dettagli nell'associazione visualizzata.
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
Se il valore in Nome metodo era un metodo
PATCH
, controlla la richiesta corpo del messaggio per vedere quali proprietà sono state modificate.Nelle chiamate
update
(PUT
), l'intero oggetto viene inviato nel campo perché le modifiche non sono così chiare.Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento dei privilegi
- Conferma la sensibilità dell'oggetto sottoposto a query e se la modifica è giustificata.
- Per le associazioni, puoi controllare l'oggetto e verificare se e deve avere il ruolo a cui è associato.
- Determina se esistono altri segnali di attività dannosa da parte del nei log.
Se l'email dell'entità non è un account di servizio, contatta il proprietario per verificare se l'azione sia stata eseguita dal legittimo proprietario.
Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identificare l'origine della modifica per determinarne legittimità.
Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
Privilege Escalation: Create Kubernetes CSR for master cert
Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha creato un master Kubernetes
richiesta di firma del certificato
(CSR), che offre agli utenti cluster-admin
l'accesso.
Passaggio 1: esamina i dettagli dei risultati
Apri
Privilege Escalation: Create Kubernetes CSR for master cert
come indicato in Revisione dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 viene eseguita l'azione si è verificato un errore.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
- Controlla il valore nel campo
protoPayload.resourceName
per identificare il una richiesta di firma del certificato specifica. Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento dei privilegi.
- Verifica se l'accesso a
cluster-admin
era garantito. Se l'email dell'entità non è un account di servizio, contatta il proprietario per verificare se l'azione sia stata eseguita dal legittimo proprietario.
Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne legittimità.
Per sviluppare un piano di risposta, combina i risultati della tua indagine con 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 cluster-admin
ruolo.
Passaggio 1: esamina i dettagli dei risultati
Apri
Privilege Escalation: Creation of sensitive Kubernetes bindings
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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: i nodi Kubernetes sensibili
associazione o
ClusterRoleBinding
creata.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome visualizzato della risorsa: il cluster Kubernetes in cui viene eseguita l'azione si è verificato un errore.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento dei privilegi.
- Conferma la sensibilità dell'associazione creata e se i ruoli sono necessari per i soggetti.
- Per le associazioni, puoi controllare l'oggetto e verificare se e deve avere il ruolo a cui è associato.
- Determina se esistono altri segnali di attività dannosa da parte del nei log.
Se l'email dell'entità non è un account di servizio, contatta il proprietario per verificare se l'azione sia stata eseguita dal legittimo proprietario.
Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne legittimità.
Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access
Un utente 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 generalmente anonimi e devono essere evitati quando creando associazioni di ruoli o ruoli cluster a qualsiasi ruolo RBAC. Esamina il per garantirne la necessità. Se l'associazione non è necessaria, rimuovi li annotino. Per ulteriori dettagli, consulta il messaggio di log relativo a questo risultato.
- Esamina le eventuali associazioni create che hanno concesso autorizzazioni agli
system:anonymous
utente,system:unauthenticated group
o Grupposystem:authenticated
. - Determina se esistono altri segnali di attività dannosa da parte del nell'audit log di Cloud Logging.
Se vengono rilevati segnali di attività dannose, consulta le linee guida 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 un certificato
di firma del cliente (CSR), con il comando kubectl
, utilizzando
le 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 dei risultati
Apri
Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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 viene eseguita l'azione si è verificato un errore.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: controlla i log
Se il nome del metodo, che hai annotato nel campo Nome metodo nel risultato
, è un metodo GET
, segui questi passaggi:
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
- Controlla il valore nel campo
protoPayload.resourceName
per identificare il una richiesta di firma del certificato specifica.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento dei privilegi.
- Se il CSR specifico è disponibile nel voce di log, esamina la sensibilità della voce certificato e se l'azione era giustificata.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
Privilege Escalation: Launch of privileged Kubernetes container
Un utente potenzialmente malintenzionato ha creato un pod contenente o container con funzionalità di escalation dei privilegi.
Il campo privileged
di un container con privilegi è impostato su
true
. Un container con funzionalità di escalation dei privilegi ha
Campo allowPrivilegeEscalation
impostato su true
. Per ulteriori informazioni
consulta la sezione SecurityContext
v1 core nella documentazione di Kubernetes.
Passaggio 1: esamina i dettagli dei risultati
Apri
Privilege Escalation: Launch of privileged Kubernetes container
come indicato in Revisione dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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 viene eseguita l'azione si è verificato un errore.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella scheda JSON, prendi nota dei valori dei campi dei risultati:
- findings.kubernetes.pods[].containers: il container con privilegi attivato all'interno del pod.
Passaggio 2: controlla i log
- Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI Cloud Logging.
Verifica altre azioni intraprese dall'entità utilizzando quanto segue filtri:
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
Sostituisci quanto segue:
CLUSTER_NAME
: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.PRINCIPAL_EMAIL
: il valore annotato nell'attributo Campo Email entità nei dettagli del risultato.
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Aumento dei privilegi.
- Conferma che il container creato richieda l'accesso alle risorse dell'host e e le funzionalità del kernel.
- Determina se esistono altri segnali di attività dannosa da parte del nei log.
Se l'email dell'entità non è un servizio contatta il proprietario dell'account per verificare se si tratta di un'entità legittima l'azione non è stata eseguita dal proprietario.
Se l'email dell'entità è un account di servizio (IAM o Kubernetes), identifica l'origine dell'azione per determinarne legittimità.
Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
Privilege Escalation: Dormant Service Account Granted Sensitive Role
Rileva gli eventi in cui un ruolo IAM sensibile viene concesso a un servizio gestito dall'utente inattivo Google Cloud. In questo contesto, un account di servizio viene considerata inattiva se è rimasta inattiva per più di 180 giorni.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Privilege Escalation: Dormant Service Account Granted Sensitive Role
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.
Nella sezione Che cosa è stato rilevato:
- Email principale: l'utente che ha eseguito l'azione di concessione.
- Offending access Grants.Principal name: l'account di servizio inattivo che ha ricevuto il ruolo sensibile.
- Concedi accesso con problemi. Ruolo concesso: il ruolo IAM sensibile assegnato.
In Risorsa interessata:
- Nome visualizzato della risorsa: l'organizzazione, la cartella o il progetto in cui è stato concesso il ruolo IAM sensibile all'account di servizio inattivo.
Passaggio 2: ricerca i metodi di attacco e di risposta
- Utilizza l'account di servizio di Google, come Attività Analizzatore, per esaminare l'attività dell'account di servizio inattivo.
- Contatta il proprietario del campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro dei dettagli del risultato, nella sezione Link correlati Fai clic sul link URI Cloud Logging 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
- Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dall'assistenza clienti Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
La rappresentazione anomala dell'account di servizio viene rilevata esaminando l'amministratore Audit log delle attività per vedere se si è verificata un'anomalia in un account di servizio di impersonificazione.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato
Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity
, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud.
- Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
- 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 è il chiamante la richiesta di impersonificazione.
- 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
- Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.
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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity
Il parametro Anomalous Multistep Service Account Delegation
viene rilevato esaminando
Audit log delle attività di amministrazione per verificare se si sono verificate anomalie in un account di servizio
di impersonificazione.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato
Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity
, come indicato in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud.
- Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
- 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 è il chiamante la richiesta di impersonificazione.
- Risorsa interessata
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
- Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.
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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access
Anomalous Multistep Service Account Delegation
viene rilevato esaminando i dati
Accedi agli audit log per vedere se si sono verificate anomalie in un account di servizio
di impersonificazione.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato
Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access
, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
- Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
- 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 è il chiamante la richiesta di impersonificazione
- Risorsa interessata
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
- Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.
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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity
Rilevamento di Anomalous Service Account Impersonator
tramite l'esame dell'amministratore
Audit log delle attività per vedere se si è verificata un'anomalia in un account di servizio
di impersonificazione.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato
Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity
, come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
Che cosa è stato rilevato, in particolare i seguenti campi:
- Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
- Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
- 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 è il chiamante la richiesta di impersonificazione
Risorsa interessata
Link correlati, in particolare i seguenti campi:
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
- Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.
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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.
Privilege Escalation: Anomalous Service Account Impersonator for Data Access
Il furto d'identità anomalo dell'account di servizio viene rilevato esaminando l'accesso ai dati Audit log per vedere se si è verificata un'anomalia nella rappresentazione di un account di servizio richiesta.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Aperto
Privilege Escalation: Anomalous Service Account Impersonator for Data Access
come indicato in Revisione dei risultati. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori seguenti campi.
Nella sezione Che cosa è stato rilevato:
- Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
- Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
- 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 è il chiamante la richiesta di impersonificazione
Passaggio 2: ricerca i metodi di attacco e di risposta
- Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
- Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
- Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.
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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
- Per limitare gli utenti che possono creare account di servizio, utilizza Servizio Criteri dell'organizzazione.
- Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.
Privilege Escalation: ClusterRole with Privileged Verbs
Qualcuno ha creato un oggetto ClusterRole
RBAC contenente l'elemento bind
, escalate
o
impersonate
verbi. Un soggetto associato a un ruolo con questi verbi può
rubare l'identità di altri utenti con privilegi più elevati, associarsi a Role
aggiuntivi
o ClusterRole
oggetti che contengono autorizzazioni aggiuntive, oppure puoi modificarne
Autorizzazioni ClusterRole
. Ciò potrebbe portare questi soggetti
cluster-admin
privilegi. Per ulteriori dettagli, consulta il messaggio di log relativo
avviso.
- Esamina
ClusterRole
eClusterRoleBindings
associato per verificare se i soggetti hanno effettivamente bisogno di queste autorizzazioni. - Se possibile, evita di creare ruoli che coinvolgano
bind
,escalate
o Verbiimpersonate
. - Determina se esistono altri segnali di attività dannosa da parte del nell'audit log di Cloud Logging.
- Quando si assegnano le autorizzazioni in un ruolo RBAC, utilizza il principio del e concedere le autorizzazioni minime necessarie per eseguire un'attività. Utilizzo il principio del privilegio minimo riduce il potenziale di privilegio una escalation se il cluster è compromesso e riduce la probabilità un accesso eccessivo può causare un incidente di sicurezza.
Privilege Escalation: ClusterRoleBinding to Privileged Role
Qualcuno ha creato un ClusterRoleBinding
RBAC che fa riferimento al valore predefinito
system:controller:clusterrole-aggregation-controller
ClusterRole
. Questo
Il valore predefinito ClusterRole
ha il verbo escalate
, che consente ai soggetti di modificare
i privilegi dei propri ruoli, consentendo l'escalation dei privilegi. Per ulteriori informazioni
vedi il messaggio di log per questo avviso.
- Esamina tutti i
ClusterRoleBinding
che fanno riferimento aisystem:controller:clusterrole-aggregation-controller
ClusterRole
. - Rivedi eventuali modifiche
system:controller:clusterrole-aggregation-controller
:ClusterRole
. - Determina se esistono altri segnali di attività dannosa da parte del
l'entità che ha creato
ClusterRoleBinding
negli audit log in in Cloud Logging.
Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape
Un utente ha eseguito il deployment di un pod con una convenzione di denominazione simile a quella degli strumenti comuni utilizzati o per eseguire altri attacchi sul cluster. Per ulteriori dettagli, vedi il messaggio di log per questo avviso.
- Verifica che il Pod sia legittimo.
- Determina se esistono altri segnali di attività dannosa dal pod o nell'audit log di Cloud Logging.
- Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
- Se l'entità è un account di servizio (IAM o Kubernetes), identificare l'origine dell'azione per determinarne la legittimità.
- Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.
Privilege Escalation: Workload Created with a Sensitive Host Path Mount
Qualcuno ha creato un carico di lavoro contenente un montaggio del volume hostPath
in una
di un percorso sensibile nel file system del nodo host. Accesso a questi percorsi sull'host
file system può essere utilizzato per accedere a informazioni riservate o sensibili sul
e per gli escape dei container. Se possibile, non consentire alcun volume hostPath
nel tuo cluster. Per maggiori dettagli, consulta il messaggio di log per questo avviso.
- Esamina il carico di lavoro per determinare se questo volume
hostPath
è necessario per la funzionalità prevista. In caso affermativo, assicurati che il percorso sia una directory specifica. Ad esempio,/etc/myapp/myfiles
anziché/
o/etc
. - Determina se esistono altri segnali di attività dannose correlati a questo per il carico di lavoro negli audit log di Cloud Logging.
Per bloccare i montaggi di volumi hostPath
nel cluster, consulta le linee guida per l'applicazione degli standard di sicurezza dei pod.
Privilege Escalation: Workload with shareProcessNamespace enabled
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 di processo Linux. Questo
potrebbe consentire a un container non attendibile o compromesso di aumentare i privilegi
accedere e controllare le variabili di ambiente, la memoria e altri
provenienti da processi in esecuzione in altri container. Alcuni carichi di lavoro potrebbero richiedere
il funzionamento di questa funzionalità per motivi legittimi, come la gestione dei log
di container collaterali o di debug. Per maggiori dettagli, consulta il log
per questo avviso.
- Conferma che il carico di lavoro richieda effettivamente l'accesso a un processo condiviso per tutti i container nel carico di lavoro.
- Controlla se esistono altri segnali di attività dannosa da parte dell’entità nel gli audit log di Cloud Logging.
- Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se è stata un'azione.
- Se l'entità è un account di servizio (IAM o Kubernetes), identificare la legittimità di ciò che ha provocato l'esecuzione di questa operazione da parte dell'account di servizio un'azione.
Service account self-investigation
Le credenziali di un account di servizio vengono utilizzate per esaminare i ruoli autorizzazioni associate allo stesso account di servizio. Questo risultato indica le credenziali dell'account di servizio potrebbero essere compromesse e l'azione immediata deve essere preso.
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Discovery: Service Account Self-Investigation
, come indicato in Esaminare i dettagli dei risultati in precedenza . Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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. Gravità
è
HIGH
se la chiamata API che ha attivato questo risultato è non autorizzato: l'account di servizio non dispone dell'autorizzazione per interroga le proprie autorizzazioni IAM con APIprojects.getIamPolicy
. - Email principale: l'account di servizio potenzialmente compromesso.
- IP chiamante: indirizzo IP interno o esterno
- Gravità: il livello di rischio assegnato al risultato. Gravità
è
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa:
- Nome completo del progetto: il progetto che contiene la risorsa potenzialmente divulgata le credenziali dell'account.
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link alle voci di Logging.
- Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: rivedi le autorizzazioni del progetto e dell'account di servizio
Nella console Google Cloud, vai alla pagina IAM.
Se necessario, seleziona il progetto elencato nel campo
projectID
della alla ricerca di JSON.Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencate in Email principale e controlla le autorizzazioni assegnate.
Nella console Google Cloud, vai alla pagina Account di servizio.
Nella pagina visualizzata, nella casella Filtro, inserisci il nome del compromesso l'account di servizio e controlla le chiavi e la chiave date di creazione.
Passaggio 3: controlla i log
- Nella scheda Riepilogo del riquadro con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.
- Se necessario, seleziona il progetto.
- Nella pagina visualizzata, controlla i log per verificare se sono presenti attività nuove o aggiornate.
alle risorse IAM utilizzando i seguenti filtri:
proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
protoPayload.methodName="SetIamPolicy"
protoPayload.authenticationInfo.principalEmail="principalEmail"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Scoperta dei gruppi di autorizzazioni: gruppi cloud.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con l'account compromesso.
- Elimina l'account di servizio compromesso, ruota ed elimina a tutte le chiavi di accesso degli 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 di progetto create dall'account compromesso, ad esempio quelle sconosciute di Compute Engine, istanze, snapshot, account di servizio per gli utenti IAM.
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
Event Threat Detection esamina gli audit log per rilevare l'eliminazione di host che sono delle applicazioni protette dal servizio Backup & DR. Dopo l'eliminazione di un host, non è possibile eseguire il backup delle applicazioni associate all'host.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Inhibit System Recovery: Deleted Google Cloud Backup and DR host
di ricerca, come descritto in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- .
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome applicazione: il nome di un database o di una VM connessa a Backup & RE
- Nome host: il nome di un host connesso a Backup & RE
- Oggetto entità: un utente che ha eseguito 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 MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Attenzione valutare le informazioni raccolte nell'indagine per determinare il modo migliore per risolvere i risultati.
- Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
- Verifica che l'host eliminato non sia più nell'elenco degli host di Backup & RE.
- 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 & DR utilizzato per applicare criteri di backup a un'applicazione.
Passaggio 1: esamina i dettagli dei risultati
- Apri
Inhibit System Recovery: Google Cloud Backup and DR remove plan
di ricerca, come descritto in Analisi dei risultati. I dettagli del risultato si apre nella scheda Riepilogo. - Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- .
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome applicazione: il nome di un database o di una VM connessa a Backup & RE
- Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
- Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stato eliminato il piano
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.
- Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
- Nella scheda Gestione app, trova le applicazioni interessate che non sono più e di rivedere i criteri di backup per ognuna.
Inhibit System Recovery: Google Cloud Backup and DR delete template
Security Command Center esamina gli audit log per rilevare l'eliminazione anomala di un modello. Un modello è una configurazione di base per i backup che può essere applicata per applicazioni containerizzate.
Passaggio 1: esamina i dettagli dei risultati
- Apri
Inhibit System Recovery: Google Cloud Backup and DR delete template
di ricerca, come descritto in Analisi dei risultati. I dettagli del risultato si apre nella scheda Riepilogo. - 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 del backup
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stato eliminato il modello
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.
- Nel progetto in cui è stata eseguita l'azione, vai alla sezione e la console di gestione.
- Nella scheda Gestione app, trova le applicazioni interessate che non sono più e di rivedere i criteri di backup per ognuna.
- Per aggiungere nuovamente un modello, vai alla scheda Piani di backup e seleziona Modelli, quindi seleziona 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 la modalità di esecuzione di un backup e la sua posizione di archiviazione.
Passaggio 1: esamina i dettagli dei risultati
- Apri
Inhibit System Recovery: Google Cloud Backup and DR delete policy
di ricerca, come descritto in Analisi dei risultati. I dettagli del risultato si apre nella scheda Riepilogo. - 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 il backup frequenza, pianificazione e tempo di conservazione
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stato eliminato il criterio
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, seleziona l'applicazione interessata ed esamina 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 quali pool di archiviazione vengono utilizzati per archiviare i backup.
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Inhibit System Recovery: Google Cloud Backup and DR delete profile
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 dell'applicazione e della VM
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stato eliminato il profilo
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Piani di backup, seleziona Profili per visualizzare un elenco di tutti i profili. 3. Esamina i profili per verificare che tutti i profili obbligatori siano presenti. 4. Se il profilo eliminato è stato rimosso per errore, seleziona Crea profilo per definire le destinazioni di archiviazione per le appliance di Backup & RE.
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
Gli audit log vengono esaminati per rilevare l'eliminazione di un pool di archiviazione. Un pool di archiviazione associa un bucket Cloud Storage a Backup & RE.
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Inhibit System Recovery: Google Cloud Backup and DR delete storage pool
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 sono archiviati i backup
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stato eliminato il pool di archiviazione
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestisci, seleziona Pool di archiviazione per un elenco di tutti i pool di archiviazione. 3. Esamina le associazioni del pool di archiviazione con le appliance di backup. 4. Se a un'appliance attiva non è associato un pool di archiviazione, seleziona Aggiungi pool OnVault per aggiungerlo nuovamente.
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 dei risultati
- Apri il risultato
Inhibit System Recovery: Google Cloud Backup and DR expire image
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 del backup
- Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
- Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'immagine di backup
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitoraggio 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 utente potenzialmente malintenzionato ha richiesto di eliminare tutte le immagini di backup associate a un'applicazione.
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Inhibit System Recovery: Google Cloud Backup and DR expire all images
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 del backup
- Nome modello: il nome di un insieme di criteri che definiscono la frequenza, la pianificazione e il tempo di conservazione del backup
- Nome profilo: specifica la destinazione di archiviazione per i backup dei dati dell'applicazione e della VM
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui sono state eliminate le immagini di backup
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Vai alla scheda Monitoraggio 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
Gli audit log 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 dei risultati
- Apri il risultato
Inhibit System Recovery: Google Cloud Backup and DR remove appliance
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- .
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome appliance: il nome di un database o di una VM connessa a Backup & RE
- Oggetto entità: un utente che ha eseguito un'azione.
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui è stata eliminata l'appliance
- Correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK
- URI di Logging: link per aprire Esplora log
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di risposta
Contatta il proprietario dell'account di servizio nel campo Email 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. Valuta attentamente le informazioni raccolte durante l'indagine per determinare il modo migliore per risolvere i risultati. 1. Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione. 2. Nella scheda Gestione app, trova 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 & RE nella console Google Cloud e seleziona l'opzione Esegui il deployment di un'altra appliance di backup o ripristino. 4. Nel menu Archiviazione, configura ogni nuova appliance con una destinazione di archiviazione. Dopo aver configurato un'appliance, questa viene visualizzata come opzione quando crei un profilo per le applicazioni.
Impact: Google Cloud Backup and DR reduced backup expiration
Event Threat Detection esamina gli audit log per rilevare se la data di scadenza per un backup su un'appliance del servizio Backup & DR è stata ridotta.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Impact: Google Cloud Backup and DR reduced backup expiration
di ricerca, come descritto in Analisi dei risultati. La Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 è stato ha eseguito un'azione
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui scade il backup è stato ridotto.
- Link correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK.
- URI di Logging: link per aprire Esplora log.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di 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 risultato. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.
- Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
- Nella scheda Gestione app, trova l'applicazione interessata per la quale è stato eseguito il backup. la scadenza è stata ridotta e verificare che la scadenza fosse prevista principale.
- Per avviare un nuovo backup dell'applicazione, seleziona Gestisci le 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 gli audit log per rilevare se il piano di backup ha è stato modificato per ridurre la frequenza dei backup.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Impact: Google Cloud Backup and DR reduced backup frequency
di ricerca, come descritto in Analisi dei risultati. La Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. - 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 è stato ha eseguito un'azione
- Risorsa interessata
- .
- Nome visualizzato della risorsa: il progetto in cui viene generata la frequenza di backup è stato ridotto.
- Link correlati, in particolare i seguenti campi:
- .
- Metodo MITRE ATTACK: link alla documentazione MITRE ATT&CK.
- URI di Logging: link per aprire Esplora log.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: ricerca i metodi di attacco e di 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 risultato. Attenzione valutare le informazioni raccolte durante l'indagine per determinare per risolvere i risultati.
- Nel progetto in cui è stata eseguita l'azione, vai alla console di gestione.
- Nella scheda Gestione app, trova l'applicazione interessata per la quale è stato eseguito il backup. frequenza è stata ridotta e verificare che la modifica fosse intenzionale principale.
- Per avviare un nuovo backup dell'applicazione, seleziona Gestisci le configurazioni di backup per creare un backup on demand o per pianificare un nuovo backup.
Impact: Suspicious Kubernetes Container Names - Coin Mining
Un utente ha eseguito il deployment di un pod con una convenzione di denominazione simile alla criptovaluta comune miner di monete. Potrebbe trattarsi di un tentativo di un aggressore che ha raggiunto il traguardo iniziale accesso al cluster per utilizzare le risorse del cluster per il mining di criptovaluta. Per maggiori dettagli, consulta il messaggio di log per questo avviso.
- Verifica che il Pod sia legittimo.
- Determina se esistono altri segnali di attività dannosa dal pod o nell'audit log di Cloud Logging.
- Se l'entità non è un account di servizio (IAM o Kubernetes), contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.
- Se l'entità è un account di servizio (IAM o Kubernetes), identificare l'origine dell'azione per determinarne la legittimità.
- Se il pod non è legittimo, rimuovilo, insieme a eventuali RBAC associati e account di servizio utilizzati dal carico di lavoro e che ne hanno consentito per la creazione di contenuti.
Lateral Movement: Modified Boot Disk Attached to Instance
Gli audit log vengono esaminati per rilevare movimenti sospetti di dischi tra le risorse delle istanze Compute Engine. Un disco di avvio potenzialmente modificato è stato collegato al tuo Compute Engine.
Passaggio 1: esamina i dettagli dei risultati
- Apri il risultato
Lateral Movement: Modify Boot Disk Attaching to Instance
, come descritto in dettaglio in Analisi dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo. Nella scheda Riepilogo, prendi nota dei valori campi seguenti.
Nella sezione 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 ha eseguito l'accesso dall'account di servizio.
- Nome metodo: il metodo chiamato
Passaggio 2: ricerca i metodi di attacco e di risposta
- Utilizza l'account di servizio di Google, come Attività Analizzatore, per analizzare l'attività dell'account di servizio associato.
- Contatta il proprietario dell'account di servizio nel campo Email 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 risultati.
- Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
- Valuta l'uso Avvio protetto per il tuo di istanze VM di Compute Engine.
- Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi esegui la rotazione ed eliminalo a tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 e collaborare con i proprietari delle applicazioni per garantire la continuità aziendale.
- Collabora con il team di sicurezza per identificare le risorse sconosciute, ad esempio Istanze Compute Engine, snapshot, account di servizio e IAM utenti. Elimina le risorse non create con account autorizzati.
- Rispondere a qualsiasi notifica dell'assistenza Google Cloud.
Privilege Escalation: AlloyDB Over-Privileged Grant
Rileva quando tutti i privilegi su un database AlloyDB per PostgreSQL (o tutti funzioni o procedure in un database) vengono concesse a uno o più database utenti.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri
Privilege Escalation: AlloyDB Over-Privileged Grant
come indicato in Revisione dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome visualizzato database: il nome del database nella Istanza AlloyDB per PostgreSQL interessata.
- Nome utente database: l'utente PostgreSQL che ha concesso i privilegi in eccesso.
- Query sul database: la query PostgreSQL eseguita che ha concesso ai privilegiati.
- Beneficiari database: i beneficiari dei privilegi overbroad.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome della risorsa di AlloyDB per PostgreSQL interessata.
- Nome completo padre: il nome della risorsa di AlloyDB per PostgreSQL in esecuzione in un'istanza Compute Engine.
- 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 MITRE ATT&CK.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: rivedi i privilegi del database
- Connettiti all'istanza AlloyDB per PostgreSQL.
- Elencare e mostrare i privilegi di accesso
per:
- .
- Database. Usa il metacomando
\l
o\list
e controllare quali privilegi sono assegnati al database elencato in Nome visualizzato del database (dal Passaggio 1). - Funzioni o procedure. Usa il metacomando
\df
e controllare quali privilegi sono assegnati per funzioni o procedure database elencato in Nome visualizzato del database (da Passaggio 1).
- Database. Usa il metacomando
Passaggio 3: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su il link nell'URI Cloud Logging (da Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
- In Esplora log, controlla i log PostgreSQL
pgaudit
, che registrano query eseguite sul database, utilizzando i seguenti filtri:protoPayload.request.database="var class="edit">database"
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi web.
- Per determinare se sono necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario dell'istanza con concessioni con privilegi in eccesso.
- Valuta la possibilità di revocare tutte le autorizzazioni per i beneficiari elencati in Beneficiari database fino al termine dell'indagine.
- Per limitare l'accesso al database (da Nome visualizzato del database di Passaggio 1, revoca non necessario delle autorizzazioni dei beneficiari (da Beneficiari database Passaggio 1.
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
Rileva quando l'account super user del database AlloyDB per PostgreSQL (postgres
)
nelle tabelle utente. Il super user (un ruolo con accesso molto ampio) in genere
non deve essere utilizzato per scrivere nelle tabelle degli utenti. Un account utente con accesso più limitato.
deve essere utilizzato per la normale attività quotidiana. Quando un super user scrive a un utente
tabella, che potrebbe indicare che un aggressore ha aumentato i privilegi o ha
ha compromesso l'utente del database predefinito e sta modificando i dati. Potrebbe anche
indicare pratiche normali ma non sicure.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
- Apri un
Privilege Escalation: AlloyDB Database Superuser Writes to User Tables
come indicato in Revisione dei risultati. Nella scheda Riepilogo del riquadro dei dettagli del risultato, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome visualizzato database: il nome del database nella Istanza AlloyDB per PostgreSQL interessata.
- Nome utente database: il super user.
- 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 di AlloyDB per PostgreSQL interessata.
- Nome completo padre: il nome della risorsa di AlloyDB per PostgreSQL in esecuzione in un'istanza Compute Engine.
- 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 MITRE ATT&CK.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: controlla i log
- Nella console Google Cloud, vai a Esplora log facendo clic su
il link in
cloudLoggingQueryURI
(dal Passaggio 1). La pagina Esplora log include tutti i log relativi ai AlloyDB per PostgreSQL. - Controlla i log pgaudit PostgreSQL, che contengono le query
eseguite dal super user, utilizzando i seguenti filtri:
protoPayload.request.user="postgres"
Passaggio 3: ricerca i metodi di attacco e di risposta
- Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi web.
- Per determinare se sono necessarie ulteriori misure di correzione, combina i risultati dell'indagine con il MITRE ricerca.
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 risultati.
- Esamina gli utenti autorizzati a connettersi al database.
- Valuta la possibilità di cambiare la password del super user.
- Potresti creare un nuovo utente con accesso limitato
per i diversi tipi di query
usati sull'istanza.
- Concedi al nuovo utente solo le autorizzazioni necessarie per eseguire le sue query.
- Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL
Rilevamenti dei metadati amministrativi di Compute Engine
Persistence: GCE Admin Added SSH Key
Descrizione | Azioni | |
---|---|---|
La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata su 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
implementate da un avversario per introdurre un nuovo accesso alla vostra organizzazione.
|
Controlla i log utilizzando i seguenti filtri:
Sostituisci quanto segue:
|
Eventi di ricerca che attivano questo risultato: |
Persistence: GCE Admin Added Startup Script
Descrizione | Azioni | |
---|---|---|
La chiave dei metadati dell'istanza Compute Engine startup-script o startup-script-url è stata modificata su un'istanza stabilita.
|
La chiave dei metadati dell'istanza Compute Engine startup-script oppure
startup-script-url è stato modificato su un'istanza creata più di
sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata
implementate da un avversario per introdurre un nuovo accesso alla vostra organizzazione.
|
Controlla i log utilizzando i seguenti filtri:
Sostituisci quanto segue:
|
Eventi di ricerca che attivano questo risultato: |
Rilevamenti dei log di Google Workspace
Se condividi i log di Google Workspace con Cloud Logging, Event Threat Detection genera risultati per diversi account Google Workspace in modo proattivo. Poiché i log di Google Workspace sono a livello di organizzazione, Event Threat Detection può analizzarle solo se attivi Security Command Center a livello di organizzazione.
Event Threat Detection arricchisce gli eventi dei log e scrive i risultati Security Command Center. La tabella seguente contiene Google Workspace le minacce, i MITRE ATT&CK pertinenti, del framework e i dettagli sul eventi che attivano i risultati. Puoi anche controllare i log usando filtri specifici, e combinare tutte le informazioni per rispondere a Google Workspace. minacce.
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 a causa di una fuga di password rilevato. | Reimposta le password degli account interessati e consiglia ai membri di Utilizzare password efficaci e univoche per gli account aziendali. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato:
|
Initial Access: Suspicious Login Blocked
Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.
Descrizione | Azioni | |
---|---|---|
È stato rilevato un accesso sospetto all'account di un membro e bloccato. | Questo account potrebbe essere preso di mira da utenti malintenzionati. Assicurati che dell'account utente segue le linee guida di sicurezza della tua organizzazione per password e autenticazione a più fattori. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato:
|
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à sospetta. | Questo account è stato compromesso. Reimpostare la password dell'account e incoraggiare gli utenti a creare password efficaci e univoche per gli account aziendali. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato:
|
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 che lo fornisca prontamente. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato:
|
Initial Access: Government Based Attack
Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.
Descrizione | Azioni | |
---|---|---|
Gli aggressori sostenuti da un governo potrebbero aver tentato di compromettere un su un computer o un account membro. | Questo account potrebbe essere preso di mira da utenti malintenzionati. Assicurati che dell'account utente segue le linee guida di sicurezza della tua organizzazione per password e autenticazione a più fattori. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato:
|
Persistence: SSO Enablement Toggle
Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.
Descrizione | Azioni | |
---|---|---|
Impostazione Abilita SSO (Single Sign-On) nell'account amministratore è stato disattivato. | Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se implementate da un avversario per introdurre un nuovo accesso alla vostra organizzazione. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci quanto segue:
|
Eventi di ricerca che attivano questo risultato:
|
Persistence: SSO Settings Changed
Questo risultato non è disponibile se attivi Security Command Center a livello di progetto.
Descrizione | Azioni | |
---|---|---|
Le impostazioni SSO dell'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 implementate da un avversario per introdurre un nuovo accesso alla vostra organizzazione. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci quanto segue:
|
Eventi di ricerca che attivano questo risultato:
|
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 il tuo dell'organizzazione. Scopri se si è trattato di una modifica intenzionale delle norme da parte di un amministratore o se si tratta di un tentativo da parte di un avversario di creare i compromissioni più facilmente. |
Controlla i log utilizzando i seguenti filtri:
Sostituisci |
Eventi di ricerca che attivano questo risultato: |
Rispondere alle minacce relative a Google Workspace
I risultati di Google Workspace sono disponibili solo a livello di organizzazione attivazioni di Security Command Center. I log di Google Workspace non possono essere analizzate per rilevare attivazioni a livello di progetto.
Se sei un amministratore di Google Workspace, puoi utilizzare le impostazioni di sicurezza del servizio strumenti per risolvere queste minacce:
Gli strumenti includono avvisi, una dashboard per la sicurezza, consigli per la sicurezza e può aiutarti a indagare e a risolvere le minacce.
Se non sei un amministratore di Google Workspace, segui questi passaggi:
- Se hai ancora accesso al tuo account, modifica o reimposta il tuo password e attiva Verifica in due passaggi.
- Contatta il tuo Google Workspace amministratore o al team del tuo che gestisce il tuo account Google Workspace. Utilizza questi risultati a indicare che un account potrebbe essere stato compromesso.
Rilevamenti delle minacce di Cloud IDS
Cloud IDS: THREAT_ID
I risultati di Cloud IDS sono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico da e verso Risorse Google Cloud per le minacce. Quando Cloud IDS rileva un una minaccia, invia informazioni relative alla minaccia, come l'indirizzo IP di origine, indirizzo e numero di porta di destinazione a Event Threat Detection, che quindi invia alla ricerca di una minaccia.
Passaggio 1: esamina i dettagli dei risultati
Aperto il risultato
Cloud IDS: THREAT_ID
, come indicato in Analisi dei risultati.Nei dettagli dei risultati, nella scheda Riepilogo, esamina i valori elencati in le seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Protocollo: il protocollo di rete utilizzato
- Ora evento: quando si è verificato l'evento.
- Descrizione: ulteriori informazioni sul risultato
- Gravità: la gravità dell'avviso.
- IP di destinazione: l'IP di destinazione 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 risorsa: il progetto contenente la rete con la minaccia
- Link correlati, in particolare i seguenti campi:
- .
- URI Cloud Logging: link a Cloud IDS Logging voci : queste voci contengono le informazioni necessarie per la ricerca Palo Alto Networks Archivio delle minacce
- Servizio di rilevamento
- .
- Finding Category (Trova categoria) Il nome della minaccia Cloud IDS
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.
Passaggio 2: ricerca i metodi di attacco e di risposta
Dopo aver esaminato i dettagli del risultato, consulta la Documentazione di Cloud IDS sull'analisi degli avvisi di minacce per determinare una risposta appropriata.
Puoi trovare ulteriori informazioni sull'evento rilevato nel log originale facendo clic sul link nel campo URI Cloud Logging nel risultato i dettagli.
Risposte di Container Threat Detection
Per saperne di più su Container Threat Detection, consulta come funziona Container Threat Detection.
Added Binary Executed
Un file binario che non faceva parte dell'immagine container originale era
eseguito. Gli aggressori di solito installano strumenti di sfruttamento e malware dopo la compromissione iniziale. Garantire che i container siano immutabili è una best practice importante. Questo
è un risultato di bassa gravità, perché la tua organizzazione potrebbe non seguire
best practice. Sono presenti
Execution: Added Malicious Binary Executed
risultati quando l'hash del
binario è un indicatore noto di compromissione (IoC). Per rispondere a questo risultato,
procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Added Binary Executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 programma binario aggiunto.
- Argomenti: gli argomenti forniti durante la chiamata del programma binario aggiunto.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic su JSON e prendi nota dei seguenti campi:
resource
:project_display_name
: il nome del progetto che contiene nel 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 container interessato.Container_Image_Uri
: il nome dell'immagine container di cui è stato eseguito il deployment.VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Identifica altri risultati che si sono verificati in un momento simile per questo container. Risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'inosservanza delle best practice.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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 inresource.labels.cluster_name
location
: la località elencata inresource.labels.location
project_name
: il nome del progetto elencato inresource.project_display_name
Recupera il programma binario aggiunto eseguendo:
kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name local_file
Sostituisci
local_file
con un percorso file locale per archiviare il file binario aggiunto.Connettiti all'ambiente dei container eseguendo:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, API nativa.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Se il file binario doveva essere incluso nel container, ricrea l'immagine container includendo il file binario. In questo modo, il container può essere immutabile.
- In caso contrario, contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Added Library Loaded
È stata caricata una libreria che non faceva parte dell'immagine container originale.
Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per
bypassare le protezioni di esecuzione del codice e nascondere il codice dannoso. Garantire che i container siano immutabili è una best practice importante. Questo è un risultato 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 noto indicatore di compromissione (IoC). Per rispondere
ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Added Library Loaded
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- File binario del programma: il percorso completo del file binario del processo che ha caricato libreria.
- Librerie: dettagli sulla libreria aggiunta.
- Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa nel cluster.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON e prendi nota dei seguenti campi:
resource
:project_display_name
: il nome del progetto che contiene per l'asset.
sourceProperties
:Pod_Namespace
: il nome dello spazio dei nomi Kubernetes del pod.Pod_Name
: il nome del pod GKE.Container_Name
: il nome del container interessato.Container_Image_Uri
: il nome dell'immagine container che viene eseguita.VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Identifica altri risultati che si sono verificati in un momento simile per questo container. Risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'inosservanza delle best practice.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato in
resource.name
. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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
Recupera la libreria aggiunta eseguendo:
kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name local_file
Sostituisci local_file con un percorso file locale per archiviare l'elemento aggiunto libreria.
Connettiti all'ambiente dei container eseguendo:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, Moduli condivisi.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Se la libreria doveva essere inclusa nel container, ricrea l'immagine container includendo la libreria. In questo modo, il container può essere immutabile.
- In caso contrario, contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Added Malicious Binary Executed
Un programma binario dannoso che non faceva parte dell'immagine container originale è stato eseguito. Normalmente gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Added Malicious Binary Executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 programma binario aggiunto.
- Argomenti: gli argomenti forniti durante la chiamata del programma binario aggiunto.
- Container: il nome del contenitore interessato.
- URI container: il nome dell'immagine container di cui si esegue il deployment.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.
- Link correlati, in particolare i seguenti campi:
- .
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON e prendi nota dei seguenti campi:
sourceProperties
:VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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 inresource.labels.cluster_name
location
: la località elencata inresource.labels.location
project_name
: il nome del progetto elencato inresource.project_display_name
Recupera il file 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 archiviare il file binario dannoso aggiunto.Connettiti all'ambiente dei container:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, API nativa.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
- Controlla il valore hash SHA-256 del file binario segnalato come dannoso su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Added Malicious Library Loaded
È stata caricata una libreria dannosa che non faceva parte dell’immagine container originale. Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per bypassare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Added Malicious Library Loaded
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- File binario del programma: il percorso completo del file binario del processo che ha caricato libreria.
- Librerie: dettagli sulla libreria aggiunta.
- Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
- Container: il nome del contenitore interessato.
- URI container: il nome dell'immagine container di cui si esegue il deployment.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa nel cluster.
- Link correlati, in particolare i seguenti campi:
- .
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON e prendi nota dei seguenti campi:
sourceProperties
:VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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
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 il malware aggiunto libreria.
Connettiti all'ambiente dei container:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, Moduli condivisi.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
- Controlla il valore hash SHA-256 della libreria segnalata come dannosa su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Built in Malicious Binary Executed
Un programma binario eseguito con questo codice:
- Incluso nell'immagine container originale.
- Identificati come dannosi in base alle informazioni sulle minacce.
L'aggressore ha il controllo del repository delle immagini container o della pipeline di creazione, in cui il programma binario dannoso viene iniettato nell’immagine container. Per rispondere a questo risultato:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Built in Malicious Binary Executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 programma binario integrato.
- Argomenti: gli argomenti forniti durante la chiamata al programma binario integrato.
- Container: il nome del contenitore interessato.
- URI container: il nome dell'immagine container di cui si esegue il deployment.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.
- Link correlati, in particolare i seguenti campi:
- .
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic su JSON e prendi nota dei seguenti campi:
sourceProperties
:VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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 inresource.labels.cluster_name
location
: la località elencata inresource.labels.location
project_name
: il nome del progetto elencato inresource.project_display_name
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 integrato.Connettiti all'ambiente dei container:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, API nativa.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
- Controlla il valore hash SHA-256 del file binario segnalato come dannoso su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Malicious Python executed
Un modello di machine learning ha identificato il codice Python eseguito come dannoso. Gli aggressori possono utilizzare Python per trasferire strumenti ed eseguire comandi senza programmi binari. Garantire che i container siano immutabili è una best practice importante. L'utilizzo degli script per gli strumenti di trasferimento può imitare la tecnica del trasferimento degli strumenti in entrata e causare rilevamenti indesiderati.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Malicious Python executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- File binario del programma: dettagli sull'interprete che ha richiamato lo script.
- Script: percorso assoluto del nome dello script su disco. questo
viene visualizzato solo per gli script scritti su disco, non per il valore letterale
dell'esecuzione dello script, ad esempio
python3 -c
. - Argomenti: gli argomenti forniti durante la chiamata dello script.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e cluster nome
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
finding
:processes
:script
:contents
: contenuti dello script eseguito, che potrebbero essere troncati per motivi delle prestazioni; può essere utile nella tua indaginesha256
: l'hash SHA-256 discript.contents
resource
:project_display_name
: il nome del progetto che contiene per l'asset.
sourceProperties
:Pod_Namespace
: il nome dello spazio dei nomi Kubernetes del pod.Pod_Name
: il nome del pod GKE.Container_Name
: il nome del container interessato.Container_Image_Uri
: il nome dell'immagine container che viene eseguita.VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Identifica altri risultati che si sono verificati in un momento simile per questo container. Ad esempio, se lo script rilascia un file binario, controlla i risultati relativi a quel file.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato in
resource.name
e allo spazio dei nomi del pod elencato inPod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Fai clic sul nome del cluster mostrato in
resource.labels.cluster_name
.Nella pagina Cluster, fai clic su Connetti e quindi su Esegui in. in Cloud Shell.
Cloud Shell avvia e aggiunge i comandi per il cluster nella o nel terminale.
Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.
Connettiti all'ambiente dei container eseguendo questo comando:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Comandi e script Interprete, Trasferimento di strumenti in entrata.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Se Python ha apportato modifiche previste al container, ricrea l'immagine container in modo che non siano necessarie modifiche. In questo modo, il container può essere immutabile.
- In caso contrario, contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Modified Malicious Binary Executed
Un programma binario eseguito con questo codice:
- Incluso nell'immagine container originale.
- Modificato durante il runtime del container.
- Identificati come dannosi in base alle informazioni sulle minacce.
Normalmente gli aggressori installano strumenti di exploit e malware dopo la compromissione iniziale. Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Modified Malicious Binary Executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 programma binario modificato.
- Argomenti: gli argomenti forniti durante la chiamata al programma binario modificato.
- Container: il nome del contenitore interessato.
- URI container: il nome dell'immagine container di cui si esegue il deployment.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e nome del cluster.
- Link correlati, in particolare i seguenti campi:
- .
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic su JSON e prendi nota dei seguenti campi:
sourceProperties
:VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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 inresource.labels.cluster_name
location
: la località elencata inresource.labels.location
project_name
: il nome del progetto elencato inresource.project_display_name
Recupera il file 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 archiviare il file binario dannoso modificato.Connettiti all'ambiente dei container:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, API nativa.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
- Controlla il valore hash SHA-256 del file binario segnalato come dannoso su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Execution: Modified Malicious Library Loaded
Una libreria che è stata caricata, con la libreria in questione:
- Incluso nell'immagine container originale.
- Modificato durante il runtime del container.
- Identificati come dannosi in base alle informazioni sulle minacce.
Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per bypassare le protezioni di esecuzione del codice e nascondere il codice dannoso. Per rispondere ricerca, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Modified Malicious Library Loaded
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- File binario del programma: il percorso completo del file binario del processo che ha caricato libreria.
- Librerie: dettagli sulla libreria modificata.
- Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
- Container: il nome del contenitore interessato.
- URI container: il nome dell'immagine container di cui si esegue il deployment.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa nel cluster.
- Link correlati, in particolare i seguenti campi:
- .
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON e prendi nota dei seguenti campi:
sourceProperties
:VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato in
resource.name
. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in
Pod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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
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 il file dannoso modificato libreria.
Connettiti all'ambiente dei container:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: trasferimento di strumenti in entrata, Moduli condivisi.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
- Controlla il valore hash SHA-256 della libreria segnalata come dannosa su VirusTotal di facendo clic sul link nell'indicatore di VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Malicious Script Executed
Un modello di machine learning ha identificato il codice Bash eseguito come dannoso. Gli aggressori possono usare Bash per trasferire strumenti ed eseguire comandi senza programmi binari. Garantire che i container siano immutabili è una best practice importante. L'utilizzo degli script per gli strumenti di trasferimento può imitare la tecnica del trasferimento degli strumenti in entrata e causare rilevamenti indesiderati.
Per rispondere a questo risultato, procedi nel seguente modo:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Malicious Script Executed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- File binario del programma: dettagli sull'interprete che ha richiamato lo script.
- Script: percorso assoluto del nome dello script su disco. questo
viene visualizzato solo per gli script scritti su disco, non per il valore letterale
dell'esecuzione di script, ad esempio
bash -c
. - Argomenti: gli argomenti forniti durante la chiamata dello script.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa del cluster, inclusi numero di progetto, località e cluster nome
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi.
finding
:processes
:script
:contents
: contenuti dello script eseguito, che potrebbero essere troncati per motivi delle prestazioni; può essere utile nella tua indaginesha256
: l'hash SHA-256 discript.contents
resource
:project_display_name
: il nome del progetto che contiene per l'asset.
sourceProperties
:Pod_Namespace
: il nome dello spazio dei nomi Kubernetes del pod.Pod_Name
: il nome del pod GKE.Container_Name
: il nome del container interessato.Container_Image_Uri
: il nome dell'immagine container che viene eseguita.VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.
Identifica altri risultati che si sono verificati in un momento simile per questo container. Ad esempio, se lo script rilascia un file binario, controlla i risultati relativi a quel file.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del risultato. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.
Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato in
resource.name
e allo spazio dei nomi del pod elencato inPod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Fai clic sul nome del cluster mostrato in
resource.labels.cluster_name
.Nella pagina Cluster, fai clic su Connetti e quindi su Esegui in. in Cloud Shell.
Cloud Shell avvia e aggiunge i comandi per il cluster nella o nel terminale.
Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.
Connettiti all'ambiente dei container eseguendo questo comando:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento di strumenti in entrata.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Se lo script stava apportando modifiche previste al container, ricrea l'immagine container in modo che non siano necessarie modifiche. In questo modo, il container può essere immutabile.
- In caso contrario, contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Malicious URL Observed
Container Threat Detection ha rilevato un URL dannoso nell'elenco di argomenti di un eseguibile del processo. Gli aggressori possono caricare malware o librerie dannose tramite URL dannosi.
Per rispondere a questo risultato, segui questi passaggi.
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Malicious URL Observed
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 durante la chiamata al programma binario del processo.
- Variabili di ambiente: le variabili di ambiente presenti nella quando il programma binario del processo è stato richiamato.
- Container: il nome del container.
- Pod Kubernetes: nome del pod e spazio dei nomi.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome visualizzato della risorsa: il nome della risorsa interessata.
- Nome completo risorsa: il nome completo della risorsa
nel cluster. Il nome completo della risorsa include quanto segue:
informazioni:
- Il progetto che contiene il cluster:
projects/PROJECT_ID
- La località in cui si trova il cluster:
zone/ZONE
olocations/LOCATION
- Il nome del cluster:
projects/CLUSTER_NAME
- Il progetto che contiene il cluster:
- Che cosa è stato rilevato, in particolare i seguenti campi:
Nella scheda JSON, nell'attributo
sourceProperties
, prendi nota del valore della proprietàVM_Instance_Name
.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che viene visualizzato Nome completo risorsa (
resource.name
), se necessario. Il progetto viene visualizzato dopo/projects/
nel nome completo della risorsa.Fai clic sul nome del cluster che hai annotato in Nome visualizzato della risorsa. (
resource.display_name
) del riepilogo dei risultati. La sezione Cluster si apre una pagina.Nella sezione Metadati della **pagina dei dettagli del cluster, annota eventuali delle informazioni definite dall'utente che potrebbero essere utili per risolvere come le informazioni che identificano il proprietario del cluster.
Fai clic sulla scheda Nodi.
Tra i nodi elencati, seleziona quello che corrisponde al valore di
VM_Instance_Name
che hai notato nel risultato JSON.Nella scheda Dettagli della pagina Dettagli nodo, Annotazioni, nota il valore del parametro annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel Nome completo risorsa (
resource.name
) del cluster nella un riepilogo dei risultati, se necessario.Fai clic su Mostra carichi di lavoro di sistema.
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 dei risultati e, se necessario, lo spazio dei nomi del pod (kubernetes.pods.ns
) che hai annotato.Fai clic sul nome del carico di lavoro che corrisponde al valore dell'
VM_Instance_Name
che hai notato nel file JSON dei risultati in precedenza. I Dettagli pod si apre una pagina.Nella pagina Dettagli pod, prendi nota delle eventuali informazioni sul pod può aiutarti a risolvere la minaccia.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che viene visualizzato Nome completo risorsa (
resource.name
), se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- Trova i log dei pod per il tuo pod (
kubernetes.pods.name
) utilizzando 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="INSTANCE_ID"
- Trova i log dei pod per il tuo pod (
Passaggio 5: analizza il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Fai clic sul nome del cluster mostrato in
resource.labels.cluster_name
.Nella pagina Cluster, fai clic su Connetti e quindi su Esegui in. in Cloud Shell.
Cloud Shell avvia e aggiunge i comandi per il cluster nella o nel terminale.
Premi Invio e, se viene visualizzata la finestra di dialogo Autorizza Cloud Shell, fai clic su Autorizza.
Connettiti all'ambiente dei container eseguendo questo comando:
kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
Sostituisci
CONTAINER_NAME
con il nome del container che hai notato nel riepilogo dei risultati in precedenza.Questo comando richiede che nel container sia installata una shell in
/bin/sh
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Controllare lo stato dei siti segnalato dalla funzione Navigazione sicura per informazioni sul motivo per cui l'URL è classificato come dannoso.
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento di strumenti Ingress.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con ricerca MITRE.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Reverse Shell
Processo avviato con il reindirizzamento dello stream a un socket connesso remoto. Deposizione delle uova una shell connessa in rete può consentire a un utente malintenzionato di eseguire azioni arbitrarie dopo una limitata compromissione iniziale. Per rispondere a questo risultato, seguenti:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Reverse Shell
come indicato in Revisione dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.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 iniziato con il reindirizzamento dei flussi a un socket remoto.
- Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo risorsa: il nome completo della risorsa nel cluster.
- Nome completo del progetto:
- Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
- Nel file JSON, tieni presente i seguenti campi.
resource
:project_display_name
: il nome del progetto che contiene per l'asset.
sourceProperties
:Pod_Namespace
: il nome dello spazio dei nomi Kubernetes del pod.Pod_Name
: il nome del pod GKE.Container_Name
: il nome del container interessato.VM_Instance_Name
: il nome del nodo GKE in cui Pod eseguito.Reverse_Shell_Stdin_Redirection_Dst_Ip
: l'indirizzo IP remoto del connessioneReverse_Shell_Stdin_Redirection_Dst_Port
: la porta remotaReverse_Shell_Stdin_Redirection_Src_Ip
: l'indirizzo IP locale del connessioneReverse_Shell_Stdin_Redirection_Src_Port
: porta localeContainer_Image_Uri
: il nome dell'immagine container che viene eseguita.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato in
resource.name
. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Filtra in base al cluster elencato in
resource.name
e allo spazio dei nomi del pod elencato inPod_Namespace
, se necessario.Seleziona il pod elencato in
Pod_Name
. Prendi nota di tutti i metadati relativi al pod il suo proprietario.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: esamina il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo 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
Avvia una shell nell'ambiente del container eseguendo:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:
ps axjf
Questo comando richiede che nel container sia installato
/bin/ps
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento di strumenti in entrata.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Unexpected Child Shell
Container Threat Detection ha osservato un processo che ha generato inaspettatamente un processo shell figlio. Questo evento potrebbe indicare che un utente malintenzionato sta tentando di abusare di comandi e script di shell.
Per rispondere a questo risultato, segui questi passaggi.
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Unexpected Child Shell
come indicato in Analisi dei risultati. Il riquadro dei dettagli per risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Processo padre: il processo che ha creato inaspettatamente il processo della shell secondaria.
- Processo figlio: il processo shell figlio.
- Argomenti: gli argomenti forniti al file binario del processo della shell secondaria.
- Variabili di ambiente: le variabili di ambiente del programma binario dei processi della shell figlio.
- Container: il nome del container.
- URI container: l'URI dell'immagine del container.
- Pod Kubernetes: nome del pod e spazio dei nomi.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome visualizzato della risorsa: il nome della risorsa interessata.
- Nome completo risorsa: il nome completo della risorsa
nel cluster. Il nome completo della risorsa include quanto segue:
informazioni:
- Il progetto che contiene il cluster:
projects/PROJECT_ID
- La località in cui si trova il cluster:
zone/ZONE
olocations/LOCATION
- Il nome del cluster:
projects/CLUSTER_NAME
- Il progetto che contiene il cluster:
- Che cosa è stato rilevato, in particolare i seguenti campi:
Fai clic sulla scheda JSON e prendi nota dei seguenti campi:
+processes
: un array contenente tutti i processi correlati al risultato. Questo array include il processo shell figlio e il processo padre.
+resource
:
+project_display_name
: il nome del progetto che contiene gli asset.
+sourceProperties
:
+VM_Instance_Name
: il nome del nodo GKE in cui
Pod eseguito.
Passaggio 2: esamina il cluster e il nodo
Nella console Google Cloud, vai alla pagina Cluster Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
, se necessario.Seleziona il cluster elencato in
resource.name
. Prendi nota di tutti i metadati del cluster e del rispettivo proprietario.Fai clic sulla scheda Nodi. Seleziona il nodo elencato in
VM_Instance_Name
.Fai clic sulla scheda Dettagli e prendi nota annotazione
container.googleapis.com/instance_id
.
Passaggio 3: rivedi il pod
Nella console Google Cloud, vai alla pagina Carichi di lavoro Kubernetes.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che hai annotato nel Nome completo risorsa (
resource.name
) del cluster nella un riepilogo dei risultati, se necessario.Fai clic su Mostra carichi di lavoro di sistema.
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 dei risultati e, se necessario, lo spazio dei nomi del pod (kubernetes.pods.ns
) che hai annotato.Fai clic sul nome del carico di lavoro che corrisponde al valore dell'
VM_Instance_Name
che hai notato nel file JSON dei risultati in precedenza. I Dettagli pod si apre una pagina.Nella pagina Dettagli pod, prendi nota delle eventuali informazioni sul pod può aiutarti a risolvere la minaccia.
Passaggio 4: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
.Imposta Seleziona intervallo di tempo sul periodo di interesse.
Nella pagina visualizzata, procedi nel seguente modo:
- 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"
- Trova gli audit log del cluster utilizzando il filtro seguente:
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
- Trova i log della console del nodo GKE utilizzando il seguente filtro:
resource.type="gce_instance"
resource.labels.instance_id="instance_id"
- Trova i log dei pod per
Passaggio 5: analizza il container in esecuzione
Se il container è ancora in esecuzione, potrebbe essere possibile esaminare il dell'ambiente del container.
Vai alla console Google Cloud.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto elencato in
resource.project_display_name
.Fai clic su Attiva Cloud Shell.
Ottieni le credenziali GKE per il tuo cluster eseguendo seguenti comandi.
Per i cluster di zona, esegui questo comando:
gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name
Per i cluster a livello di regione, esegui questo comando:
gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name
Per avviare una shell nell'ambiente del container, esegui questo comando:
kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
Questo comando richiede che nel container sia installata una shell in
/bin/sh
.Per visualizzare tutti i processi in esecuzione nel container, esegui questo comando nella shell del container:
ps axjf
Questo comando richiede che nel container sia installato
/bin/ps
.
Passaggio 6: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script: Unix Shell.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
- Contatta il proprietario del progetto con il container compromesso.
- Interrompi o elimina compromesso e sostituirlo con un nuovo container.
Risposta di VM Threat Detection
Per saperne di più su VM Threat Detection, consulta Panoramica di VM Threat Detection.
Execution: Cryptocurrency Mining Hash Match
VM Threat Detection ha rilevato attività di mining di criptovaluta mediante la corrispondenza della memoria hash di programmi in esecuzione rispetto ad hash di memoria di mining di criptovaluta noti software.
Per rispondere a questi risultati, segui questi passaggi:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Cryptocurrency Mining Hash Match
, come indicato in Esamina i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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.
- File binario del programma: il percorso assoluto del processo.
- Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
- Nomi processi: il nome del processo in esecuzione nell'istanza VM associato alle corrispondenze della firma rilevate.
VM Threat Detection può riconoscere le build del kernel dai principali distribuibili. Se può riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo
processes
del risultato. Se VM Threat Detection non riesce riconoscere il kernel, ad esempio se è personalizzato creato: il campoprocesses
del risultato non è compilato.Risorsa interessata, in particolare i seguenti campi:
- Nome completo della risorsa: il nome completo della risorsa interessata Istanza VM, incluso l'ID del progetto che la contiene.
Per vedere il JSON completo per questo risultato, nella visualizzazione dettagliata il risultato, fai clic sulla scheda JSON.
indicator
signatures
:memory_hash_signature
: una firma corrispondente alla memoria hash delle pagine.detections
binary
: il nome dell'applicazione di criptovaluta binario, ad esempiolinux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0
.percent_pages_matched
: la percentuale di pagine in memoria che corrispondono alle pagine nelle applicazioni di criptovaluta note il database con hash delle pagine.
Passaggio 2: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che sull'istanza VM, come specificato nella riga Nome completo risorsa in la scheda Riepilogo dei dettagli dei risultati.
Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Per Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato alla riga Nome completo risorsa nella scheda Riepilogo della trovare i dettagli.
Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM corrispondente al progetto identificato nel nome completo della risorsa. Rivedi istanza i dettagli, incluse le impostazioni di rete e accesso.
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per Esecuzione.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Contatta il proprietario della VM.
Conferma se si tratta di un'applicazione di mining:
Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, considerare i valori su Programma binario, Argomenti e Righe Nomi processi nella scheda Riepilogo dei dettagli del risultato nella tua indagine.
Se i dettagli del processo non sono disponibili, controlla se il nome binario del file la firma hash della memoria può fornire degli indizi. Considera un file binario chiamato
linux-x86-64_xmrig_2.14.1
. Puoi utilizzare logrep
per cercare file importanti nello spazio di archiviazione. Utilizza una parte significativa di il nome binario nel pattern di ricerca, in questo casoxmrig
. Esamina la risultati di ricerca.Esamina i processi in esecuzione, soprattutto quelli con un elevato utilizzo della CPU, per vedere se ce n'è qualcuno che non riconosci. Determina se applicazioni associate sono applicazioni miner.
Cercare nei file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining utilizzati, ad esempio
btc.com
,ethminer
,xmrig
,cpuminer
erandomx
. Per altri esempi di stringhe che puoi cercare, vedi Nomi software e regole YARA e la relativa documentazione per ciascun software elencato.
Se ritieni che si tratti di un'applicazione di miner e la relativa procedura è ancora in esecuzione, termina il processo. Individuare l'eseguibile dell'applicazione file binario nello spazio di archiviazione della VM e eliminarlo.
Se necessario, interrompi l'istanza compromessa e sostituirlo con una nuova istanza.
Execution: Cryptocurrency Mining YARA Rule
VM Threat Detection ha rilevato attività di mining di criptovaluta mediante la corrispondenza della memoria come le costanti del proof of work, note per essere utilizzate dalle criptovalute di software di mining.
Per rispondere a questi risultati, segui questi passaggi:
Passaggio 1: esamina i dettagli dei risultati
Apri un risultato di
Execution: Cryptocurrency Mining YARA Rule
, come indicato in Esamina i risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.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.
- File binario del programma: il percorso assoluto del processo.
- Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
- Nomi processi: il nome dei processi in esecuzione nella VM all'istanza associata alle corrispondenze di firma rilevate.
VM Threat Detection può riconoscere le build del kernel dai principali distribuibili. Se può riconoscere la build del kernel della VM interessata, può identificare i dettagli del processo dell'applicazione e compilare il campo
processes
del risultato. Se VM Threat Detection non riesce riconoscere il kernel, ad esempio se è personalizzato creato: il campoprocesses
del risultato non è compilato.Risorsa interessata, in particolare i seguenti campi:
- Nome completo della risorsa: il nome completo della risorsa interessata Istanza VM, 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 MITRE ATT&CK.
- Risultati correlati: collega a eventuali risultati correlati.
- Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.
- Chronicle: link a Google SecOps.
Per vedere il JSON completo per questo risultato, nella visualizzazione dettagliata il risultato, fai clic sulla scheda JSON.
Passaggio 2: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che sull'istanza VM, come specificato nella riga Nome completo risorsa in la scheda Riepilogo dei dettagli dei risultati.
Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Per Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato il nome della risorsa elencato nella Riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del risultato.
Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde a
resourceName
. Rivedi istanza i dettagli, incluse le impostazioni di rete e accesso.
Passaggio 4: ricerca i metodi di attacco e di risposta
- Esamina le voci del framework MITRE ATT&CK per Esecuzione.
- Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.
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 risultati.
Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
- Contatta il proprietario della VM.
Conferma se si tratta di un'applicazione di mining:
Se sono disponibili il nome del processo e il percorso binario dell'applicazione rilevata, considerare i valori su Programma binario, Argomenti e Righe Nomi processi nella scheda Riepilogo dei dettagli del risultato nella tua indagine.
Esamina i processi in esecuzione, soprattutto quelli con un elevato utilizzo della CPU, per vedere se ce n'è qualcuno che non riconosci. Determina se applicazioni associate sono applicazioni miner.
Cercare nei file nello spazio di archiviazione le stringhe comuni utilizzate dalle applicazioni di mining utilizzati, ad esempio
btc.com
,ethminer
,xmrig
,cpuminer
erandomx
. Per altri esempi di stringhe che puoi cercare, vedi Nomi software e regole YARA e la relativa documentazione per ciascun software elencato.
Se ritieni che si tratti di un'applicazione di miner e la relativa procedura è ancora in esecuzione, termina il processo. Individuare l'eseguibile dell'applicazione file binario nello spazio di archiviazione della VM e eliminarlo.
Se necessario, interrompi l'istanza compromessa e sostituirlo con una nuova istanza.
Execution: cryptocurrency mining combined detection
VM Threat Detection ha rilevato più categorie di risultati all'interno di un singolo
giorno da un'unica fonte. Una singola applicazione può attivare contemporaneamente
Execution: Cryptocurrency Mining YARA Rule
e
Execution: Cryptocurrency Mining Hash Match findings
.
Per rispondere a un risultato combinato, segui le istruzioni di risposta per entrambi
Execution: Cryptocurrency Mining YARA Rule
e
Execution: Cryptocurrency Mining Hash Match findings
.
Malware: Malicious file on disk (YARA)
VM Threat Detection ha rilevato un file potenzialmente dannoso analizzando il file dischi permanenti per le firme di malware note.
Per rispondere a questi risultati, segui questi passaggi:
Passaggio 1: esamina i dettagli dei risultati
Apri il risultato
Malware: Malicious file on disk (YARA)
, come indicato in Esamina dei risultati. Il riquadro dei dettagli del risultato si apre nella scheda Riepilogo.Nella scheda Riepilogo, esamina le informazioni nelle seguenti sezioni:
- Che cosa è stato rilevato, in particolare i seguenti campi:
- .
- Nome regola YARA: la regola YARA corrispondente.
- File: l'UUID della partizione e il percorso relativo dell'elemento è stato rilevato il file dannoso.
- Risorsa interessata, in particolare i seguenti campi:
- .
- Nome completo della risorsa: il nome completo della risorsa interessata Istanza VM, incluso l'ID del progetto che la contiene.
- Che cosa è stato rilevato, in particolare i seguenti campi:
Per vedere il JSON completo per questo risultato, nella visualizzazione dettagliata il risultato, fai clic sulla scheda JSON.
Nel file JSON, tieni presente i seguenti campi:
indicator
signatures
:yaraRuleSignature
: una firma corrispondente alla regola YARA che è stata trovata una corrispondenza.
Passaggio 2: controlla i log
Nella console Google Cloud, vai a Esplora log.
Nella barra degli strumenti della console Google Cloud, seleziona il progetto che sull'istanza VM, come specificato nella riga Nome completo risorsa in la scheda Riepilogo dei dettagli dei risultati.
Controlla i log per verificare la presenza di segni di intrusione nell'istanza VM interessata. Per Ad esempio, verifica la presenza di attività sospette o sconosciute e di segni di credenziali compromesse.
Passaggio 3: controlla le autorizzazioni e le impostazioni
Nella console Google Cloud, vai alla pagina Dashboard.
Seleziona il progetto specificato il nome della risorsa elencato nella Riga Nome completo della risorsa nella scheda Riepilogo dei dettagli del risultato.
Vai alla scheda Risorse e fai clic su Compute Engine.
Fai clic sull'istanza VM che corrisponde a
resourceName
. Rivedi istanza i dettagli, incluse le impostazioni di rete e accesso.
Passaggio 4: ricerca i metodi di attacco e di risposta
Controlla il valore hash SHA-256 del file segnalato come dannoso su VirusTotal. VirusTotal è un servizio di proprietà di Alphabet che fornisce contesto su file potenzialmente dannosi, URL, domini e indirizzi IP.
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 risultati.
Contatta il proprietario della VM.
Se necessario, individua ed elimina il file potenzialmente dannoso. Per ottenere all'UUID della partizione e al percorso relativo del file, fai riferimento al campo File nella la scheda Riepilogo dei dettagli dei risultati. Per facilitare il rilevamento la rimozione, utilizzare una soluzione di rilevamento e risposta agli endpoint.
Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.
Per l'analisi forense, esegui il backup delle macchine virtuali dei dischi permanenti standard. Per ulteriori informazioni, consulta la sezione Protezione dei dati le opzioni di Compute Engine documentazione.
Per ulteriori indagini, prendere in considerazione l’utilizzo di servizi di risposta agli incidenti come Mandiant
Correggi le vulnerabilità correlate
Per evitare che le minacce si ripetano, esamina e correggi le vulnerabilità correlate o errori di configurazione.
Per trovare eventuali risultati correlati, segui questi passaggi:
Nella console Google Cloud, vai a Security Command Center Pagina Risultati.
Rivedi il risultato della minaccia e copia il valore di un attributo che figura nell'ambito di eventuali vulnerabilità o configurazioni errate correlate risultato, ad esempio l'indirizzo email principale o il nome della persona interessata risorsa.
Nella pagina Risultati, apri l'Editor di query facendo clic su Modifica query.
Fai clic su Aggiungi filtro. Si apre il menu Seleziona filtro.
Dall'elenco delle categorie di filtro sul lato sinistro del menu, seleziona la categoria che contiene l'attributo che hai notato nella minaccia ricerca.
Ad esempio, se hai preso nota del nome completo della risorsa interessata, seleziona Risorsa. I tipi di attributi della categoria Risorsa sono visualizzato nella colonna a destra, incluso Nome completo .
Tra gli attributi visualizzati, seleziona il tipo di attributo che indicati nel risultato della minaccia. Si apre un riquadro di ricerca per i valori degli attributi a destra e vengono visualizzati tutti i valori trovati per il tipo di attributo selezionato.
Nel campo Filtro, incolla il valore dell'attributo che hai copiato da alla scoperta della minaccia. L'elenco di valori visualizzato viene aggiornato i valori corrispondenti a quello incollato.
Dall'elenco dei valori visualizzati, seleziona uno o più valori e fai clic su Applica. Il riquadro Risultati query dei risultati si aggiorna per mostrare solo risultati corrispondenti.
Se i risultati mostrano molti risultati, filtrali per selezionando altri filtri dal riquadro Filtri rapidi.
Ad esempio, per mostrare solo
Vulnerability
eMisconfiguration
risultati della classe contenenti i valori degli attributi selezionati, Scorri verso il basso fino alla sezione Ricerca del corso in 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 può integrare il programma Minaccia di messa a fuoco automatica Intelligence con Event Threat Detection. AutoFocus è un servizio di intelligence sulle minacce che fornisce informazioni sulle minacce di rete. Per saperne di più, visita la AutoFocus nella console Google Cloud.
Correggere le minacce
Correggere i risultati di Event Threat Detection e Container Threat Detection non è così semplice la correzione degli errori di configurazione e delle vulnerabilità identificate Security Command Center.
Le configurazioni errate e le violazioni della conformità identificano i punti deboli nelle risorse che potrebbero essere sfruttate. In genere, gli errori di configurazione sono correzioni implementate, 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. Una correzione potrebbe non essere efficace per la protezione delle risorse perché i metodi esatti utilizzati per ottenere l'exploit potrebbero non essere noti.
Ad esempio, un risultato Added Binary Executed
indica che un non autorizzato
è stato avviato in un container. Un consiglio di base per la correzione
ti consiglia di mettere in quarantena il container ed eliminare il file binario, ma questa operazione potrebbe non
risolvere la causa principale che ha consentito l’esecuzione dell’accesso malintenzionato
il file binario. Devi scoprire il modo in cui l'immagine container è stata danneggiata.
l'exploit. Determinare se il file è stato aggiunto tramite una porta configurata in modo errato
o in altro modo richiede un'indagine approfondita. Un analista con
un esperto del tuo sistema potrebbe dover esaminare i suoi punti deboli.
I malintenzionati attaccano le risorse utilizzando tecniche diverse, quindi applicando una correzione a un
exploit specifico potrebbe non essere efficace contro le varianti di quell'attacco. Per
Ad esempio, in risposta a un risultato Brute Force: SSH
, potresti ridurre l'autorizzazione
livelli specifici di alcuni account utente
per limitare l'accesso alle risorse. Tuttavia, i valori deboli
le password potrebbero comunque fornire un percorso di attacco.
L'ampiezza dei vettori di attacco rende difficile fornire passaggi per porvi rimedio che funzionano in tutte le situazioni. Il ruolo di Security Command Center nella sicurezza del cloud è identificare le risorse colpite quasi in tempo reale, indicare quali minacce affrontare e fornire prove e contesto a supporto delle indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni esaustive in Security Command Center risultati per determinare i modi migliori per risolvere i problemi e mettere in sicurezza le risorse contro attacchi futuri.
Passaggi successivi
Consulta: Panoramica di Event Threat Detection per saperne di più sul servizio e sulle minacce che rileva.
Consulta: Panoramica di Container Threat Detection per scoprire come funziona il servizio.
Consulta: Panoramica di VM Threat Detection per saperne di più sul servizio e sulle minacce che rileva.