blue team – PwnDefend

How likely is successful mass exploitation of PHP2SHELL?

Never in a high alert scenario should be try and be too solid with our predictions, because this game is difficult! but given PHP2SHELL day is such a mad day, I’m going to break my typical model, however:

Personal view: this is a HIGH ALERT scenario but not an ACTIVE EXPLOITATION scenario (at the time of writing), so this is SERIOUS and requires paying attention to!

but the question, how likely is this to lead to mass exploitation? is there REAL tough and serious question we have to ask when considering the wider landscape of national security etc. so I’m going to at least explore it a bit!

Leadership

PASSKEYS ARE NOT A TRAP

This is one of the strangest takes on security I’ve seen in a while: passkeys are a trap, do not use them (WTF).

It’s 12 pages and over 4,000 words, an essay mixing real facts with a lot of invalid and odd reasoning. Not everything in it is untrue, which is what makes it slippery. Here are the claims that make up the main bulk of the argument, and why they don’t make sense:

1. “2FA and TOTP are the superior option, and FIDO ignored them.”
TOTP can be phished by relaying the code live. An attacker proxy forwards your password and your six digits to the real site and keeps the session. The 30-second expiry is irrelevant when the attacker uses the code immediately. FIDO’s own U2F predates passkeys and was built to fix exactly this.

2. “Transferable versus non-transferable passkeys.”
A non-exportable hardware credential can’t be moved by definition. It’s a distinction invented to make the catalogue look bigger.

3. “Attestation comes with passkeys whether you want it or not.”
It’s optional. A site asks for it at registration, and browsers gate identifying attestation behind a consent prompt. As far as I know, the synced passkeys most people use offer little or none of it to sites.

4. “Sites will quietly start rejecting non-attested passkeys in staggered waves.”
Attestation is returned once, when the credential is created. A site can’t retroactively demand it from existing passkeys. It would have to force everyone to re-enrol, which is anything but quiet. His own footnote 9 admits sites can’t even check who would pass.

5. “Attestation needs your chip, passkey manager, OS and firmware to all pass.”
That describes Play Integrity and App Attest, which are different mechanisms. WebAuthn attestation identifies the authenticator, not your whole stack. Android key attestation does include boot state, but it describes a key, not what’s installed on your phone.

6. “Attestation lets vendors block encrypted messaging and rival apps.”
It doesn’t inventory your software. Any vendor who wants to gate on device integrity already has Play Integrity and App Attest, and not a single passkey is needed for that.

7. “Attestation lets Google lock out other browsers and extensions like uBlock Origin.”
WebAuthn doesn’t attest the browser. The uBlock Origin removal was a Manifest V3 decision with nothing to do with authentication.

8. “A YubiKey avoids the attestation problem because it’s self-contained.”
A YubiKey in FIDO mode is a WebAuthn authenticator. It’s exactly the kind of device an allowlist would admit. If attestation is the threat, the recommendation doesn’t avoid it.

9. “So don’t use passkeys. Use TOTP.”
The conclusion is to prefer passwords and TOTP, which are phishable, over passkeys, which resist phishing through domain binding. For the non-technical audience he’s writing for, the real alternative is a reused password with SMS as the second factor.

Underneath it all, the objection is distrust of the FIDO Alliance, distrust of service providers, and loss of control. But a service has always decided who gets in. It can disable your account, set password rules and force MFA. Choosing which authenticators it accepts is the same kind of decision, and it concerns their service, not your device. He even tells readers to put on a tinfoil hat.

The lock-in worry is fine to have, there are potential risks with implementation with some providers (but that’s always true whenever you use a third party service!). “Don’t use passkeys” is the wrong conclusion, and the essay gives the game away itself. Footnote 13 admits passkeys are domain-bound and resist man-in-the-middle attacks, and the opening concedes they can be far more secure than passwords.

So in short: they even tell you, passkeys are more secure and more convenient.

The more I look at the 12 pages of essay (and god there are footnotes!) the more I just want to block the URL… so so so many words, to self own!

I use passkeys! I broadly believe that without specific requirement statements, I’d say: default to passkeys! Are they perfect? No, are they better than username and passwords for most things? sure! Do you need to ensure you have a plan for failure scenarios? 100% that’s true of basically everything! We have backups as a concept for a reason!

This was attempt 3 of this response, I decided an essay on an essay is probably not the right approach, drowning in words doesn’t change the facts! Once again, it seems like we spend more time combatting myths than fighting baddies! A strange cyber world we live in!

Machine Speed

I have been both watching/listening and in meetings where I have heard some ‘interesting’ statements about ‘machine speed’ hacking by with unlimited capacity and unlimited speed….

You can, if you know me, imagine my expression on my face, however I figured let’s not settle for ‘Trust me bro it doesn’t work like that’, let’s do some SCIENCE!

