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

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-s3-privesc.md

@@ -60,7 +60,7 @@ Portanto, se você tiver as permissões listadas sobre esses arquivos, há um ve
 Siga a descrição na seção *Abusing Terraform State Files* da página *Terraform Security* para código de exploit diretamente utilizável:
 
 {{#ref}}
-terraform-security.md#abusing-terraform-state-files
+pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
 {{#endref}}
 
 ### `s3:PutBucketPolicy`

src/pentesting-cloud/azure-security/az-privilege-escalation/az-app-services-privesc.md

@@ -7,7 +7,7 @@
 Para mais informações sobre os serviços de aplicativo do Azure, consulte:
 
 {{#ref}}
-../az-services/az-app-service.md
+../az-services/az-app-services.md
 {{#endref}}
 
 ### Microsoft.Web/sites/publish/Action, Microsoft.Web/sites/basicPublishingCredentialsPolicies/read, Microsoft.Web/sites/config/read, Microsoft.Web/sites/read
@@ -19,7 +19,7 @@ Essas permissões permitem obter um **SSH shell** dentro de um aplicativo web. E
 # Direct option
 az webapp ssh --name <name> --resource-group <res-group>
 ```
-- **Criar túnel e então conectar ao SSH**:
+- **Criar túnel e depois conectar ao SSH**:
 ```bash
 az webapp create-remote-connection --name <name> --resource-group <res-group>
 
@@ -129,7 +129,7 @@ Então, você pode usar essas credenciais para **acessar as plataformas SCM e FT
 Lembre-se de que para acessar a plataforma SCM pela **web, você precisa acessar `<SCM-URL>/BasicAuth`**.
 
 > [!WARNING]
-> Note que cada usuário pode configurar suas próprias credenciais chamando o comando anterior, mas se o usuário não tiver permissões suficientes para acessar o SCM ou FTP, as credenciais não funcionarão.
+> Note que todo usuário pode configurar suas próprias credenciais chamando o comando anterior, mas se o usuário não tiver permissões suficientes para acessar o SCM ou FTP, as credenciais não funcionarão.
 
 - Se você ver que essas credenciais estão **REDACTED**, é porque você **precisa habilitar a opção de autenticação básica do SCM** e para isso você precisa da segunda permissão (`Microsoft.Web/sites/basicPublishingCredentialsPolicies/write`):
 ```bash
@@ -163,7 +163,7 @@ curl -X POST "<SMC-URL>/api/publish?type=zip" --data-binary "@./app.zip" -u '<us
 ```
 ### Webjobs: Microsoft.Web/sites/publish/Action | Credenciais do SCM
 
-A permissão do Azure mencionada permite realizar várias ações interessantes que também podem ser executadas com as credenciais do SCM:
+A permissão do Azure mencionada permite realizar várias ações interessantes que também podem ser realizadas com as credenciais do SCM:
 
 - Ler logs de **Webjobs**:
 ```bash

src/pentesting-cloud/azure-security/az-services/az-function-apps.md

@@ -12,10 +12,10 @@
 ### Planos Diferentes
 
 - **Flex Consumption Plan**: Oferece **escalonamento dinâmico e orientado a eventos** com preços pay-as-you-go, adicionando ou removendo instâncias de função com base na demanda. Suporta **rede virtual** e **instâncias pré-provisionadas** para reduzir inícios a frio, tornando-o adequado para **cargas de trabalho variáveis** que não requerem suporte a contêineres.
-- **Traditional Consumption Plan**: A opção sem servidor padrão, onde você **paga apenas pelos recursos de computação quando as funções são executadas**. Ele escala automaticamente com base nos eventos recebidos e inclui **otimizações de início a frio**, mas não suporta implantações de contêiner. Ideal para **cargas de trabalho intermitentes** que requerem escalonamento automático.
+- **Traditional Consumption Plan**: A opção sem servidor padrão, onde você **paga apenas pelos recursos de computação quando as funções são executadas**. Escala automaticamente com base em eventos recebidos e inclui **otimizações de início a frio**, mas não suporta implantações de contêiner. Ideal para **cargas de trabalho intermitentes** que requerem escalonamento automático.
 - **Premium Plan**: Projetado para **desempenho consistente**, com **trabalhadores pré-aquecidos** para eliminar inícios a frio. Oferece **tempos de execução estendidos, rede virtual** e suporta **imagens personalizadas do Linux**, tornando-o perfeito para **aplicações críticas** que necessitam de alto desempenho e recursos avançados.
 - **Dedicated Plan**: Executa em máquinas virtuais dedicadas com **faturamento previsível** e suporta escalonamento manual ou automático. Permite executar várias apps no mesmo plano, fornece **isolamento de computação** e garante **acesso seguro à rede** via App Service Environments, tornando-o ideal para **aplicações de longa duração** que necessitam de alocação consistente de recursos.
-- **Container Apps**: Permite implantar **function apps containerizadas** em um ambiente gerenciado, ao lado de microsserviços e APIs. Suporta bibliotecas personalizadas, migração de aplicativos legados e **processamento GPU**, eliminando a necessidade de gerenciamento de clusters Kubernetes. Ideal para **aplicações escaláveis e orientadas a eventos**.
+- **Container Apps**: Permite implantar **function apps containerizadas** em um ambiente gerenciado, juntamente com microsserviços e APIs. Suporta bibliotecas personalizadas, migração de aplicativos legados e **processamento GPU**, eliminando a necessidade de gerenciamento de clusters Kubernetes. Ideal para **aplicações escaláveis e orientadas a eventos**.
 
 ### **Buckets de Armazenamento**
 
@@ -48,7 +48,7 @@ Usando um gatilho HTTP:
 
 Essas variáveis de ambiente ou parâmetros de configuração também controlam como a Função executa o código, por exemplo, se **`WEBSITE_RUN_FROM_PACKAGE`** existir, isso indicará a URL onde o código da aplicação está localizado.
 
-### **Sandbox da Função**
+### **Function Sandbox**
 
 Dentro do sandbox linux, o código-fonte está localizado em **`/home/site/wwwroot`** no arquivo **`function_app.py`** (se python for usado) o usuário que executa o código é **`app`** (sem permissões sudo).
 
@@ -56,16 +56,16 @@ Em uma função **Windows** usando NodeJS, o código estava localizado em **`C:\
 
 ### **Identidades Gerenciadas & Metadados**
 
-Assim como [**VMs**](vms/), Functions podem ter **Identidades Gerenciadas** de 2 tipos: Atribuídas pelo sistema e Atribuídas pelo usuário.
+Assim como [**VMs**](vms/index.html), Functions podem ter **Identidades Gerenciadas** de 2 tipos: Atribuídas pelo sistema e Atribuídas pelo usuário.
 
-A **atribuição pelo sistema** será uma identidade gerenciada que **apenas a função** que a possui atribuída poderá usar, enquanto as **identidades gerenciadas atribuídas pelo usuário** são identidades gerenciadas que **qualquer outro serviço Azure poderá usar**.
+A **atribuição pelo sistema** será uma identidade gerenciada que **apenas a função** que a possui atribuída poderá usar, enquanto as identidades gerenciadas **atribuidas pelo usuário** são identidades gerenciadas que **qualquer outro serviço Azure poderá usar**.
 
 > [!NOTE]
-> Assim como em [**VMs**](vms/), Functions podem ter **1 identidade gerenciada atribuída pelo sistema** e **várias atribuídas pelo usuário**, portanto, é sempre importante tentar encontrar todas elas se você comprometer a função, pois pode ser capaz de elevar privilégios para várias identidades gerenciadas a partir de apenas uma Função.
+> Assim como em [**VMs**](vms/index.html), Functions podem ter **1 identidade gerenciada atribuída pelo sistema** e **várias atribuídas pelo usuário**, portanto, é sempre importante tentar encontrar todas elas se você comprometer a função, pois você pode ser capaz de elevar privilégios para várias identidades gerenciadas a partir de apenas uma Função.
 >
 > Se uma identidade gerenciada pelo sistema não for usada, mas uma ou mais identidades gerenciadas pelo usuário estiverem anexadas a uma função, por padrão você não poderá obter nenhum token.
 
-É possível usar os [**scripts PEASS**](https://github.com/peass-ng/PEASS-ng) para obter tokens da identidade gerenciada padrão a partir do endpoint de metadados. Ou você pode obtê-los **manualmente** conforme explicado em:
+É possível usar os [**scripts PEASS**](https://github.com/peass-ng/PEASS-ng) para obter tokens da identidade gerenciada padrão a partir do endpoint de metadados. Ou você pode obtê-los **manualmente** como explicado em:
 
 {% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#azure-vm" %}
 
@@ -79,8 +79,8 @@ Note que você precisa descobrir uma maneira de **verificar todas as Identidades
 Ao criar um endpoint dentro de uma função usando um **gatilho HTTP**, é possível indicar o **nível de autorização da chave de acesso** necessário para acionar a função. Três opções estão disponíveis:
 
 - **ANONYMOUS**: **Todos** podem acessar a função pela URL.
-- **FUNCTION**: O endpoint é acessível apenas a usuários usando uma **chave de função, host ou mestre**.
-- **ADMIN**: O endpoint é acessível apenas a usuários com uma **chave mestre**.
+- **FUNCTION**: O endpoint é acessível apenas para usuários usando uma **chave de função, host ou mestre**.
+- **ADMIN**: O endpoint é acessível apenas para usuários com uma **chave mestre**.
 
 **Tipo de chaves:**
 
@@ -99,12 +99,12 @@ Ao criar um endpoint dentro de uma função usando um **gatilho HTTP**, é poss
 Assim como nos App Services, Functions também suportam autenticação básica para conectar ao **SCM** e **FTP** para implantar código usando um **nome de usuário e senha em uma URL** fornecida pelo Azure. Mais informações sobre isso em:
 
 {{#ref}}
-az-app-service.md
+az-app-services.md
 {{#endref}}
 
 ### Implantações Baseadas em Github
 
-Quando uma função é gerada a partir de um repositório Github, o console da web do Azure permite **criar automaticamente um Workflow do Github em um repositório específico**, de modo que sempre que este repositório for atualizado, o código da função seja atualizado. Na verdade, o yaml da ação do Github para uma função python se parece com isso:
+Quando uma função é gerada a partir de um repositório Github, o console web do Azure permite **criar automaticamente um Workflow do Github em um repositório específico**, de modo que sempre que este repositório for atualizado, o código da função seja atualizado. Na verdade, o yaml da Ação do Github para uma função em python se parece com isso:
 
 <details>
 
@@ -195,7 +195,7 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
 Além disso, uma **Identidade Gerenciada** também é criada para que a Ação do Github do repositório possa fazer login no Azure com ela. Isso é feito gerando uma credencial Federada sobre a **Identidade Gerenciada**, permitindo o **Emissor** `https://token.actions.githubusercontent.com` e o **Identificador do Sujeito** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>`.
 
 > [!CAUTION]
-> Portanto, qualquer pessoa que comprometer esse repositório poderá comprometer a função e as Identidades Gerenciadas associadas a ela.
+> Portanto, qualquer pessoa que comprometer esse repositório poderá comprometer a função e as Identidades Gerenciadas anexadas a ela.
 
 ### Implantações Baseadas em Contêiner