Could Your Organization Be Next? What the FBI’s Flax Typhoon Domain Seizures Reveal About Your Critical Infrastructure Security

Seven domains. Two tools. One message: attackers don’t need a “big” opening—just one forgotten service, one reused password, one unpatched box. The DOJ/FBI seizures tied to China-linked Flax Typhoon show a clean assembly line: scan at scale, pick the soft targets, then phish and persist until someone notices. If you run anything that keeps the lights on, planes moving, or students learning, this hits close to home. Here’s what MicroScan and FishHub did, what the joint advisory is really warning about, and the practical moves that lower your odds of being next.

What the FBI actually disrupted (and why it matters to defenders)

The FBI didn’t “take down Flax Typhoon.” What it disrupted was the kind of stable, repeatable infrastructure attackers need to run an assembly line: scan, pick targets, phish, get access, keep access.

In this case, law enforcement seized seven domains tied to China-linked activity tracked as Flax Typhoon, and connected them to two platforms allegedly operated by Integrity Technology Group (Integrity Tech): MicroScan (vulnerability scanning) and FishHub (spear-phishing + post-compromise tooling).

The “two-tool” model: one finds doors, the other walks through them

Think of it like this:

• MicroScan = “Where are the unlocked doors?”

A scanning platform used to hunt exposed services and known weaknesses at scale, including across critical infrastructure targets.

• FishHub = “Now that we’re in, how do we stay and pull data?”

Used for spear-phishing, malware delivery, unauthorized remote access, and search + exfiltration of files.

That split matters to defenders because it mirrors how modern intrusions actually happen. The breach rarely starts with some movie-style “zero-day.” It usually starts with exposure (an internet-facing box, an old VPN endpoint, a stale admin panel) and ends with persistence + data access.

The seven seized domains (and what each role tells you)

The domains weren’t random. They map to functions in the kill chain:

• MicroScan access domain: c0cc.cc (used to access the MicroScan platform)
• FishHub / malware delivery domains: 98aicai.com, 98aicode.com, outlook3650.com, youtubecard.com, linkedinns.net
• Note the lookalike branding (Outlook/LinkedIn). That’s not subtle—it's phishing-friendly infrastructure.
• Persistence domain tied to VPN tooling: 98aiblog.com, linked to SoftEther VPN installed on compromised systems to maintain remote access

Also worth calling out: the seized domains were redirected to FBI seizure notices naming Flax Typhoon and Integrity Technology Group. That’s a signal the FBI wanted defenders to notice the infrastructure patterns, not just the headline.

Why domain seizures should change how you defend

Domains are a forcing function for attackers. They need them for:

1. Reliability (payload hosting that stays up)
2. Repeatability (same tooling reused across victims)
3. Operational control (central access points for platforms like MicroScan and FishHub)

When those domains get burned, operators can pivot. But the tradecraft doesn’t change: scanning doesn’t stop, phishing doesn’t stop, and persistence doesn’t stop. What changes is your opportunity to learn from the exposed plumbing.

If you’re defending critical infrastructure networks, treat this like a blueprint. MicroScan shows what gets you “pre-selected.” FishHub shows what happens after a single person—or single server—blinks.

MicroScan: Mirai-backed scanning at scale (how critical infra gets “pre-selected”)

If FishHub is the “hands-on-keyboard” phase, MicroScan is the sorting hat. It’s how an operator quickly decides which organizations are worth the next step.

Per the FBI seizure affidavit, MicroScan was used alongside a botnet of internet-connected devices infected with Mirai malware to scan for vulnerabilities.  That pairing is the part defenders should sit with, because it changes the shape of the noise you see.

Why Mirai makes scanning harder to pin down

A Mirai-infected IoT botnet (think cheap routers, IP cameras, and other always-on devices) gives attackers a few advantages:

• Distributed scanning at high volume: requests come from a wide spread of IPs, not one obvious scanner.
• Speed: botnets can sweep huge address ranges fast, which shortens the window between “new exposure” and “someone is already probing it.”
• Blending into background internet noise: a lot of IoT traffic is messy by nature, and that mess can hide malicious scanning in plain sight.

The result is a constant pressure test on your perimeter: if you’ve got an exposed service, MicroScan-style operations are built to find it.

MicroScan wasn’t scanning “randomly.” It was scanning where it hurts.

The affidavit calls out target types that most security teams would categorize as critical infrastructure or close to it:

• a South Carolina power company
• airports in Japan and Poland
• Taiwanese natural gas and electricity companies
• universities

