# A Seized Hacker Domain Is Not an Eviction Receipt

> Authorities disrupted two tools used in China-linked intrusions. Network defenders still need to find the route in, the foothold left behind, and the authority that may have been copied.

- **Author:** Kubilay Tunca
- **Published:** 2026-10-12
- **Category:** For Developers
- **Tags:** Incident Response, Network Security, Identity Security, Threat Hunting
- **Canonical URL:** https://cyber-security-in-plain-english.com/post/developers/news/domain-seizure-is-not-an-eviction-receipt

---

Seven domains stopped serving the people who had used them to scan networks, deliver malware, and search stolen email. That is good news. It is also a poor reason for any network defender to close an incident ticket.

On 8 October 2026, the US Department of Justice said courts had authorised the seizure of domains connected to two tools called MicroScan and FishHub. The department alleges that people working for the China-based Integrity Technology Group operated the tools, while a joint advisory from agencies in ten countries describes related activity across government, healthcare, manufacturing, education, religious organisations, and technology providers. The disruption removed infrastructure from the operators. It did not inspect your server, remove their access from your tenant, or tell you whether credentials had already been copied.

That distinction is the practical story. A takedown changes the attacker's infrastructure. Eviction changes the victim's environment. Teams that confuse the two can patch the public door while leaving a private entrance, a remote-access client, or a working cloud session behind.

The right response is calm and specific. Work out whether the activity touched you. Preserve enough evidence to understand the route. Remove every form of access that route created. Then prove the boundary is different from the one the attacker crossed.

## What the October operation actually changed

The public action targeted two parts of an operating system for intrusions, not one magic piece of malware. MicroScan helped find exposed systems and known weaknesses. FishHub helped run targeted email lures and deliver follow-on software after someone had already been reached. Together, they covered two familiar routes: find an open technical door, or persuade a person to open one.

