How to Spot a Fake-Invoice Phishing Email (And How I Traced One Safely)

A German Mahnung landed in our inbox last week. "Rechnung RE583492 from 18.07.2026 is overdue, open the Mahnschreiben in the attachment." Polite, official-looking, a little threatening in that very German administrative way. It was phishing. Here's exactly what it was, what would have happened if someone clicked, how you can spot one yourself in ten seconds, and how I traced the whole thing down to the payload without ever letting it run in a browser.

Grab the free checklists first, no email or signup required. A one-page, plain-language version you can print and hand to any less-technical friend or relative. Download the English PDF or the German PDF.

Before anything else: every URL in this post is defanged (hxxps://, [.]) so nothing here is clickable. Never paste a live phishing link into your own browser. That's the whole lesson, really, and we'll get to why.

What a Fake Invoice Phishing Email Actually Looks Like

Here's the anatomy of the one we got:

• Subject: Fwd: Mahnung-Nr. 68285 RE_54-1895_DE
• From: Buchhaltung <buchhaltung@moolaah[.]com>
• Body: a short German note claiming an invoice from "BenBlue GmbH" was overdue, with a green Öffnen button to "view your invoice and download the reminder."

That's the entire play. Money you supposedly owe, a document you have to retrieve, one button. It even faked a forwarded internal accounting message, headers and all, so it looked like it had already been passed around inside a company before reaching you. The "Bitte bezahlen......." at the top is almost lazy, and that laziness is the tell once you know what you're looking at.

This is the most common phishing email shape hitting German inboxes right now, because it works. A dunning notice triggers a small panic, and panic is the enemy of checking. Nobody wants a debt collector. So the finger moves to the button before the brain catches up.

How to Spot a Phishing Email: 5 Tells That Don't Need Any Tools

You don't need to be technical for the first pass. Five things, roughly in order of how reliable they are.

1. The link doesn't go where the text says. The button read "Öffnen" but pointed at hxxps://mtd.raajrani[.]net/home/pages/hr/phpexcel/vendor/ezyang/htmlpurifier/..., a random unrelated domain with a deeply nested path. A real invoice from BenBlue would live on a BenBlue domain. Hover over any link before you click and read the actual destination. On a phone, press and hold to preview it.

2. The sender doesn't match the company. The mail claims to be BenBlue GmbH but was sent from moolaah[.]com, a domain with no relationship to the company named in the text. When the "who" and the "from" disagree, stop.

3. Broken details under the surface. The reply address in the fake forwarded header was mangled nonsense: eescuol@ee-en.chbuchhaltung@moolaah[.]com. Two addresses smashed together. Real mail systems don't produce that.

4. Urgency plus a document you must fetch. "Overdue." "Reminder attached." "Open now." Manufactured pressure is the entire point. It exists to stop you from doing exactly what I'm telling you to do here.

5. You don't actually recognise the invoice. You never ordered from them. There's no matching invoice number in your records. The amount and the company are unfamiliar. Trust that. Your own paperwork is the source of truth, not the email.

Print those five out and stick them on the fridge. Genuinely. The people who fall for this are rarely careless, they're just busy or trusting, and a checklist next to the computer beats a lecture every time.

"But It Passed SPF, DKIM, and DMARC" Is Not a Green Light

This is the trap that catches even technical people, so pay attention here.

That phishing email passed all three email authentication checks. SPF, DKIM, DMARC, all green. And it means almost nothing for your safety.

Those checks only prove the message really came from moolaah[.]com and wasn't tampered with in transit. They say nothing about whether moolaah[.]com is trustworthy. An attacker who registers their own throwaway domain, or sends through a legitimate provider like Amazon SES (which this one did), gets passing authentication for free. It's their domain. Of course they can authenticate mail from it.

So "authenticated" is not "safe." It never was. All a green DMARC tells you is that the liar is who they say they are. If your own domain doesn't have these records set up correctly, that's a separate and real problem worth fixing, and it's on my website security hardening checklist for a reason. But receiving a message that passed them is not a reason to trust it.

What Actually Happens If You Click (The Two-Stage Cloaking Trap)

Here's where it gets clever, and honestly a little unsettling. The link does not drop you straight onto a fake login page. It runs a two-stage trap built to hide from security researchers and automated scanners.

Stage one is the cloaking gate. The landing page looks empty. Behind the scenes, obfuscated JavaScript quietly fingerprints your browser: your timezone and its name, your operating system and browser, and critically, whether you're an automated or headless browser (the navigator.webdriver flag that security tools trip). It packs all of that into a hidden form and silently sends it back to the server. The page was also padded with a wall of invisible, tiny, random words, an old trick to confuse spam filters.

Stage two is the decision. The server reads your fingerprint and decides who you are. Look like a real, targeted victim, a genuine Windows browser in the right country, not a bot? You get served the real payload: a credential-harvesting page dressed as a Microsoft or bank or invoice-portal login, or a malware download disguised as the Mahnung. Look like a researcher, a scanner, or a bot? You get quietly redirected to a harmless real website. In our case, adobe[.]com.

That redirect to a legitimate site is the kit protecting itself. It's the exact reason a casual "let me just click and see what it is" is dangerous. A real victim's browser sees a completely different page than an analyst's does. You could click, get bounced to Adobe, decide it was a dud, and never realize your grandmother on the same email a day later got the real thing.

The net effect for a victim: they type real credentials into a convincing fake, or download and run malware, believing the entire time they're just opening an overdue invoice.

Who Actually Owns a Phishing Attack (And Why the Host Is Often a Victim Too)

There are two separate pieces of infrastructure here, and they matter because they get reported to different people.

The sending identity was moolaah[.]com delivered through Amazon SES. That's who to report to AWS abuse so they suspend it. The hosting, where the phishing kit actually runs, was raajrani[.]net at 103.174.152.60, sitting in a datacenter in Bangladesh. That's a different abuse team, and taking down the page is their job.

Here's the part people miss: raajrani[.]net is almost certainly a compromised legitimate website, not the attacker's own server. The kit was buried inside a real PHP library's directory, vendor/ezyang/htmlpurifier/…, which is a classic place to stash malicious code after breaking into a site so the actual owner never notices. Some small business somewhere has a phishing kit running on their server right now and has no idea. They're a victim too. This is the same category of problem as a compromised npm package quietly poisoning your site, just from the hosting side instead of the dependency side. If you run a website, "am I accidentally hosting someone's attack" is a real question, not a paranoid one.

How to Investigate a Suspicious Link Without Getting Burned

I wanted to understand exactly how deep this trap went. But I was not about to open it in a real browser, because that would execute the JavaScript, leak my home IP, and confirm my address to the attacker. So every step ran from a server over SSH, command-line tools only.

Read the raw source, not the pretty version. I never opened the email in a normal client. I pulled the raw message source, headers plus the plain HTML. That's just text. Nothing renders, nothing runs. The headers gave up the true sender (moolaah[.]com via Amazon SES) and the HTML gave up the real button target.

Follow the link with curl, not a browser. curl fetches a page but does not execute JavaScript, so browser-based exploits are inert. Run it from a server so the attacker sees the server's IP, never your personal one:

curl -sSL -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" \
  --max-redirs 15 -D - -o body.html \
  "hxxps://mtd.raajrani[.]net/.../stereotape"

The -D - prints every response header so you see each redirect hop, -o body.html saves the page for offline reading instead of rendering it, and --max-redirs caps the redirects so you can't be looped forever. This landed on a page running an ancient PHP 7.3.33, consistent with a compromised host nobody's updated.

Read the code by hand. I grepped the saved HTML for the usual redirect and form tricks. No visible content, just that wall of invisible random words and one block of obfuscated JavaScript. Reading through the obfuscation showed exactly what it collected and that it POSTed the fingerprint back to the same URL. That's when it was obviously a cloaking gate, not the final page.

Replay the fingerprint POST to reveal stage two. To see what the server does after the check, I replayed the POST with a plausible "real German Windows browser" fingerprint:

curl -sS --data-urlencode 'd={"n":"Europe/Berlin","sp":"Win32","wd":false,...}' \
  -D - -o stage2.html "hxxps://mtd.raajrani[.]net/.../stereotape/"

The server replied 302 → hxxps://www.adobe[.]com/. It judged us not a real victim and bounced us to a harmless site, confirming the cloaking without ever triggering the real payload.

Know where to stop. I could not see the final credential or malware page, because it's served only to a browser that fully passes the gate. Forcing it would mean driving a fully instrumented headless browser spoofing every signal: more effort, more risk, almost no extra value. I knew what it was and that it actively hides from analysis. That's enough to report it and warn people. Knowing when to stop is part of doing this safely.

Attackers are automating all of this now, by the way, which is the uncomfortable backdrop to AI making it faster to find and exploit weaknesses than to patch them. The kit that fingerprinted my browser and sorted me in milliseconds isn't run by a genius. It's a product someone rented.

What to Do When a Phishing Email Lands in Your Inbox

Short version, and this is the part to forward to family:

1. Don't click. If you're curious, that curiosity is precisely what the trap is built to exploit.
2. Verify out of band. If there's any real chance the invoice is genuine, contact the company through a phone number or address you already have, never the one in the email.
3. Report it. Send the raw headers, not a screenshot, to the sending provider's abuse team and the host's abuse team. Raw headers are the evidence they can actually act on.
4. Mark as spam and delete. That trains your provider's filter to catch the next one.
5. If someone already clicked and typed something in: change that password immediately, and anywhere it was reused, turn on two-factor authentication, and run a malware scan if a file was downloaded.

The One Thing to Remember About Phishing Emails

A passing SPF/DKIM/DMARC check, a company name you half recognize, and an urgent overdue invoice are not evidence that a message is safe. They're the exact ingredients a good phishing lure is built from. What matters is where the link actually goes, verified through a channel you already trust.

You can go remarkably deep on a suspicious link with nothing more than the raw email source, curl, and the discipline to never let it run in a real browser. But most people shouldn't have to. Most people just need the five tells and the habit of pausing before the button.

If your business handles this stuff for a team, or you've got older family members who keep getting these and you want something you can actually hand them, that's exactly why I built the printable checklist below. Stick it next to the computer. And if you'd rather have someone lock down your own site so it never becomes the compromised host in a story like this one, that's a conversation I'm always happy to have.

The Free Printable Checklist

I turned the five tells into a one-page version in big, plain type, made to be printed and stuck next to the computer or handed to the family members who keep getting these. No jargon, nothing technical, just what to check before clicking. Both are completely free to download, no email required.

• Download the checklist (English, PDF)
• Checkliste auf Deutsch (PDF)