Best of the Worst: Five Attacks That Looked Broken (and Worked)
The post Best of the Worst: Five Attacks That Looked Broken (and Worked) appeared first on Blog.
I skipped last week’s roundup. Holiday weekend, family stuff, the usual.
Best of the Worst: Five Attacks That Looked Broken (and Worked)
The post Best of the Worst: Five Attacks That Looked Broken (and Worked) appeared first on Blog.
I skipped last week’s roundup. Holiday weekend, family stuff, the usual. So this is a two-week-ish view of what we’ve published in the Threat Intelligence series since Edition 03 dropped on April 13.
Quick context for new readers. Every week, I pull a handful of real phishing attacks we caught, sit with them for a bit, and try to find the thread connecting them. Last edition was about precision: surgical attacks built for a specific recipient before the send. The kind of attack that took reconnaissance and patience.
This edition is the opposite story.
The five attacks below were sloppy work.
Several had quality-control failures the attackers themselves should have caught before launch. One had two letters transposed inside the word Missouri. One had Mustache template variables sitting in the email body as raw text. One pasted “adobe.com” into a directory path of an obviously malicious domain.
They all reached inboxes anyway.
This is the part of the threat picture that doesn’t make conference keynotes. Plenty of inbox-resident phishing this month came from operators running cheap, fast, broken kits. They do not care if the kit is broken (because the gateway will deliver it for them).
5 Attacks. One Embarrassing Floor.
In When the Phishing Kit Ships Early: Exposed Template Variables Reveal Attack Infrastructure, the operator forgot to populate the kit. The email body referenced a CPL_Agreement_ #, the kind of Mustache or Jinja2 syntax a templating engine is supposed to fill in before send. The single embedded link in the message pointed to hxxp://vm/, a phishing kit’s local development placeholder, exposed to the inbox because someone hit deploy without a final QA pass. The compromised sending account’s authentication carried it in. The subject line read “[Action required] Your_Mail_Box_Is_Full,” underscores and all. Microsoft delivered it.
In One Missing Letter, One Stolen Payment: A Reply-To Typosquat That Beat the Spam Score, the attacker registered leadsavingsofmissuori.com as a typosquat of the real vendor domain. The “o” and “u” inside Missouri are transposed (Missuori instead of Missouri). One character pair, swapped, the entire technical investment required to intercept a payment conversation. Microsoft’s Spam Confidence Level rated the message SCL=8 (high spam confidence), and one of the embedded links was internally flagged as malicious. The message landed in the inbox anyway because the recipient’s organization had a transport rule whitelisting payment-related senders. The whitelist override beat the explicit malicious-URL signal coming from the same Microsoft stack that was scoring it.
In The URL That Put adobe.com in the Wrong Place, the attacker pasted adobe.com into the directory path of a fishy domain (reviewdocpdfreader[.]com/docprivatepremiumfile/allfile/adobe.com/). It is the URL-deception equivalent of putting a “Police” sticker on the side of a non-police vehicle. This is not a new trick. It still got past the perimeter, because the URL parser saw a legitimate substring and apparently called it close enough.
In Sign Here, Get Phished: Inside an Adobe Sign Lure With a Multi-Hop Redirect to Credential Theft, the kit operators could not even keep the brand voice consistent inside their own email. The CTA buttons alternated between “Adobe” and “AdobeSign” depending on the paragraph. That is the visible seam from a template stitched together out of two earlier kits without anyone proofreading the result. Themis caught the redirect chain on first-time-sender behavioral signals. The point is that the kit was visibly cobbled, and three commercial gateways still cleared it.
What these four share is a lack of QA.
…and the kits were sloppy before they shipped.
…and the gateways shipped them forward anyway.
Featured Attack: The Hungarian Bank From Nepal
A K&H Bank phishing email arrived in inboxes from a Nepali domain. K&H Bank is real, headquartered in Budapest, the second-largest commercial bank in Hungary. The sending domain was rstonline[.]com[.]np. No relationship to Hungary, no relationship to banking, no credible resemblance to any K&H property.
Read the full incident breakdown here.
The kit hotlinked the real kh.hu favicon, which is the only thing in the message that actually looked Hungarian. The body text was supposed to be in Hungarian. It was not, exactly. The phrase “Fontos információ” (Hungarian for “important information”) rendered as “Fontos informaciA3” because the kit was authored on a system that handled the character encoding wrong, and the fix never happened. Any actual Hungarian speaker reading this email would notice immediately. Most non-Hungarian readers would also notice that the text looks wrong, because mojibake reads as garbage in any language.
The terminal link did not point to a K&H lookalike or to anything resembling a banking domain. It pointed to ecstechs[.]net, an unrelated business hosting domain. The chain inside the message did not even attempt to maintain the impersonation consistently from header to body to call-to-action.
I have to sit with this one for a minute. The kit author is in one country. The sending infrastructure is in a second country. The bank being impersonated is in a third country. The character-encoding library used to build the body is wrong for the target language. The CTA points to a domain that has no relationship to the brand being impersonated. Five separate quality failures, layered, in a single message. And it cleared authentication well enough to land in inboxes. The attacker did not need to do better, because the gateway was not asking for better.
DKIM was valid against the attacker’s own configured selector. SPF returned no policy at all. Microsoft’s compauth scoring still let the message through, because compauth weighting in Exchange Online treats “no SPF policy published” as inconclusive rather than failed. Our Adaptive AI flagged the message on cross-language anomalies and a sender domain history that had nothing in common with the impersonated brand. Three commercial gateways did not.
If the attacker had spent another twenty minutes proofreading their own kit, they could have shipped a much more convincing attack. They did not need to. The bar to clear was a triple-acronym authentication check that was already half-passing on the strength of a DKIM signature the attacker generated themselves.
See Your Risk: Find out how many threats like this your current security stack is missing
What Defenders Should Take From This Week
A few concrete takeaways:
Audit your transport rules. The Missouri typosquat case landed because an organization-level allow-rule overrode a high-spam-confidence verdict that the platform itself had flagged. If you have payment-related allow-rules in Exchange or Google Workspace, those rules are an attack surface. Document them, audit them quarterly, and pair them with secondary detection (behavioral or deep-content) instead of treating “allow” as terminal.
Look for kit tells in the body. Unresolved template variables (, ${…}, <%…%>), placeholder URLs (hxxp://, localhost, 127.0.0.1, vm/), brand inconsistencies inside a single message, and character-encoding errors are all visible to a content scanner that bothers to look. They are also visible to a trained user.
Stop trusting URL substrings. A URL with adobe.com in the path is not an Adobe URL. Any URL parser that grants reputation based on substring presence rather than registered hostname is broken. Verify the eTLD+1.
DKIM-pass is not endorsement. The K&H Bank case had a valid DKIM signature against a selector the attacker configured. DKIM verifies that the signing key controls the message. It does not verify that the signing key belongs to the impersonated brand. Pair DKIM checks with brand-impersonation detection.
Budget your assumption of attacker effort. A meaningful share of inbox-resident phishing this month did not require sophistication, recon, or operator skill. The market floor for “attack good enough to deliver” is low. Build detection assuming a sloppy adversary delivering volume, alongside the tooling you have for the surgical operator from last week’s roundup.
See You Next Friday
Attack of the Day publishes daily in the Threat Intelligence section. Next week: probably another roundup, on time this time, with whatever pattern emerges from the next seven posts. If the pattern is “the floor went lower again,” I will say so.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Audian Paxson. Read the original post at: https://ironscales.com/blog/best-of-the-worst-april-25-2026
About Author
