Sharon Brizinov made ~$64k by recovering secrets from deleted files in public Git repos. Even after using git rm, files remain in the history stored in the .git/objects dir until garbage collection runs.

Here's the command to use: Methodology:
- Clone target repos
- List all Git objects (e.g., using git rev-list --objects --all) to expose dangling blobs and restored files
- Search through deleted commits, orphaned branches, and stashed content for leaked secrets

Ok, so @slonser_, some of the folks in the CTBB discord, and I (@rhynorater) did a bit of follow-up on this and found a couple more useful primitives:

https://twitter.com/slonser_/status/1919439373986107814

First, this can be done recursively and, since we can specify multiple URLs per Link header (or multiple Link headers, if you prefer), we can create a continuous stream of requests to our server from a single attacker-controlled image being loaded.

A Google iframe component used across multiple products had weak origin validation. We used postMessages, CSPT, and Google’s RPC API to exfiltrate data. The iframe’s flexibility made origin validation difficult (for them). ↓ Google’s requests via this iframe included an Authorization header by default.
The iframe made two requests:

1. Domain validation where the malicious postMessage's origin is passed into a request via query param ?domain=attacker..com
2. The actual request/returned data

Last year, @joaxcar found a way to hide payloads in URL creds.

Inspired by this, @garethheyes pushed the research further, revealing new attack vectors and WAF-blind spots.

Here’s a quick breakdown of what they discovered 👇 @joaxcar @garethheyes 1️⃣ Understanding the URL Credential Discrepancy

Did you know document.URL includes credentials, while location doesn’t? This opens a way to test hidden payloads in the credentials part of a URL.

🧵 1/6

Team Critical Thinking (@0xLupin & @Rhynorater) hit up Vegas last week for the Google BugSwat!

Here are their 8 key takeaways from the event: @0xLupin @Rhynorater 1. Focus on the main app

Target the primary application of your target. It’s often under active development, meaning new features and frequent updates—prime conditions for new bugs to appear.

New functionality means new gadgets, and often, new vulnerabilities.

1/8

.@H4R3L's "Cookie XSS" affecting almost every Zoom page and subdomain demonstrates the effectiveness of experimenting with escape characters in cookie values.

Details in thread. @H4R3L It all started when @H4R3L discovered a CSP Nonce cookie that was being used in every page with a CSP policy.

Because Zoom takes their security seriously, there was a CSP policy on almost every page!

IIS Hacking tips from the latest episode with the master himself @infosec_au:
1. NEVER leave that blue IIS page un-touched
"You see that blue page that comes up when you hit an IIS server? That should be your point where you think, I'm gonna find criticals on this bad boy. 2. Use shortscan or other shortname scanners to enumerate directory and file shortnames
IIS is vulnerable to short name file enumeration. This allows you to determine the first 6 chars of the name and 3 chars of extension.
github.com/bitquark/short…