<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de recompensas por bugs!
A Política de Segurança de Conteúdo (CSP) é reconhecida como uma tecnologia de navegador, principalmente destinada a **proteger contra ataques como scripting entre sites (XSS)**. Funciona definindo e detalhando caminhos e fontes das quais os recursos podem ser carregados com segurança pelo navegador. Esses recursos abrangem uma variedade de elementos, como imagens, frames e JavaScript. Por exemplo, uma política pode permitir o carregamento e execução de recursos do mesmo domínio (self), incluindo recursos inline e a execução de código de string por meio de funções como `eval`, `setTimeout` ou `setInterval`.
A implementação do CSP é realizada por meio de **cabeçalhos de resposta** ou incorporando **elementos meta na página HTML**. Seguindo essa política, os navegadores aplicam proativamente essas estipulações e bloqueiam imediatamente quaisquer violações detectadas.
CSP restringe as origens para carregar conteúdo ativo e passivo, controlando aspectos como a execução de JavaScript inline e o uso de `eval()`. Um exemplo de política é:
* **script-src**: Permite fontes específicas para JavaScript, incluindo URLs, scripts inline e scripts acionados por manipuladores de eventos ou folhas de estilo XSLT.
* **default-src**: Define uma política padrão para buscar recursos quando diretivas de busca específicas estão ausentes.
* **child-src**: Especifica recursos permitidos para workers da web e conteúdos de frames incorporados.
* **connect-src**: Restringe URLs que podem ser carregadas usando interfaces como fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Restringe URLs para frames.
* **frame-ancestors**: Especifica quais fontes podem incorporar a página atual, aplicável a elementos como `<frame>`, `<iframe>`, `<object>`, `<embed>` e `<applet>`.
* **img-src**: Define fontes permitidas para imagens.
* **font-src**: Especifica fontes válidas para fontes carregadas usando `@font-face`.
* **manifest-src**: Define fontes permitidas de arquivos de manifesto de aplicativo.
* **media-src**: Define fontes permitidas para carregar objetos de mídia.
* **object-src**: Define fontes permitidas para elementos `<object>`, `<embed>` e `<applet>`.
* **base-uri**: Especifica URLs permitidos para carregar usando elementos `<base>`.
* **form-action**: Lista pontos finais válidos para envios de formulários.
* **plugin-types**: Restringe os tipos MIME que uma página pode invocar.
* **upgrade-insecure-requests**: Instrui os navegadores a reescrever URLs HTTP para HTTPS.
* **sandbox**: Aplica restrições semelhantes ao atributo sandbox de um `<iframe>`.
* **report-to**: Especifica um grupo para o qual um relatório será enviado se a política for violada.
* **worker-src**: Especifica fontes válidas para scripts de Worker, SharedWorker ou ServiceWorker.
* **prefetch-src**: Especifica fontes válidas para recursos que serão buscados ou pré-buscados.
* **navigate-to**: Restringe os URLs para os quais um documento pode navegar por qualquer meio (a, formulário, window.location, window.open, etc.)
### Fontes
*`*`: Permite todos os URLs, exceto aqueles com esquemas `data:`, `blob:`, `filesystem:`.
*`'self'`: Permite o carregamento do mesmo domínio.
*`'data'`: Permite que recursos sejam carregados via o esquema de dados (por exemplo, imagens codificadas em Base64).
*`'none'`: Bloqueia o carregamento de qualquer fonte.
*`'unsafe-eval'`: Permite o uso de `eval()` e métodos similares, não recomendado por motivos de segurança.
*`'unsafe-hashes'`: Habilita manipuladores de eventos inline específicos.
*`'unsafe-inline'`: Permite o uso de recursos inline como `<script>` ou `<style>` inline, não recomendado por motivos de segurança.
*`'nonce'`: Uma lista branca para scripts inline específicos usando um nonce criptográfico (número usado uma vez).
*`'sha256-<hash>'`: Lista branca para scripts com um hash sha256 específico.
*`'strict-dynamic'`: Permite o carregamento de scripts de qualquer fonte se tiver sido listado na lista branca por um nonce ou hash.
*`'host'`: Especifica um host específico, como `example.com`.
*`https:`: Restringe URLs para aqueles que usam HTTPS.
*`blob:`: Permite que recursos sejam carregados a partir de URLs Blob (por exemplo, URLs Blob criados via JavaScript).
*`filesystem:`: Permite que recursos sejam carregados a partir do sistema de arquivos.
*`'report-sample'`: Inclui uma amostra do código violador no relatório de violação (útil para depuração).
*`'strict-origin'`: Semelhante a 'self', mas garante que o nível de segurança do protocolo das fontes corresponda ao documento (apenas origens seguras podem carregar recursos de origens seguras).
*`'strict-origin-when-cross-origin'`: Envia URLs completos ao fazer solicitações de mesma origem, mas envia apenas a origem quando a solicitação é de origem cruzada.
*`'unsafe-allow-redirects'`: Permite que recursos sejam carregados e redirecionem imediatamente para outro recurso. Não recomendado, pois enfraquece a segurança.
Se você de alguma forma conseguir fazer com que um **código JS permitido crie uma nova tag de script** no DOM com seu código JS, porque um script permitido está criando isso, a **nova tag de script será permitida a ser executada**.
No entanto, é altamente provável que o servidor esteja **validando o arquivo enviado** e só permitirá que você **faça upload de um tipo específico de arquivo**.
Além disso, mesmo que você consiga fazer o upload de um **código JS dentro** de um arquivo usando uma extensão aceita pelo servidor (como: _script.png_), isso não será suficiente, pois alguns servidores como o servidor apache **selecionam o tipo MIME do arquivo com base na extensão** e navegadores como o Chrome irão **rejeitar a execução de código Javascript** dentro de algo que deveria ser uma imagem. "Felizmente", existem falhas. Por exemplo, em um CTF eu aprendi que o **Apache não reconhece** a extensão _**.wave**_, portanto não a serve com um **tipo MIME como audio/\***.
A partir daqui, se você encontrar um XSS e um upload de arquivo, e conseguir encontrar uma **extensão interpretada erroneamente**, você pode tentar fazer o upload de um arquivo com essa extensão e o conteúdo do script. Ou, se o servidor estiver verificando o formato correto do arquivo enviado, crie um poliglota ([alguns exemplos de poliglotas aqui](https://github.com/Polydet/polyglot-database)).
#### Payloads usando Angular + uma biblioteca com funções que retornam o objeto `window` ([confira este post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
O post mostra que você poderia **carregar** todas as **bibliotecas** de `cdn.cloudflare.com` (ou de qualquer outro repositório de bibliotecas JS permitido), executar todas as funções adicionadas de cada biblioteca e verificar **quais funções de quais bibliotecas retornam o objeto `window`**.
De acordo com [**este relatório de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves) você pode abusar do [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) dentro de um CSP para executar código JS arbitrário, burlando o CSP:
Cenários como este, onde `script-src` está definido como `self` e um domínio específico que está na lista branca pode ser contornado usando JSONP. Os endpoints JSONP permitem métodos de retorno de chamada inseguros que permitem a um atacante realizar XSS, payload de trabalho:
A mesma vulnerabilidade ocorrerá se o **endpoint confiável contiver um Redirecionamento Aberto** porque se o endpoint inicial for confiável, os redirecionamentos também são confiáveis.
Conforme descrito no [seguinte post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), existem muitos domínios de terceiros que podem ser permitidos em algum lugar no CSP e podem ser abusados para exfiltrar dados ou executar código JavaScript. Alguns desses terceiros são:
Se você encontrar algum dos domínios permitidos no CSP do seu alvo, há chances de que você possa burlar o CSP se registrando no serviço de terceiros e, assim, exfiltrar dados para esse serviço ou executar código.
Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by allowing web developers to control the resources that a user agent is allowed to load for a specific web page. However, in some cases, CSP can be misconfigured or not implemented properly, leading to potential security vulnerabilities.
If a CSP allows `'unsafe-inline'` for script-src, it permits the execution of inline JavaScript code. This can be exploited by an attacker to execute arbitrary code inline, bypassing the CSP restrictions.
Using the `data:` URI scheme, an attacker can embed the contents of a script directly into the HTML document. If the CSP policy allows `data:` as a valid source for scripts, this technique can be used to bypass CSP restrictions.
Script gadgets are small pieces of code that can be used to bypass CSP restrictions by manipulating the behavior of existing scripts on the page. By leveraging script gadgets, an attacker can execute malicious code without triggering CSP violations.
Content Security Policy is a powerful security mechanism that can help protect web applications from various types of attacks. However, it is essential to configure CSP properly to ensure its effectiveness. By understanding common bypass techniques, developers and security professionals can better secure their web applications against potential CSP bypass vulnerabilities.
Deverá ser capaz de exfiltrar dados, da mesma forma como sempre foi feito com [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). Neste caso, siga estes passos gerais:
1. Vá para "Configurações -> Básico" e obtenha seu "ID do Aplicativo".
1. No site alvo de onde deseja exfiltrar dados, você pode exfiltrar dados diretamente usando o gadget do Facebook SDK "fbq" por meio de um "customEvent" e a carga de dados.
1. Vá para o "Gerenciador de Eventos" do seu aplicativo e selecione o aplicativo que você criou (observe que o gerenciador de eventos pode ser encontrado em uma URL semelhante a esta: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
Em seguida, no lado da vítima, execute o seguinte código para inicializar o pixel de rastreamento do Facebook para apontar para o ID do aplicativo do desenvolvedor do Facebook do atacante e emitir um evento personalizado como este:
### Bypass através de RPO (Sobrescrita de Caminho Relativo) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
Além da mencionada redireção para contornar restrições de caminho, existe outra técnica chamada Sobrescrita de Caminho Relativo (RPO) que pode ser usada em alguns servidores.
Isso funciona porque, para o navegador, você está carregando um arquivo chamado `..%2fangular%2fangular.js` localizado em `https://example.com/scripts/react/`, o que está em conformidade com CSP.
Assim, eles irão decodificá-lo, solicitando efetivamente `https://example.com/scripts/react/../angular/angular.js`, o que é equivalente a `https://example.com/scripts/angular/angular.js`.
A solução é não tratar `%2f` como `/` no lado do servidor, garantindo uma interpretação consistente entre o navegador e o servidor para evitar esse problema.
Se a diretiva **base-uri** estiver ausente, você pode abusar dela para realizar uma [**injeção de marcação pendente**](../dangling-markup-html-scriptless-injection/).
Além disso, se a **página estiver carregando um script usando um caminho relativo** (como `<script src="/js/app.js">`) usando um **Nonce**, você pode abusar da **tag base** para fazer com que ele **carregue** o script do **seu próprio servidor alcançando um XSS.**\
Se a página vulnerável for carregada com **httpS**, use um URL httpS na base.
Uma política específica conhecida como Content Security Policy (CSP) pode restringir eventos JavaScript. No entanto, o AngularJS introduz eventos personalizados como uma alternativa. Dentro de um evento, o AngularJS fornece um objeto único `$event`, fazendo referência ao objeto de evento do navegador nativo. Este objeto `$event` pode ser explorado para contornar o CSP. Notavelmente, no Chrome, o objeto `$event/event` possui um atributo `path`, que contém uma matriz de objetos implicados na cadeia de execução do evento, com o objeto `window` posicionado invariavelmente no final. Esta estrutura é fundamental para táticas de escape de sandbox.
Ao direcionar esta matriz para o filtro `orderBy`, é possível iterar sobre ela, aproveitando o elemento terminal (o objeto `window`) para acionar uma função global como `alert()`. O trecho de código demonstrado abaixo esclarece este processo:
Este trecho destaca o uso da diretiva `ng-focus` para acionar o evento, empregando `$event.path|orderBy` para manipular o array `path`, e aproveitando o objeto `window` para executar a função `alert()`, revelando assim `document.cookie`.
**Encontre outras formas de burlar o Angular em** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
Uma política CSP que lista permissões de domínios para carregamento de scripts em uma aplicação Angular JS pode ser contornada através da invocação de funções de retorno e certas classes vulneráveis. Mais informações sobre essa técnica podem ser encontradas em um guia detalhado disponível neste [repositório git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22).
Outros pontos de execução arbitrária JSONP podem ser encontrados [**aqui**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (alguns deles foram excluídos ou corrigidos)
O que acontece quando CSP encontra uma redireção do lado do servidor? Se a redireção levar a uma origem diferente que não é permitida, ela ainda falhará.
No entanto, de acordo com a descrição em [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), se a redireção levar a um caminho diferente, ela pode contornar as restrições originais.
Se o CSP estiver definido como `https://www.google.com/a/b/c/d`, uma vez que o caminho é considerado, os scripts `/test` e `/a/test` serão bloqueados pelo CSP.
No entanto, o `http://localhost:5555/301` final será **redirecionado no lado do servidor para `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Como se trata de um redirecionamento, o **caminho não é considerado** e o **script pode ser carregado**, contornando assim a restrição do caminho.
Portanto, a melhor solução é garantir que o site não tenha vulnerabilidades de redirecionamento aberto e que não haja domínios que possam ser explorados nas regras do CSP.
`'unsafe-inline'` significa que você pode executar qualquer script dentro do código (XSS pode executar código) e `img-src *` significa que você pode usar na página web qualquer imagem de qualquer recurso.
Você pode contornar esse CSP exfiltrando os dados por meio de imagens (neste caso, o XSS abusa de um CSRF onde uma página acessível pelo bot contém um SQLi e extrai a flag por meio de uma imagem):
De: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
Também é possível abusar dessa configuração para **carregar código JavaScript inserido dentro de uma imagem**. Por exemplo, se a página permitir o carregamento de imagens do Twitter, você poderia **criar** uma **imagem especial**, **fazer upload** dela no Twitter e abusar do "**unsafe-inline**" para **executar** um código JS (como um XSS regular) que irá **carregar** a **imagem**, **extrair** o **JS** dela e **executá-lo**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
Se um **parâmetro** enviado por você está sendo **colado dentro** da **declaração** da **política**, então você poderia **alterar** a **política** de alguma forma que a torne **inútil**. Você poderia **permitir script 'unsafe-inline'** com qualquer um desses bypasses:
Você pode encontrar um exemplo aqui: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
Desta vez, você pode fazer a vítima **carregar** uma página em **seu controle** via **XSS** com um `<iframe`. Desta vez, você fará a vítima acessar a página de onde deseja extrair informações (**CSRF**). Você não pode acessar o conteúdo da página, mas se de alguma forma você puder **controlar o tempo que a página precisa para carregar** você pode extrair as informações necessárias.
Desta vez uma **bandeira** será extraída, sempre que um **caractere for corretamente adivinhado** via SQLi a **resposta** levará **mais tempo** devido à função de sleep. Em seguida, você poderá extrair a bandeira:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
Este ataque implicaria alguma engenharia social onde o atacante **convence o usuário a arrastar e soltar um link sobre o bookmarklet do navegador**. Este bookmarklet conteria **código javascript malicioso** que, quando arrastado e solto ou clicado, seria executado no contexto da janela web atual, **burlando o CSP e permitindo roubar informações sensíveis** como cookies ou tokens.
Neste [**writeup de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), o CSP é burlado ao injetar dentro de um iframe permitido um CSP mais restritivo que proibia o carregamento de um arquivo JS específico que, então, via **poluição de protótipo** ou **dom clobbering** permitia **abusar de um script diferente para carregar um script arbitrário**.
No [**writeup do CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), foi possível, por meio de **injeção de HTML**, **restringir** ainda mais um **CSP** para que um script que impedia CSTI fosse desativado e, portanto, a **vulnerabilidade se tornasse explorável.**\
O CSP pode ser tornar mais restritivo usando **tags meta de HTML** e scripts inline podem ser desativados **removendo** a **entrada** permitindo seu **nonce** e **habilitando scripts inline específicos via sha**:
Se você conseguir fazer com que o servidor responda com o cabeçalho **`Content-Security-Policy-Report-Only`** com um **valor controlado por você** (talvez por causa de um CRLF), você poderia fazer com que ele aponte para o seu servidor e se você **envolver** o **conteúdo JS** que deseja exfiltrar com **`<script>`** e porque é altamente provável que `unsafe-inline` não seja permitido pelo CSP, isso irá **disparar um erro de CSP** e parte do script (contendo as informações sensíveis) será enviada para o servidor a partir do `Content-Security-Policy-Report-Only`.
- Um `iframe` é criado apontando para uma URL (vamos chamá-la de `https://example.redirect.com`) que é permitida pelo CSP.
- Essa URL então redireciona para uma URL secreta (por exemplo, `https://usersecret.example2.com`) que **não é permitida** pelo CSP.
- Ao escutar o evento `securitypolicyviolation`, é possível capturar a propriedade `blockedURI`. Essa propriedade revela o domínio da URI bloqueada, vazando o domínio secreto para o qual a URL inicial redirecionou.
É interessante notar que navegadores como Chrome e Firefox têm comportamentos diferentes ao lidar com iframes em relação ao CSP, levando a vazamentos potenciais de informações sensíveis devido ao comportamento indefinido.
Outra técnica envolve explorar o próprio CSP para deduzir o subdomínio secreto. Este método se baseia em um algoritmo de busca binária e na ajustagem do CSP para incluir domínios específicos que são deliberadamente bloqueados. Por exemplo, se o subdomínio secreto é composto por caracteres desconhecidos, você pode testar iterativamente diferentes subdomínios modificando a diretiva CSP para bloquear ou permitir esses subdomínios. Aqui está um trecho mostrando como o CSP pode ser configurado para facilitar esse método:
Ao monitorar quais solicitações são bloqueadas ou permitidas pelo CSP, é possível reduzir as possíveis caracteres no subdomínio secreto, eventualmente descobrindo a URL completa.
Ambos os métodos exploram as nuances da implementação e comportamento do CSP nos navegadores, demonstrando como políticas aparentemente seguras podem inadvertidamente vazar informações sensíveis.
Truque de [**aqui**](https://ctftime.org/writeup/29310).
Junte-se ao servidor [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) para se comunicar com hackers experientes e caçadores de recompensas por bugs!
O PHP é conhecido por **armazenar em buffer a resposta para 4096** bytes por padrão. Portanto, se o PHP estiver exibindo um aviso, fornecendo **dados suficientes dentro dos avisos**, a **resposta** será **enviada****antes** do **cabeçalho CSP**, fazendo com que o cabeçalho seja ignorado.\
Assim, a técnica consiste basicamente em **preencher o buffer de resposta com avisos** para que o cabeçalho CSP não seja enviado.
De [**este writeup**](https://blog.ssrf.kr/69) parece que foi possível contornar uma proteção CSP carregando uma página de erro (potencialmente sem CSP) e reescrevendo seu conteúdo.
ALGUNS é uma técnica que abusa de um XSS (ou XSS altamente limitado) **em um endpoint de uma página** para **abusar****de outros endpoints da mesma origem.** Isso é feito carregando o endpoint vulnerável de uma página do atacante e, em seguida, atualizando a página do atacante para o endpoint real na mesma origem que você deseja abusar. Dessa forma, o **endpoint vulnerável** pode usar o objeto **`opener`** no **payload** para **acessar o DOM** do **endpoint real a ser abusado**. Para mais informações, consulte:
Além disso, o **wordpress** possui um endpoint **JSONP** em `/wp-json/wp/v2/users/1?_jsonp=data` que irá **refletir** os **dados** enviados na saída (com a limitação de apenas letras, números e pontos).
Um atacante pode abusar desse endpoint para **gerar um ataque ALGUNS** contra o WordPress e **incorporá-lo** dentro de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` observe que esse **script** será **carregado** porque é **permitido por 'self'**. Além disso, e porque o WordPress está instalado, um atacante pode abusar do **ataque ALGUNS** através do **endpoint de retorno de chamada****vulnerável** que **burla o CSP** para conceder mais privilégios a um usuário, instalar um novo plugin...\
Para mais informações sobre como realizar esse ataque, consulte [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
Se houver um CSP estrito que não permita que você **interaja com servidores externos**, há algumas coisas que você sempre pode fazer para exfiltrar as informações.
<summary><strong>Aprenda hacking AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você deseja ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**swag oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao** 💬 [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe seus truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).