Threat Intel
We can see from Defused honeypots and conducting a triage that CVE-2026-34910 (updated as I had the wrong CVE number, wrong as in this packet does show a traversal but is the using command exec) is being exploited in the wild!
Read more “CVE-2026-34910 Exploitation ITW – building a botnet (MIRAI)”
Education
SPF and DMARC stop criminals from sending email as you. MTA-STS stops attackers from intercepting email sent to you. They defend different things, and you need all three. Here’s what each one actually protects against — and why MTA-STS, the one almost nobody has enabled, is the obvious next step.
Read more “Lock Down Your Email: SPF and DMARC as the Baseline — Then Turn On MTA-STS”
Vulnerabilities
Ok, fun things to learn about me, I don’t like CVEs or CVSS because my brain can’t really read them! I have the same challenge with some server naming standards. I need something like SRV-UK-ADDS-01 if it’s not goy hyphens I need a tool to read them for me! (true story!). So lets look at CVSS (I know I’m full of fun topics).
Read more “CVSS Scoring is fun they said!”
Leadership
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.
Read more “Email Security: An Enablement Journey, Not a Maturity Ladder”
Research
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.
Read more “The State of DNS Security — Where the Top Million Stands: DNSSEC, Email Authentication & DANE by the Numbers”
Leadership
‘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!
Read more “DNSSEC”
Cybercrime
When we look at ‘sextortion’ and ’email based extortion’ tactics used by threat actors we see a common pattern, one that leverages shame & fear. I’ve worked with some victims of this and it’s really not nice for them, the impacts are not just financial, they are emotional and sometimes more. It’s fortunately (for me) don’t however deal with this in volume, however I wanted to highlight something, the similarities between extortion and what I would describe as ‘Security Scanning’ shame scamming. Now you might think, that’s a massive leap… but bear with me, I’ve been looking at this (CTI/OSINT) plus working with ‘victims’ for years…
I’ll be posting about some research I’ve done on DNSSEC shortly too, I’ve kind of figured this topic was over years ago, but it’s recently come back on my radar, you know sometimes ‘duty calls’. But let’s look at shame based extortion patterns for now:
Read more “Using shame to enable extortion”
Vulnerabilities
Fast publish: If the past gives us any indication for the future, if you are running MoveIT you want to be aware of:
Read more “I like to MoveIT MoveIT”
Threat Intel
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.
We have used ‘AI’ (Claude) to create a timeline based on packets from Defused honeypots:
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 vectorGET /scripts2/listaccts as the cache gadget trigger/json-api/ endpoints within seconds of gadget confirmationWorth 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!
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…
AI
Do you ever struggle to keep up with the cyber world? Not everyone is plugged into the internet 24/7 as some people (I swear I get offline sometimes!) so keeping up to date with the cyber world can be pretty tricky! Also who has time to read everything? no one that’s who! But what about if we used an LLM to read things for us and then give us an update? Well here’s an example of this!
Read more “Using AI in a positive (non scary) way”