The [Justice Department's 8 October announcement](https://www.justice.gov/opa/pr/justice-department-and-fbi-seize-vulnerability-scanning-and-spear-phishing-tools-operated) says authorities seized seven domains. One gave operators access to MicroScan. Five helped deliver malware connected to FishHub. The department says MicroScan targets included a South Carolina power company, airports in Japan and Poland, Taiwanese power and natural-gas companies, universities, and a multinational non-governmental organisation. It identifies about 20 Taiwanese universities as confirmed victims of FishHub activity.

Those statements matter, but their limits matter too. The court action denies access to named infrastructure. It does not mean every operator account, server, tool copy, or replacement domain disappeared. It does not mean every organisation scanned by MicroScan was compromised. Scanning is observation from outside. Compromise requires a successful route in.

The reverse limit is just as important. A domain seizure does not reach backwards into a system that was compromised last month. If an actor installed a second remote-access route, copied an administrator credential, created an application consent grant, or downloaded a mailbox, taking away one command server cannot unmake those effects.

The operation was also not the first disruption of this infrastructure. In September 2024, US authorities disrupted a Mirai-based botnet linked to Integrity Tech. The 2026 announcement calls this the second public technical disruption of the company's operations. [The Record's account of the new operation](https://therecord.media/flax-typhoon-china-tools-integrity-tech-international-takedown) notes that the earlier botnet contained more than 260,000 compromised consumer devices.

That history should shape the defender's expectation. Disruption creates friction, removes capacity, reveals methods, and buys time. It is valuable work. Yet a capable operation can acquire new servers and domains. Your durable gain comes from using the released evidence to find old access and close the class of route, rather than waiting for the next list of names.

## The route was ordinary before it became serious

The joint advisory is useful because it resists the temptation to make the campaign sound mysterious. The operators combined automated scanning, compromised devices, public tools, password guessing, targeted email, and manual work. None of those parts requires a cinematic explanation. The scale came from joining ordinary methods into a repeatable system.

The [joint advisory AA26-281A](https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-281a) says MicroScan contained more than 1,300 scripts for checking websites and services. It names OpenSSL, Oracle WebLogic, WordPress, Jenkins, Apache Struts, and Juniper ScreenOS among the targets. The advisory also lists common open-source scanners and says the operators tended to look for more vulnerable targets.

That last phrase deserves attention. Automated reconnaissance changes the economics of old exposure. A forgotten service no longer needs to be interesting enough for a person to investigate by hand. It only needs to answer on a port and match a check that can run thousands of times. An old administration page, a test host, or a remote-access service can sit unnoticed by its owner while remaining obvious to a machine.

The advisory lists eight vulnerabilities associated with observed activity. Their years run from 2014 to 2023. The campaign did not depend on one new flaw defeating every current defence. Much of it relied on old software and reachable services surviving long enough to be found at scale.

FishHub covered a different opening. According to the Justice Department, it supported targeted email attacks and then delivered additional software. That software could provide remote access or search for selected files and send them to operator-controlled servers. The technical advisory describes a web page altered to collect usernames and passwords, followed by a password-protected download that launched software assessed to target mailbox data.

The campaign also went directly after email accounts. The advisory describes password spraying against several Microsoft Exchange and Microsoft 365 interfaces. Password spraying tries a small set of likely passwords across many accounts rather than hammering one account with thousands of guesses. That can look quieter, avoid simple lockout rules, and succeed wherever an old password and an exposed login route meet.

After access, the operators did not need exotic persistence. Investigators observed SoftEther, legitimate virtual private network software, configured to reconnect when a system started. Installers were sometimes named `conhost.exe` or `dllhost.exe`, names that resemble ordinary Windows components. A legitimate remote-access program under a familiar-looking filename gives the attacker a durable route while making a quick software inventory less helpful.

The reported collection matched the routes. Investigators saw database downloads, manual extraction from email, scripts that accessed calendars and contacts through Exchange Web Services, and a command-line program that collected Microsoft 365 mailbox content. [The Hacker News summary of the operation](https://thehackernews.com/2026/10/fbi-seizes-7-domains-disrupts-flax.html) independently reports the same progression from scanning and targeted email into VPN persistence and mailbox theft.

The useful model is short:

`public exposure -> initial access -> durable route -> trusted identity -> data collection`

A defender who repairs only the first arrow has not addressed the rest. Once a trusted identity or persistent route exists, the attacker may no longer need the original flaw.

## Domain seizure and victim eviction solve different problems

Imagine that a thief uses a rented van to reach a warehouse, copies a key, and hides a second key nearby. Police later seize the van. The seizure makes the thief's next trip harder. It does not change either key.

Infrastructure disruption works on the operator's side of the connection. Authorities can seize a domain, redirect traffic, remove malware from devices under a court order, or deny access to a service. These actions can break command paths and reveal useful evidence. They can also warn victims who had no reason to recognise the traffic before.

Eviction works on the victim's side. It identifies every host and account the attacker touched, blocks current access, removes persistence, replaces exposed authority, and closes the initial route. It ends with evidence that the actor cannot return through the same path or a path created during the intrusion.

The difference explains why blocking the seven seized domains is necessary but incomplete. A block can stop a known connection and produce a useful alert if an infected host keeps trying. It cannot detect a VPN client pointed at an unlisted address. It cannot expire a stolen cloud session. It cannot restore a mailbox that was already downloaded. It cannot tell you whether the operator added another administrator.

The same problem appears when a vendor takes down a malicious package, a hosting company closes a phishing page, or a platform removes an attacker account. Availability changes upstream. Trust does not reset downstream. Any authority copied before the removal remains a separate problem.

Teams often miss this because the external event supplies a clean date. The press release arrived on 8 October. The affected environment may contain evidence from months or years before that date. The advisory says related access has been observed since at least January 2021, while MicroScan itself was used as early as 2017. A seven-day log search cannot answer a five-year question.

That does not mean every organisation needs to retain every packet forever. It means the look-back period should follow the evidence you possess, not the date the story reached your feed. Start with the longest useful records: identity sign-ins, cloud audit logs, VPN configuration history, endpoint software inventory, firewall changes, email access records, and backups of critical configuration. State where visibility ends. An honest gap is better than a fabricated clean bill of health.

This is the central position: treat a public takedown as an intelligence release, not as remote remediation for your network.

## Start with exposure, then test for effects

A useful first pass answers whether you offered the routes described in the advisory. Do not begin by dumping thousands of indicators into a dashboard and waiting for red dots. Begin with your own inventory.

List the internet-facing systems your organisation owned during the relevant period. Include systems that no longer exist, old addresses, disaster-recovery nodes, vendor-managed appliances, mail gateways, forgotten test hosts, and services exposed through cloud load balancers. Compare that history with the technologies and ports described in the advisory. Current inventory alone can erase the machine that matters most.

For each matching system, record the software release, the date it became reachable, the date it received the repair, and the logs available for the earlier window. “Patched” is one field in that record. It is not the conclusion. If a server was reachable and vulnerable for six weeks, the repaired version does not answer what happened during those six weeks.

The same process applies to email and identity. Identify which Exchange and Microsoft 365 interfaces were available, which accounts lacked multifactor authentication at the time, and where password-only access remained possible. Review connected applications, delegated permissions, unfamiliar inbox rules, forwarding, new authentication methods, and sign-ins from infrastructure that does not fit the account's normal use.

Indicators from the advisory can then sharpen the hunt. A known domain or address in DNS, proxy, endpoint, or firewall records is strong evidence worth investigating. An unfamiliar SoftEther installation, an unexpected auto-start entry, or a supposedly standard Windows filename outside its normal path can point to persistence. A high volume of small login failures across many users can fit password spraying better than the dramatic lockout on one account.

Absence of a named indicator proves less than many dashboards imply. Domains change. Addresses get reassigned. Legitimate tools can connect to new infrastructure. Some activity in the advisory relied on normal cloud and email interfaces, where the suspicious fact is the identity, volume, timing, or sequence rather than a known malicious hostname.

Sequence gives the evidence meaning. An old web server received unusual enumeration, then downloaded a remote-access installer, then began making regular outbound connections, while an administrator account accessed email from a new location. Each event alone may have an innocent explanation. Together, they describe a route.

A good hunt therefore writes a timeline rather than a pile of matches. Put the external scan, the application event, the process start, the new service, the identity use, and the outbound transfer in order. Mark what is observed, what is inferred, and what remains unknown. That timeline decides which systems to isolate and which credentials to replace.

## Preserve enough evidence before you pull the plug

Speed matters when an attacker may still have access. So does order. Removing the first visible artefact can destroy the evidence needed to find the second route.

The joint advisory's incident-response section gives a sensible sequence. Determine which hosts may be compromised and isolate them. Start threat hunting to understand the intrusion. Collect and review artefacts, logs, devices, accounts, and timing. Then choose countermeasures that remove the observed access. The advisory explicitly warns teams to collect enough hunting data to inform the eviction plan, while recognising that collection and containment may overlap.

That is not an instruction to leave a clearly active attacker alone while a committee meets. A host sending data out should be contained. A stolen account should not keep working merely to preserve a perfect experiment. The point is to avoid careless cleanup that turns one detected implant into ten unknowns.

Suppose an analyst finds SoftEther on a mail server and uninstalls it immediately. The obvious program disappears. The team may lose its configuration, connection history, installation time, destination, service name, and link to the account that placed it there. If the same account also added a cloud application or changed a firewall rule, that evidence may never be connected.

A better containment action blocks the host's unnecessary network paths, captures volatile facts where the team's process supports it, preserves the relevant files and configuration, and records exact times. The team can then remove the program with an understanding of what else must change. When preservation is outside local skill or authority, call the incident-response provider instead of improvising forensic commands on the only copy of the system.

Identity needs the same care. Resetting one password can alert an intruder while leaving a valid session, application token, recovery method, delegated permission, or second account alive. Record the account's recent sign-ins and changes, revoke active sessions, remove unapproved authentication methods and applications, and replace any linked service credential that the account could read.

Preserve reliable evidence that can answer four questions: how access began, what durable access was created, which authority became exposed, and what data or systems that authority could reach. A museum-quality image of every machine is unnecessary. If one answer remains unknown, keep it as an explicit incident risk rather than translating it into “no evidence” too early.

## Eviction must remove authority, not just software

Software is visible, so cleanup tends to focus there. Authority is more important. A copied secret can outlive the process that stole it, and an added permission can survive the removal of the tool that created it.

Begin with the identities used on affected systems. Human administrators, service accounts, deployment tokens, backup credentials, mail application secrets, and domain trust all belong in scope if the compromised host could access them. Replace credentials from a known-clean administrative path. A password changed on the same suspect machine can be captured again.

Next, revoke sessions and tokens. Modern cloud access often continues through a session after the password changes. Review registered devices, authentication methods, consent grants, service principals, API keys, and delegated mailbox access. Remove anything that lacks a documented owner and purpose. For high-value accounts, compare the current state with a trusted earlier baseline instead of relying on memory.

Then address network authority. Remove unauthorised VPN clients, tunnels, scheduled connections, proxy settings, firewall rules, and routes. Check both the affected host and the devices around it. A server can be rebuilt while an edge rule still forwards traffic to its replacement.

Active Directory and other central identity systems require a wider response when evidence points there. The advisory reports use of a technique that copies directory data through replication functions. If a compromised identity gained that level of authority, resetting one user does not repair the trust boundary. The incident needs specialist handling, a planned credential reset sequence, and validation across domain controllers, services, and dependent systems.

Data access affects the response too. If mailbox content was taken, the risk is not limited to the mailbox owner. Email contains password-reset messages, invoices, private conversations, customer records, legal material, and introductions that make later impersonation believable. Search for exposed secrets and high-risk information inside the affected account's reach. Rotate live secrets, notify the right owners, and treat the copied correspondence as context an attacker may use later.

Here the warehouse example becomes concrete. Removing the hidden key means replacing every credential the intruder could copy, ending every session they could keep, deleting every route they could install, and checking every room that key could open. Anything less is software cleanup with trust left behind.

## Build boundaries that make the next scan boring

The advisory's mitigation list is broad because the observed activity crossed several layers. No single product provides the durable answer. Small boundaries prevent a discovered service from becoming organisation-wide authority.

Start by reducing what answers from the internet. Disable unused services and ports. Remove old administration pages. Put remote management behind a controlled access path. Ask an external inventory service, a separate team, or a trusted scanning process to show what the public internet sees. The goal is not to hide a vulnerable service. The goal is to stop publishing services that do not need a public audience.

Patch the systems that remain reachable, including firmware and appliances. Keep a receipt that names the node, installed build, activation time, and exposure window. For a cluster, “the service is patched” is too vague. Each node and standby needs evidence, and a repaired build may require a restart before it is the running build.

Put multifactor authentication on webmail, VPN, and privileged services wherever the platform supports it. Prefer methods that bind approval to the real site, such as passkeys or security keys, for accounts with broad authority. Multifactor authentication does not repair an exploitable server, but it changes the password-spraying route described in the advisory.

Narrow what edge systems can reach after they are compromised. A public web server rarely needs unrestricted access to directory services, mail systems, backup control planes, and administrator workstations. Network segmentation turns one exposed host into one incident zone instead of a bridge. Egress rules matter as well. A server that never uploads large archives should not have an unexplained path to do so without an alert.

Make legitimate remote tools visible. Maintain an approved inventory for VPN clients, remote support agents, tunnels, and startup services. Alert when a new one appears, when an approved binary runs from an odd path, or when a service begins reconnecting to an unfamiliar destination. The advisory's SoftEther example shows why the rule must cover behaviour and placement, not merely whether a program has a valid signature.

Identity monitoring should look for changes in authority. A new administrator, authentication method, service principal, consent grant, mailbox rule, forwarding address, or device registration deserves a named owner. The best alert explains the change in plain language and links it to the person or deployment that authorised it.

Keep the evidence outside the blast radius. If a compromised server can alter its own only log, the attacker gets an eraser with the key. Send security events to a separate account or service with write-only ingestion where practical. Protect configuration history, identity logs, and recovery systems with stronger boundaries than the workloads they observe.

These controls are not a promise that scanning will stop. They make scanning less productive, initial access less likely, movement harder, and investigation faster. That is a better target than pretending a public service can become invisible.

## A practical response sequence for this advisory

A team handling the October release needs a sequence that fits into real operations. The following order keeps the work tied to evidence and avoids turning a news headline into a month-long panic exercise.

1. **Name an owner and preserve the advisory.** Assign one person to coordinate the check, save the advisory and indicator files with their publication date, and record the exact time the review began. The owner does not need to perform every task. They keep one timeline and stop findings from scattering across chat messages.

2. **Build the historical exposure list.** Gather current and retired internet-facing addresses, domains, mail routes, edge devices, web applications, and remote-access services. Include the systems that were removed or moved during the period for which logs still exist. Mark owners and logging coverage.

3. **Match the described routes.** Identify exposed technologies and releases connected to the listed vulnerabilities, public login interfaces that allowed password-only access, and systems where web input could reach vulnerable application code. Prioritise matches with valuable data or broad internal connectivity.

4. **Hunt for effects, not just names.** Search the released indicators, then widen the hunt to unexpected scanning, remote-access software, startup entries, outbound connections, mailbox access, forwarding rules, application consents, and high-volume uploads. Build a timeline for each serious lead.

5. **Contain confirmed or credible access.** Isolate affected hosts, block unnecessary routes, suspend or restrict involved accounts, and stop data movement. Preserve enough configuration and logs to find related access. Bring in an incident-response specialist when central identity, regulated data, or critical operations are involved.

6. **Evict every form of persistence and copied authority.** Remove unapproved software, services, accounts, sessions, keys, applications, routes, and rules. Rotate exposed secrets from known-clean systems. Rebuild hosts when their integrity cannot be established. Do not declare eviction from an uninstall receipt.

7. **Close the initial route and prove the new boundary.** Patch or remove the exposed service, activate the repaired build, require stronger authentication, narrow network paths, and verify from outside that the old route no longer answers. Test that a compromised edge node cannot reach sensitive systems it does not need.

8. **Record the limits of the conclusion.** State the time range searched, log sources checked, systems with missing history, indicators found, credentials replaced, and evidence supporting closure. “No matching activity in 90 days of available logs” is a defensible sentence. “We were never affected” may not be.

This process scales down. A small organisation may have one managed firewall, Microsoft 365, a web host, and an outside IT provider. It can still ask the provider for the public-service list, relevant sign-in review, remote-tool inventory, patch receipt, and written scope of the check. The number of systems changes. The logic does not.

## The useful lesson survives the seized domains

The October operation removed real infrastructure and published unusually detailed defensive evidence. Both are valuable. Neither reaches into a private environment and certifies it clean.

The story is therefore bigger than Flax Typhoon, MicroScan, or FishHub. External disruption and internal eviction are separate controls. One acts on the machinery an operator uses. The other restores trust inside the place that machinery may already have reached.

Use the seized domains as alert material. Use the technical advisory to reconstruct the likely route. Then follow that route past the public service, through persistence and identity, to the data and systems the intruder could touch. Repair each boundary in order.

A takedown can close the attacker's road. Your team still has to check the doors.

For practical security explanations without panic or filler, join the newsletter. It is one email per month.

## Sources

- [CISA and international partners: Chinese Government-linked Cyber Threat Actors Combine Automated and Hands-on Hacking Tools to Steal Sensitive Data](https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-281a), accessed 2026-10-12
- [US Department of Justice: Justice Department and FBI Seize Vulnerability Scanning and Spear Phishing Tools Operated and Used by China-State Sponsored Hackers](https://www.justice.gov/opa/pr/justice-department-and-fbi-seize-vulnerability-scanning-and-spear-phishing-tools-operated), accessed 2026-10-12
- [The Record: International coalition seizes tools used by cyber firm behind Flax Typhoon](https://therecord.media/flax-typhoon-china-tools-integrity-tech-international-takedown), accessed 2026-10-12
- [The Hacker News: FBI Seizes 7 Domains, Disrupts Flax Typhoon Tools Used in Critical Infrastructure Intrusions](https://thehackernews.com/2026/10/fbi-seizes-7-domains-disrupts-flax.html), accessed 2026-10-12

---

## About the author

Kubilay Tunca — Senior Full Stack Developer and Author. Founded Cyber Security in Plain English to translate complex security concepts into clear, practical advice, and writes the accompanying books on security, privacy, secure development, and AI systems.

## Books by this author

- **The Digital Fortress** — Your Everyday Guide to a Safer Digital Life. A warm, plain-English guide for people with real lives and finite patience. Learn the handful of habits that genuinely protect your money, accounts, and family, and get honest permission to ignore the rest. [Amazon](https://buy.cyber-security-in-plain-english.com/digital-fortress) · [Details](https://cyber-security-in-plain-english.com/books/the-digital-fortress)
- **The Anonymity Playbook** — Digital Survival for Whistleblowers, Journalists, Activists, and Everyone Else. A practitioner’s field manual for journalists protecting sources, whistleblowers, and activists. It explains how the surveillance actually works, what each technique costs you, and exactly where it fails. [Amazon](https://buy.cyber-security-in-plain-english.com/anonymity-playbook) · [Details](https://cyber-security-in-plain-english.com/books/the-anonymity-playbook)
- **Secure Software Development** — Practical patterns for building secure software. A hands-on security guide for developers and IT professionals who ship real software. Build, deploy, and maintain secure systems without slowing down or drowning in theory. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-software-development) · [Details](https://cyber-security-in-plain-english.com/books/secure-software-development)
- **The Secure Harness** — Shipping Production Code with AI Coding Agents. A calm, practical guide to letting agents do useful work inside boundaries you set, enforce, and audit. Ships with 15 copy-pasteable artifacts: hook scripts, permission configs, release gates, and MCP templates. [Amazon](https://buy.cyber-security-in-plain-english.com/secure-harness) · [Details](https://cyber-security-in-plain-english.com/books/the-secure-harness)
- **The AI Native Engineer** — Build, Evaluate, and Ship AI Systems That Work in Production. Sixteen hands-on chapters, one real product. Grow it from a single model call into a retrieved, tool-using, observable, production-grade system, with evaluation treated as a habit from the first feature. [Amazon](https://buy.cyber-security-in-plain-english.com/ai-native-engineer) · [Details](https://cyber-security-in-plain-english.com/books/the-ai-native-engineer)

Full catalogue with contents and intended audience: https://cyber-security-in-plain-english.com/books

_As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog._