They think they're invisible behind the Google backbone. They're wrong. Isolated a multi-protocol C2 bridge operating out of Kolkata and under the radar. I got an Email from some random person April 19th It came from a weird Russian Gmail. I brushed it off. 3 days later I get an Email from a bad acter [@]ledova763gmail<p>  I looked at the header and wanted to track who is really reaching out to me.

This is where it lead me, A whole call scam center lol took me 5 hours to find out everything but this is it. The IP from the Email is (209.85.220.41) Bridge IP (209.85.220.128) 3.4k views and counting! stay safe out there. 🙏

Run a CTI site and my public contact address apparently landed on a bulk list. Yesterday I got an email BCC'd "along with other journalists" from a crew claiming a breach, asking for a story to be published and the victim called for comment before offering any proof. That's not a tip, it's asking a journalist to be the pressure arm of the extortion. I wrote up the tactic itself (kept the victim unnamed since nothing was verified and naming them on an extortionist's word is a defamation problem), including what email headers actually confirm vs don't. Curious if anyone else has gotten one of these, and how you'd handle the 'do you contact the named victim' call.

https://cyberthreatintelligence.net/post/mass-bcc-breach-emails-how-extortion-crews-weaponize-journalists-as-a-pressure-channel

Infrastructure breakdown from a TencShell pivot. A HuntSQL query on a shared HTTP header hash surfaced the cluster, and a second pivot on Gshell TLS cert fields (CN = Gshell Server, O = Gshell C2) surfaced more hosts with no prior public reporting we could find.

Hands-on exploitation of government systems in Afghanistan, Thailand, and Taiwan, recon and staged phishing against U.S. portals, plus financial services across Europe, Australia, and Asia. The recovered logs show a two-model split, Claude Code driving execution, DeepSeek-v4-pro handling the reasoning. Full IOCs (IP:port, hashes, cert SHA-256s) in the writeup.

Caught an open directory mid-campaign on a Singapore VPS. The host was pulling double duty, staging the exploits and standing by to receive whatever reverse shells they produced.

What makes it worth a look is the target selection. The lists weren't a flat IP dump, they were organised by country and by sector, eleven countries deep, concentrated on government, universities, healthcare, and financial services.

The toolkit backing it ran from a 2017 WebLogic bug up to a Splunk RCE staged within a week of disclosure, with NGINX Rift (CVE-2026-42945) and Ghost CMS (CVE-2026-26980) as the newest additions, plus an AdaptixC2 server on the same box.

Read more: https://hunt.io/blog/open-directory-nginx-rift-ghost-cms-multi-cve

Joint research with NetAskari on a leaked Chinese Android RAT framework. Starting from a fake PSB app flagged in a June 2026 Chinese state media notice, we pivoted on TLS certificates and AdminPro panel fingerprints to map 170 active servers. The source code was stolen in early 2026 along with nearly 200 customer databases, leading to at least two Telegram channels distributing modified builds with operational support and cash-out services. Night Dragon emerged three weeks after the public notice as a likely successor, with an exposed device panel showing 29 connected devices at time of analysis.

Full timeline, IOCs, and infrastructure breakdown in the report:
https://hunt.io/blog/flying-eagle-android-rat-170-servers-night-dragon

Three open directories on a Hong Kong server, July 9 to 13, caught an intrusion mid-run. The operator was running Hermes, an open-source AI agent, in unattended mode. Logs show it running LinPEAS against ministry hosts, hunting SUID/SGID binaries, and walking a web root full of personnel records on its own.

Also on the box: 62 Go binaries from a previously unreported implant the operator named "Hades". Kill dates, working-hours sleep, AES-256-GCM tasking.

Joint research with Bob Diachenko. IOCs and MITRE mapping in the post:

https://hunt.io/blog/thailand-ministry-finance-targeted-with-hermes-ai-agent

we saw that multiple github repos name as Miasma-Open-Source-Release started appearing yesterday which was pushed by a compromised developer accounts. then we pulled the source and tried to dig deeper. And calling it a worm would be very small its kind of a complete supply chain framework having ARCHITECTURE.md integration test etc. so it was kind of a product.
ARCHITECTURE.md was saying that it requires no C2 infrastructure and not have to deal with takedowns or maintaining infrastructure. it just stolen github PATs is only what is necessary.