Even more uncomfortable: investigators state that scanning activity led to successful breaches, including two Taiwanese universities that were scanned (August 2022 and March 2023) and later compromised.

What “pre-selected” really means for your org

You don’t need to be famous to land in a pipeline like this. You just need to be:

1. Internet-reachable (intentionally or by accident)
2. Running something common that scanners know how to fingerprint
3. Behind on patching or hardening long enough for automated probing to connect the dots

MicroScan is also described as a Python-based vulnerability scanner with 1,300+ penetration-testing scripts, aimed at widely used technologies like Oracle WebLogic, Apache Struts, WordPress, and Jenkins.

That’s the key takeaway: the tooling isn’t exotic. It’s systematic. If you run common software, on an exposed surface, you’re already in the lottery.

FishHub: spear-phishing, payload delivery, remote access, and data theft (the second punch)

MicroScan is how you get on the list. FishHub is how the intrusion becomes real.

According to the FBI’s description, FishHub was used to run spear-phishing campaigns and deliver additional malware, giving attackers unauthorized remote access so they could hunt for specific files and exfiltrate data to servers under Integrity Tech’s control.

That’s the “second punch”: once a foothold exists, FishHub helps convert it into repeatable outcomes—access, discovery, theft.

The FishHub workflow (what it looks like in a real environment)

At a high level, the playbook is straightforward:

1. Spear-phishing targets the right people

• Messages are shaped to get one click, one macro enable, one credential entry.

2. Domain-hosted payload delivery

• Law enforcement tied malware delivery to domains like outlook3650.com and linkedinns.net (plus 98aicai.com, 98aicode.com, youtubecard.com).
• Those names aren’t clever. They’re meant to pass a quick glance from a busy user.

3. Remote access for hands-on-keyboard activity

• The goal isn’t just execution. It’s interactive control so operators can move, test, and adapt.

4. File search + exfiltration

• The FBI notes the malware enabled searching for specific files and exfiltrating them.

One detail that should make defenders uneasy: investigators found data and files from more than 20 organizations on a server linked to FishHub, including six universities in Taiwan.

That’s what “quietly persistent” looks like when nobody catches it early.

Persistence: why “new VPN software” should set off alarms

FishHub’s story also includes a blunt persistence lesson. A seized domain, 98aiblog.com, was tied to SoftEther VPN that was installed on compromised systems to maintain remote access.

Treat that pattern as a fire alarm:

• A new VPN tool showing up on a server that didn’t need one
• Unexpected VPN services installed outside change control
• “Temporary remote access” that never gets removed

That’s not a routine IT ticket. That’s an incident until proven otherwise.

When defenders focus only on blocking the phish, they miss the bigger risk: once an operator has remote access and time, they can keep adjusting until they get what they came for.

What the joint FBI/CISA/NSA advisory says attackers keep exploiting (and what to do this week)

Once FishHub is in the picture, you’re past “generic phishing risk.” You’re dealing with a playbook that mixes known-vulnerable internet-facing apps, password spraying, and data theft, then stays put long enough to monetize access.

The joint advisory (issued with FBI/CISA/NSA and partners) lays out a pattern defenders have seen for years, but with uncomfortable clarity: attackers aren’t betting on magic. They’re betting you have one neglected system.

What attackers keep going after (because it keeps working)

1. Exposed, common enterprise apps

MicroScan scripts targeted widely used software including:

• Oracle WebLogic
• Apache Struts
• WordPress
• Jenkins

These aren’t niche technologies. They’re everywhere. That’s why they’re targeted.

2. Known CVEs that show “patch-lag” reality

Investigators listed vulnerabilities that were commonly targeted, including:

• CVE-2019-11510 (Pulse Secure VPN arbitrary file read)
• CVE-2021-22205 (GitLab RCE)
• CVE-2014-6278 (Shellshock RCE)
• CVE-2016-3081 (Apache Struts RCE)
• plus others across FTP, DNS, ONLYOFFICE, and Strapi

Even if you don’t run these exact products, the lesson holds: attackers love “old but gold” issues because defenders often leave legacy services exposed.

3. Password spraying against Microsoft Exchange

The advisory also describes use of the open-source EBurst tool to conduct password-spraying attacks against Microsoft Exchange servers.

Translation: if you still have internet-facing auth endpoints and weak credential hygiene, someone will try the classics.

What your logs will show when this is happening

Don’t wait for an EDR alert that says “lateral movement.” By then, you’re late. Look for early signals that match this tradecraft:

