Veio do Bug Bounty Reports Explained, então é confiável e com grande valor / profundidade
https://youtu.be/9tNUPpB1gto
Em resumo ele mostra um cenário que tinham um SSRF blind e através de um script que subiram num host externo e que fazia 5 redicionamentos, apos o quinto a aplicação estourava um erro, o que auxiliou ele a aumentar o impacto do achado.
Vou até testar isso em um cenário que eu tenho aqui, vai que né.
Vou até testar isso em um cenário que eu tenho aqui, vai que né.
https://slcyber.io/assetnote-security-research-center/novel-ssrf-technique-involving-http-redirect-loops/
This drove us nuts. Was there something special about the 305 status code? Even though we performed a redirect from 301 to 310, why did we only get the HTTP responses from status code 305 and beyond?
Was this an issue with libcurl? After extensive analysis of the libcurl source code and this application’s binary, we don’t think so.
Instead, we believe that the application was happy to follow a few redirects (and failing on JSON parsing) and was not happy about following more than the max redirects configured for libcurl. However, there was an error state when it followed more than five redirects, not handled by libcurl but rather by the application itself.
"Nenhuma decisão importante sobre o kernel foi tomada, mas talvez no próximo jantar 😉"
Achei fera porque já peguei esse comportamento esses tempos em bugbounty e não entendia muito bem por que ele ocorrida, achei que era algum load balancer envolvido.
Procurando pelo termo domain fronting cai em uma apresentação na defcon muito interessante:
https://cendyne.dev/posts/2023-09-08-domain-fronting-through-azure-and-cloudflare.html
Hoje o dia foi corrido, mas esse é o estudo de hoje.
Cheers,
Com Jason Haddix e promovido pela TCM
Treinamento/ Workshio gratuito de Operationalizing Cybercrime Data for Red Teams & Offensive Ops!
Se registre em:
https://flare.registration.goldcast.io/webinar/1e64a56c-d31e-4481-afe3-9b8f40ad07be
Artigo p/ ler depois ++
Aprofundamento em desserialização insegura (vlw pela call N1nja):
https://klezvirus.github.io/Advanced-Web-Hacking/Serialisation/
Aprofundamento em desserialização insegura (vlw pela call N1nja):
https://klezvirus.github.io/Advanced-Web-Hacking/Serialisation/
Quando eu falo de um ataque complexo clientside, falo de algumas chains muito bem elaboradas.
Tipo essa do Vitor Falcão(busfactor) com o XssDoctor. Conseguiram ela escalando um self xss pra um full xss, usando CSPT (client side path traversal) + JSON + SelfXss -> Cookie path -> xss:
https://blog.vitorfalcao.com/posts/hacking-high-profile-targets/
Link novo: https://vitorfalcao.com/posts/hacking-high-profile-targets/
Mad respect 🫡
Tipo essa do Vitor Falcão(busfactor) com o XssDoctor. Conseguiram ela escalando um self xss pra um full xss, usando CSPT (client side path traversal) + JSON + SelfXss -> Cookie path -> xss:
Link novo: https://vitorfalcao.com/posts/hacking-high-profile-targets/
Mad respect 🫡
Update sobre meus estudos ongoing:
- To cada vez mais obsecado por aprender mais e mais sobre Odata
- Ainda pretendo fazer um artigo sobre a falsa sensação de segurança que desenvolvedores tem sobre o uso de CryptoJS no frontend e como as pessoas usam ele para o objetivo errado: ele não nasceu pra ser uma proteção de tampering, ou que impossibilite MitM estilo TLS
Um artigo de exploração que vi agora no medium que junta exatamente esses dois temas de exploração de um banco:
https://medium.com/@_yldrm/client-side-encryption-bypass-critical-data-breach-by-manipulating-odata-queries-3abcaa81ed2e
boa leitura. Cheers🥂
- To cada vez mais obsecado por aprender mais e mais sobre Odata
- Ainda pretendo fazer um artigo sobre a falsa sensação de segurança que desenvolvedores tem sobre o uso de CryptoJS no frontend e como as pessoas usam ele para o objetivo errado: ele não nasceu pra ser uma proteção de tampering, ou que impossibilite MitM estilo TLS
Um artigo de exploração que vi agora no medium que junta exatamente esses dois temas de exploração de um banco:
https://medium.com/@_yldrm/client-side-encryption-bypass-critical-data-breach-by-manipulating-odata-queries-3abcaa81ed2e
boa leitura. Cheers🥂
Eu realmente curto muito esse grupo por que usufruo das anotações que faço aqui quando quero ver algo interessante hahaha.
Alguns highlights desse vídeo que acabei de assistir e pra variar, foi MT valendo:
* Todo mundo sabe como os sistemas deveriam funcionar (especificados nas RFCs), mas eu gosto de ver como os sistemas realmente estão se comportando. James falou que vai apresentar na blackhat conference esse ano uma ferramenta que fez com outro pesquisador que busca encontrar comportamentos anômalos em diferentes servidores e CDNs / de forma massiva.
* “Teve algum momento que estava lendo sobre HTTP response splitting e todo artigo que voce olhava para o payload tudo o que voce via era uma injecao de um cabecalho na resposta.
E nisso tem algo engraçado: porque todo mundo chama de response splitting quando se esta claramente só adicionando uma header na resposta.
Na verdade o termo foi inventado quando se injetava uma resposta inteira causando uma dessincronizacao no servidor (http desynk), mas esse conhecimento foi esquecido e o nome permaneceu o mesmo.”
E nesse gap da comunidade não entender profundamente aquele topico e provavelmente nem mesmo desenvolvedores, ele diz entao que isso chamou a atencao dele para pesquisar mais sobre o tema.
Curtiu? Já sabia essa do http response splitting?
Alguns highlights desse vídeo que acabei de assistir e pra variar, foi MT valendo:
* Todo mundo sabe como os sistemas deveriam funcionar (especificados nas RFCs), mas eu gosto de ver como os sistemas realmente estão se comportando. James falou que vai apresentar na blackhat conference esse ano uma ferramenta que fez com outro pesquisador que busca encontrar comportamentos anômalos em diferentes servidores e CDNs / de forma massiva.
* “Teve algum momento que estava lendo sobre HTTP response splitting e todo artigo que voce olhava para o payload tudo o que voce via era uma injecao de um cabecalho na resposta.
E nisso tem algo engraçado: porque todo mundo chama de response splitting quando se esta claramente só adicionando uma header na resposta.
Na verdade o termo foi inventado quando se injetava uma resposta inteira causando uma dessincronizacao no servidor (http desynk), mas esse conhecimento foi esquecido e o nome permaneceu o mesmo.”
E nesse gap da comunidade não entender profundamente aquele topico e provavelmente nem mesmo desenvolvedores, ele diz entao que isso chamou a atencao dele para pesquisar mais sobre o tema.
Curtiu? Já sabia essa do http response splitting?
Videos from day 1, June 4:
- YouTube/ Security Fest: Hackers in Fiction / John Wilander
- YouTube/ Security Fest: Is there a before and an after, or a happily ever after? / Patricia Lindén
- YouTube/ Security Fest: Finding Vulnerabilities in Apple packages at Scale / Csaba Fitzl
- YouTube/ Security Fest: Hack in a box Local Language Models for automating Red Teaming and penetration testing / Skjortan
- YouTube/ Security Fest: Plundering and pillaging password and passphrase plains for profit / Will Hunt
- YouTube/ Security Fest: Closer to 0-day - Emil Trägårdh
Videos from day 2, June 5:
- YouTube/ Security Fest: Integrating AI with Retro Hardware / A Commodore 64 LLM Module / Marek Zmysłowski, Konrad Jędrzejczyk
- YouTube/ Security Fest: Privacy, Veilid, And You / Christien ‘DilDog’ Rioux
- YouTube/ Security Fest: SonicDoor / Cracking open SonicWall’s Secure Mobile Access / Alain Mowat
- YouTube/ Security Fest: Anti-Forensics / You are doing it wrong (Believe me, I’m an IR consultant) / Stephan Berger
- YouTube/ Security Fest: Modernizing Incident Response Using Techniques that Scale / Eric Capuano, Whitney Champion
- YouTube/ Security Fest: Hack the Gap Closing the CTI Divide Between Small Teams and Big Players / Chandler McClellanhttps://m.youtube.com/watch?v=pCuFGmblha4
Update: anunciou que por padrao vai ficar 20% off até dia 30
Lembram aquele post que fiz aqui sobre a criação de túneis do Cloudflare que facilitou pra gente expor um serviço local na internet rapidamente usando um domínio trycloudflare.com para testes, como em cenários de SSRF onde precisávamos de um endpoint público sem banners ou restrições de headers?
Pois é, os atacantes estão utilizando essa mesmíssima funcionalidade do Cloudflare para se camuflar na confiabilidade dessa organização para hospedar seus payloads maliciosos e infraestrutura de comando e controle, tornando a detecção e o bloqueio de suas atividades bem mais complicados para as equipes de defesa.
A campanha SERPENTINE#CLOUD exemplifica isso: e-mails de phishing com ZIPs contêm arquivos .LNK disfarçados. Estes, ao abertos, baixam um Windows Script File (WSF) de um WebDAV em subdomínio Cloudflare Tunnel. O WSF aciona um .BAT de outro domínio Cloudflare, que exibe um PDF chamariz, verifica AV, e baixa/executa loaders Python. Esses loaders usam o empacotador Donut para injetar RATs (como AsyncRAT, Revenge RAT) diretamente na memória, evadindo detecção.
Usar *.trycloudflare.com é estratégico: o tráfego pela infraestrutura legítima do Cloudflare dificulta a distinção entre atividades benignas e maliciosas, permitindo contornar bloqueios de URL/domínio e operar sem C2 tradicional. A campanha (EUA, UK, DE, etc.) evoluiu de arquivos .URL para .LNK e já foi associada à distribuição de GuLoader, PureLogs Stealer, Remcos RAT e XWorm.
Pois é, os atacantes estão utilizando essa mesmíssima funcionalidade do Cloudflare para se camuflar na confiabilidade dessa organização para hospedar seus payloads maliciosos e infraestrutura de comando e controle, tornando a detecção e o bloqueio de suas atividades bem mais complicados para as equipes de defesa.
A campanha SERPENTINE#CLOUD exemplifica isso: e-mails de phishing com ZIPs contêm arquivos .LNK disfarçados. Estes, ao abertos, baixam um Windows Script File (WSF) de um WebDAV em subdomínio Cloudflare Tunnel. O WSF aciona um .BAT de outro domínio Cloudflare, que exibe um PDF chamariz, verifica AV, e baixa/executa loaders Python. Esses loaders usam o empacotador Donut para injetar RATs (como AsyncRAT, Revenge RAT) diretamente na memória, evadindo detecção.
Usar *.trycloudflare.com é estratégico: o tráfego pela infraestrutura legítima do Cloudflare dificulta a distinção entre atividades benignas e maliciosas, permitindo contornar bloqueios de URL/domínio e operar sem C2 tradicional. A campanha (EUA, UK, DE, etc.) evoluiu de arquivos .URL para .LNK e já foi associada à distribuição de GuLoader, PureLogs Stealer, Remcos RAT e XWorm.
https://thehackernews.com/2025/06/new-malware-campaign-uses-cloudflare.html