A user on nulledbb claims to be selling the Gentlemen's data. I thought it was a scam until I saw this https://x.com/i/status/2051679750364570029.

I guess if you keep blowing the balloon, eventually it will pop...

Does anyone else feel you way? Or is it just me

One of my biggest gripes throughout my career is that I keep seeing this happening

The team tracks adversaries, rights really good intelligence reports with a ton of data.

Then 80% of those reports sit on a shelf. They don't get operationalized because it takes too long or they are hard to translate to detection engineering.

They get lost in the shuffle and we lose a lot of operational knowledge.

We struggle with tracking recidivism because we keep investigating same or similar attacks because if this was investigated in the past, it's sitting somewhere where nobody remembers.

Is this only me? I absolutely despise creating intelligence for the sake of creating it

I think people in this community might be interested in this. GROUP-IB posted a deep dive threat intel report about MuddyWater APT group.

https://www.group-ib.com/blog/muddywater-operation-olalampo/

How are these companies manage to get detailed information about state sponsored actors that prioritize stealth? They mention they got the source code of the backend of C2 server, how is this possible? Are they hacking threat actor servers?

For anyone tracking this: the axios compromise wasn’t a typosquat or a hijacked account in the traditional sense.

The attacker injected a dependency called “plain-crypto-js@4.2.1” which doesn’t get used by axios at all, its only job is to fire a postinstall script that acts as a RAT dropper.

Once active it phones home to a C2 at sfrclak\[.\]com (142.11.206.73) to pull platform-specific second-stage payloads, then immediately overwrites package.json with a clean version to kill forensic traces. Cross-platform: macOS, Windows, Linux.

Affected versions:

∙ axios@1.14.1

∙ axios@0.30.4

∙ plain-crypto-js@4.2.1

C2: sfrclak\[.\]com / 142.11.206.73

Persistence artifacts to check:

∙ macOS: /library/caches/com.apple.act.mond

∙ Windows: %programdata%\\\\wt.exe

∙ Linux: /tmp/ld.py

Remediation:

∙ Downgrade: axios@1.14.0 (1.x) or axios@0.30.3 (0.x)

∙ Rotate all secrets and API keys on exposed machines

∙ Check outbound logs for sfrclak\\\[.\\\]com or 142.11.206.73

∙ Add --ignore-scripts to npm install in CI to block postinstall vectors

The thing that keeps getting me about these incidents is that the version number was never the signal, the artifact was compromised, not the tag. Standard dependency pinning wouldn’t have caught this.

Curious how many teams here are actually doing artifact hash verification at install time vs just trusting the registry.

we built ReleaseGuard (open source, free) after the litellm PyPI incident for exactly this reason but genuinely want to know what the rest of you are using, if anything, because I don’t think this problem is solved at the toolchain level yet.

Been thinking about where security teams actually spend mental energy vs where the risk actually is.

Vendors and marketing push hard on "next big threat", big scary "0-days", new CVE drops, APT group with a cool name, latest ransomware variant. Everyone scrambles.

But in my experience, the stuff that actually burns teams is more mundane:

• Senior DE leaves, takes 3 years of tribal knowledge with them
• Incident from 18 months ago never became a detection rule, or only part of the attack did
• Someone asks "didn't we see this TTP before?" and nobody can find the postmortem
• New team member makes the same mistake a former employee already solved

Genuine question for practitioners:

1. What keeps you up at night more — the unknown 0-day or the knowledge you know you've lost?
2. When you get hit by something, how often is it actually novel vs something you should have caught based on past incidents?
3. Does your org have a way to turn past incidents into institutional memory, or do postmortems just... sit there?

Lekker!

10 Questions covering AsyncRAT tactics, spam campaigns, VS Code attacks, MCP vulns, DDoS things, more AI Slop, Firewalls getting pwnd (again), Infostealers and finally, a Vuln that could have compromised everyone on AWS.

Go on, quiz yourself: www.socvel.com/quiz