(I know everyone loves scientists these days after they pluck numbers out of their ass and say things like: there is a 10-70% chance AI will destroy humanity in the next 5 years’ (and have zero evidence for the math let alone evidence for the risk model other than ‘trust me, I’m super smart’).

I’m not that smart so I do actual testing of theories, and then I share things, I know, I’d make a terrible ‘scientist’. It’s hot in the lab today so this will be a quite a brief view but should contain the key details.

Threat Intel

Remote Desktop Protocol + NLA Honeypots

I’ll probably update this later, but I wanted to at least show people some research I’ve been doing recently (with some support from some wonderful people in the cyber security community!)

Here’s a quick PDF! I’ll do an interactive HTML version next, but duty calls!

Vulnerabilities

WP2SHELL Update

This morning I’ve started to see exploitation attempts on pwndefend.com (they all failed because like about 80% of sites (based on sampling) this site automatically patched, but also, this site has word fence, is fronted by Cloudflare.

Global Exposure

On the 18th (AM) I did sampling of about 3.5K hosts and found ~20% were not patched. The cyber apocalypse is not seemingly here today! (let alone the fact that if every WordPress site was popped, the world would probably not end)

Threat Intel

Bleeding Out

When you compromise a firewall you have lots of options in terms of next steps, from using the VPN, changing configurations, creating backdoors or perhaps using the firewall to PCAP. In this post I’m going to explore the ‘Fortibleed’ campaign. I have to note, we can see in honeypot logs this TA did not seem to limit themselves to Fortinet exploitation, however the area of analysis has a heavy Fortinet element. You will see they deployed a capture and analysis platform. Treat everything with a pinch of salt because I’m using a mad probability based machine (LLM) to support me for this!

Leadership

Email Security: An Enablement Journey, Not a Maturity Ladder

Most organizations treat email authentication as a checkbox exercise. Deploy SPF, publish DMARC in reporting mode, call it done. But the real story isn’t about maturity tiers—it’s about what you unlock at each phase of implementation. And frankly, the gap between where organizations are and where they need to be is brutal.

This post outlines an enablement journey: each phase builds on the previous one and creates new capabilities that weren’t possible before.

Research

The State of DNS Security — Where the Top…

A position snapshot of the full Majestic Million across three layers — DNSSEC signing, email authentication (SPF / DMARC / MTA-STS), and DANE. This is the scorecard: what is deployed, on how many domains, and how it’s distributed by rank and TLD. Remember Majestic Million is a bit old so a chunk of the domains no longer resolve, but the data gives a good thematic view.

Leadership

DNSSEC

‘You are totally compromised!’ because you don’t have DNSSEC configured on domain…..

The implication is that you’re one packet away from catastrophe. It’s alarming. It’s also, for the overwhelming majority of organisations, not true. I have been talking about this for years and years!

Here’s the quickest way to see through it. I scanned the Majestic Million – the top one million domains on the internet – for DNSSEC. About 6.75% were signed (around 8.2% if you only count domains that actually resolve). The .com zone, which is half the list, sits at 4.6%. And the unsigned set includes google.com, amazon.com and microsoft.com.

So if “no DNSSEC” means “totally compromised,” then the three most-attacked, best-defended companies on the planet are totally compromised, and have been for years, on purpose. They aren’t. The finding is measuring conformance to a checklist, not risk. Let’s understand why this is!

Threat Intel

cPanel Vulnerability Exploited ITW

Mass iternet exploitation events are never fun, this week we have CVE-2026-41940 being exploited! Luckily we have the awesome and cool honeypots at Defused to help us investigate threat actor activity! So let’s take a look! (there’s a good writeup here from Watchtowr.

Kill Chain

We have used ‘AI’ (Claude) to create a timeline based on packets from Defused honeypots:

What did Claude say?

I exported the logs from the Defused honeypot TI feed focused on a single IP then imported that include a chat with Claude:

Here’s the breakdown of what the data shows:

Attack summary — CVE-2026-41940 against a cPanel honeypot

The attacker at 80.87.206.131 ran a structured, two-wave exploitation chain over approximately 22 minutes. The CVE pattern maps to a known cPanel authentication bypass class: forge a session via the preauth endpoint, propagate it through a cache gadget, then leverage the resulting authenticated context to make privileged JSON-API calls.

Wave 1 (06:36–06:37) was a minimal two-step probe — session mint followed immediately by a single cache propagation attempt. This is consistent with tooling running an initial reachability check before committing to full exploitation.

Wave 2 (06:57–06:58) is the main effort. The attacker repeated the session mint, fired the cache gadget twice (likely confirming propagation), and within 9 seconds of the second gadget request had transitioned to authenticated API calls — specifically authorizesshkey (SSH key injection) and listaccts (account enumeration). The two events timestamped 06:58:28suggest either a scripted burst or the tooling executing the auth’d phase in parallel.

Key indicators for hunting:

POST /login/?login_only=1 as the session mint vector
GET /scripts2/listaccts as the cache gadget trigger
Rapid pivot to /json-api/ endpoints within seconds of gadget confirmation
20-minute gap between waves is characteristic of automated tooling with a callback/retry loop

Worth checking whether 80.87.206.131 appears in any other decoy logs — the structured cadence strongly suggests an automated exploit kit rather than manual operation.

We can see here, the exploit here is very simple, POST then a GET followed by API access!

Not only do we now have data to write detections from, we can also look at creating a PoC for penetration testing and vulnerability assessment purposes! A double win! This really goes to show how valuable honeypots can be from a broad TI perspective as well as supporting defence and offence!

A double edged sword (or pot?), like so many things in life!

Suggested Actions to take

Check if you or your hosting providers run CPANEL
Check for compromise (or request intel from a partner)
If no compromise detected patch the server
- if you can’t patch consider using an IP allow list/VPN or other method to shield access from anywhere on the internet (you might want to do this even if you have patched)
If compromised follow your incident repsonse process

Each scenario is different so I’ll not try and tell everyone exactly what they should do here, the key point of this blog is to highlight the vulnerability, the threat/risk so people can take the appropriate steps.

Also, you probably want to check out the honeypots at Defused! They are awesome!

[update] just found this in the packets: H2ckt3ch@g0dl1k3 (cm9vdDpIMmNrdDNjaEBnMGRsMWsz is the BASE64). I won’t publish all the packets right now (because that probably won’t help this early on) but this string was interesting…