• Scanning patterns against public apps: repeated requests across endpoints, odd URIs, or bursts of 404/403/500s against admin paths and known exploit routes (SOC should baseline this).
• Password spraying behavior: many failed logins across many accounts, often from rotating IPs, focused on externally reachable Exchange/auth services (Identity/IAM + SOC).
• Signs of data theft enablement: abnormal mailbox access patterns, unusual mail export behaviors, or web access patterns consistent with email harvesting (SOC + Messaging owners). The advisory notes a custom web app that allowed browsing stolen emails without direct access to accounts, which is a reminder to treat “email access at scale” as a top-tier incident.

A tactical “do this week” action plan (with clear owners)

You don’t need a six-month program to reduce risk fast. You need tight execution and accountability.

1. Pull the advisory IOCs and hunt them (SOC)

• Review indicators of compromise like IPs/domains/hashes and tool details included in the advisory.
• Run them across SIEM, DNS logs, proxy logs, EDR, and email security telemetry.
• Confirm you can answer: Did any endpoint resolve or connect to known domains? Did any host beacon out?

2. Patch what’s internet-facing, not what’s loudest (IT + App owners)

Authorities explicitly urge orgs to patch vulnerable systems.

Practical order of operations:

• Inventory publicly exposed assets (apps, VPNs, admin panels).
• Patch or mitigate based on exploitability and exposure, not internal politics.

3. Disable exposed services you don’t need (IT + Network)

The guidance also calls out disabling unnecessary exposed services.

If a service can’t be retired, put it behind:

• VPN with strong auth
• allowlists where feasible
• reverse proxy / WAF controls with logging

4. Enforce MFA where it matters most (IAM + IT)

The advisory urges multifactor authentication.

Make it real:

• MFA on email, VPN, admin portals, remote management, SSO.
• Block legacy/basic auth where possible.

5. Validate your logging is actually usable (SOC + Platform owners)

A lot of orgs “have logs.” Fewer can investigate with them.

• Confirm retention is long enough to catch slow intrusions.
• Confirm logs are centralized and searchable.
• Confirm time sync (NTP) is solid across perimeter, identity, and endpoints.

This is the boring work that stops the exciting breach.

Reducing your phishing blast radius (a simple control most orgs underuse)

After you patch and lock down exposed services, there’s still an uncomfortable truth: spear-phishing is easier when attackers can map your people.

Look at the infrastructure tied to this case. Domains like outlook3650.com and linkedinns.net weren’t built for scanning. They were built to look familiar enough to slip past a quick glance in a busy inbox.  That’s what makes phishing so efficient: it scales when your org’s contact surface is wide open.

The problem most teams ignore: “contact sprawl”

Your real exposure isn’t just mail filtering. It’s how many places your employees’ real emails and phone numbers end up:

• conference registrations
• vendor demos and free trials
• procurement intake forms
• public “contact us” pages
• job postings and department pages
• third-party ticketing portals

Once those addresses are out there, they get reused in targeting. Attackers don’t need deep recon when your org did the indexing for them.

A simple control: separate high-risk sign-ups from real identities

This isn’t about hiding. It’s about containment.

Goal: if a vendor database leaks or a form gets scraped, the attacker walks away with addresses that don’t go straight to a named employee’s primary inbox.

Practical moves (that don’t require a new program)

1. Use role-based inboxes for public contact

• security@, it-help@, procurement@, vendors@
• Route to a triaged workflow, not one person’s mailbox.

2. Stop publishing direct staff emails by default

• If someone must be reachable, publish a role address and forward internally.
• Keep named inboxes for internal comms and trusted partners.

3. Use alias emails for vendor sign-ups and public forms

• Create an alias per vendor or per form source.
• If that alias starts getting phished, you can quarantine or kill it without disrupting the employee’s real address.

4. Use alias phone numbers where forms require SMS

• Many “support” and “verification” flows can be abused later for social engineering.
• Treat phone numbers like credentials: minimize exposure.

Where Cloaked fits (without changing how your teams work)

For high-risk external sign-ups (vendor demos, webinars, SaaS trials), tools like Cloaked can help by issuing disposable/alias emails and phone numbers. If one alias gets targeted, you can shut it off and move on, instead of forcing an employee to live with a permanently burned inbox or number.

This won’t replace MFA, patching, or IOC hunting. It just shrinks the target list. When a campaign relies on believable lookalike domains and inbox volume, having fewer “real” addresses floating around is a quiet win.

‍