Last week a personal connection reached out about a big wave of scammy invoice emails to their organization, so I thought I would do a quick 101 on what these typically are, how they occur, and what you can do about them. It was actually a good reminder. I think sometimes this sort of thing will not get much deep-dive attention because it’s not considered very sophisticated or “cool” for a certain pedigree of cyber. We don’t really consider that it’s underserved, understaffed and underfunded organizations that tend to see this sort of thing the most - which is why they get hit with ransomware (which is where these usually lead to).
I hope this also serves as a quick how-to on how these work. Frankly, to me this sort of technique feels like some unnecessary extra hoops just to convince someone a fake login page is legit, but - if it works, it works. One extra detail that was mildly interesting to me was the fact that all recipients within the organization received this phishing email from “themselves”, as in the “To:” and “From” fields were the same address, so I’ll outline a few ways in which that is possible and what we can do about that.
So here’s the TL;DR: Tycoon is a phishing-as-a-service (PhaaS) kit that performs adversary-in-the-middle (AiTM) attacks to intercept credentials and MFA codes and proxy sessions. The kit is widely used in large-scale credential theft campaigns and is often a tool of choice for initial access brokers who then resell access to ransomware groups. The delivery method I cover here hides obfuscated JavaScript inside SVG assets; the SVG decodes and executes a payload that redirects victims to an attacker-controlled page while embedding a base64 token tied to the target, which serves as a way to preload the target’s address into the login screen to lend legitimacy to the page. This can be stopped in O365 environments by disabling Direct Send and enforcing SPF/DKIM/DMARC.
To Start: What is Tycoon and what is it used for?
Tycoon 2FA is a commercial phishing kit that implements adversary-in-the-middle tactics to capture credentials and MFA tokens in real time. It is sold or distributed through PhaaS channels and has been observed targeting major providers such as Microsoft 365 and Gmail with highly convincing login pages, CAPTCHA gating and other stealth features. The kit’s purpose is to harvest valid credentials and session tokens and to enable attackers - whether the kit operator or their customers - to take over accounts, access email, and pivot into environments. Recent vendor reports and telemetry show Tycoon actively evolving with new templates and delivery techniques.
Tycoon is a full PhaaS ecosystem: operators sell subscriptions and templates (often via Telegram), provide a user-friendly control panel and relay/proxy infrastructure that performs real-time session interception, and bake in anti-analysis features such as CAPTCHA gating, link obfuscation and dynamic templates to evade automated scraping and blocking. Researchers consistently observe Tycoon collecting credentials, but also session cookies, browser fingerprints, IP/geolocation and other metadata so operators can validate access and prioritize high-value accounts; that data profile is what makes the crop attractive to initial-access brokers who verify, enrich, and then resell access to ransomware affiliates. Vendor telemetry also shows the kit evolving rapidly, like new obfuscation tricks, hosting/playbook changes, and delivery techniques.
General Threat intelligence: Tycoon, Initial Access Brokers, and ransomware resale
Tycoon and similar AiTM phishing kits are popular with both hands-on operators and initial access brokers (IABs). IABs monetize access by harvesting credentials, validating access, and then selling verified or privileged access to other criminals, frequently ransomware affiliates or Ransomware-as-a-Service operators. The economics are pretty straightforward: a PhaaS kit such as Tycoon lowers the cost and barrier to entry for credential theft, generating large credential pools that can be verified and resold. Recent telemetry shows Tycoon campaigns capturing hundreds of thousands of credentials in short time windows and a steady pipeline from phishing harvest to resale and eventual ransomware and extortion operations.
A deep dive: what did I actually look at (deobfuscated, defanged)
I was given a pretty basic and low-effort “Payment Receipt for [Organization]” email lure that included an .SVG attachment. The Recipient and Sender address were identical, as if the recipient sent themselves the message. There was no email text body, just the attachment.
One earlier indicator of Tycoon usage is that the OrgName matches the organization’s O365 subdomain name, which isn’t a perfect human-friendly representation for a lure (think “Payment Receipt for redcross” rather than Pay Receipt for the Red Cross”). So - first things first, I start taking apart the SVG attachment.
Editorial Note: I manually edited one Base64 encoded value in this example to redact the email address of the person that shared this with me. This will make sense in a moment.
The file contains an inline <script> that hides a small, concise runtime loader. The loader’s goal is simple and malicious: produce a redirect to an attacker-controlled URL while tagging the redirect with a base64 token that identifies the victim or campaign, and in this case prefills the login portal. The core steps are:
- The script stores a base64-like token (prefixed with $) that decodes to an email address. In this sample the token decodes to the targeted user’s email address.
- A long hex string is XOR-decoded with a short ASCII key into a JavaScript snippet that’s assembled at runtime.
- The snippet builds the string “eval” dynamically (using that tiny little lookup table up there) and then calls the decoded code via an indirect global eval trick, which runs the redirect payload.
- The redirect payload base64-decodes a URL and appends the token, causing the victim’s browser to navigate to an attacker domain with the victim identifier attached.
- End-state is a fake O365 login portal to steal credentials, with the targeted user’s email address pre-loaded.
Defanged artifacts from the sample
- Defanged destination: hxxps[:]//fable-5ttuenigma[.]qgwum[.]ru/kYWR!C5W/
- Defanged appended token (base64 - this is made up by me): $Ym9iam9obnNvbkBiaWdjb21wYW55Lm9yZw== → decoded: bobjohnson@bigcompany[.]org
Why the Obfuscation?
Building ‘eval’ indirectly (e.g., n(‘e’)+n(‘v’)+n(‘a’)+n(‘l’)) and XORing a hex blob at runtime are cheap but effective evasion techniques. They hide both suspicious keywords and the payload from naive static scanners and slow manual analysis. Because the payload is embedded in an SVG, it can be hosted as a seemingly benign static asset on compromised sites or within theme/templates and delivered to many targets. This means it can be moved around without anything picking up that it is malicious, which also means you can send it in an email without many things picking up that it is malicious.
Plus, you can swap out little bits and bobs in the script to change the file hash. I would imagine this has less than 24 hours before it’s in VirusTotal or various other solutions so the idea is you just send a blast and then swap out a value in the lookup table or something to change the file’s signature.
Why the email sometimes shows the same address in TO and FROM (Direct Send / spoofing)
A common triage question is: how can a phishing email appear to come from the same address that received it? Two mechanisms often explain this:
- Header spoofing combined with lax acceptance rules. An attacker can craft an SMTP message where the From: header matches the To: header. If the recipient MX accepts that message and the tenant does not enforce strict inbound authentication checks, the message may look “internal.”
- Abuse of Direct Send (Microsoft 365 example and more likely here). Direct Send allows devices and services to deliver mail directly to Microsoft 365 mailboxes using the tenant MX without authenticating, under certain configurations. Attackers abuse or mimic these delivery paths so that downstream checks treat the message as having traversed trusted infrastructure, reducing some anti-spoof signals. That’s why disabling or tightening Direct Send and enforcing authenticated submission are important mitigations. Microsoft and vendors have published guidance and tenant controls that reduce this abuse.
Practical detection, mitigation and an IR playbook
Immediate mitigation:
- Defang & block the domain(s) observed in the artifact (e.g., add to DNS/proxy blocklist). Use defanged IOCs in comms: hxxps[:]//fable-5ttuenigma[.]qgwum[.]ru. We always say this but honestly the URL is probably dead within the next week or so.
- Disable or restrict Direct Send and require authenticated SMTP submission for devices and apps; where Direct Send is necessary, inventory and restrict its use. For Exchange Online/Exchange Admins, review tenant settings and connectors and consider rejecting unauthenticated Direct Send.
- Enforce SPF/DKIM/DMARC and move DMARC to p=quarantine/p=reject after monitoring. This reduces success of external spoofing.
Conclusion
This sort of thing I generally wouldn’t come across but was a handy exercise that hopefully helps someone receiving these that otherwise wouldn’t have the resources to address it. You can largely prevent delivery of these by disabling Direct Send and enforcing SPF/DKIM/DMARC, which is a pretty low-impact way of just forgetting these ever existed. Hope it helps!