Related to the series on Japan’s cybersecurity blind spot. Start with the overview, Japan cyberattacks in 2026: what the breach wave reveals, or read the latest part, Nobody had to hack Japan’s earthquake warning.

On 16 October 2026, Maddie Baker quoted me in The Japan Times: Japanese authorities target websites selling phishing tools used to mastermind scams. Two days earlier, Ariana King reported What happens to your information after a data breach. Read those two together.

I urged the Japanese public not to “just sit there and wait for a bad thing to happen”, and I said that turning on secure Domain Name System (DNS) settings is one step that helps protect people from scams. The takedown figures are Baker’s reporting. The judgment after them, and the steps that follow, are mine.

What the police took down

The National Police Agency’s Cyber Investigation Division, in its first collaboration with Microsoft and other organizations, took down 34 website domains selling phishing tools between 8 October and 14 October, after an American court order.

Microsoft said the tools enabled “less skilled cybercriminals to target organizations (including some Japanese hospitals and companies) at scale.” Scammers bought kits such as CoGUI and IronMan with cryptocurrency on sites like YAM Store, then used stolen legitimate Microsoft or Google cloud servers to host credible fake sites.

The NPA found that CoGUI and IronMan alone were used to create about half of the 120,000 fraudulent sites in Japan in 2025. Such tools are believed to have been used against people whose email addresses were recently leaked in Japan. Microsoft says over 100 million fraudulent emails have been sent to targets in Japan since May.

Microsoft attributes the kits to “Chinese-speaking threat actors” in a wider global “cybercriminal ecosystem.” Microsoft recommends security software, passkeys, and multifactor authentication instead of only passwords.

Closing those 34 domains removes the shops. The fraudulent mail is already in circulation: Microsoft’s count is over 100 million messages to targets in Japan since May. If your address was recently leaked, you are in the group these tools are believed to have been used against.

I keep a row for every organization in Japan that has published a cyber incident notice, on the Japan breach tracker. If a service you use is on that list, open the notice itself before you trust a message about the incident. The series overview, Japan cyberattacks in 2026: what the breach wave reveals, is the longer account of how those disclosures fit together.

Turn on encrypted DNS

A normal DNS lookup asks a resolver, “what is the address of this name?” In a lot of homes and offices that question still travels in the clear, and the resolver is whichever one the network handed the device. Secure DNS sends the same question over an encrypted connection to a resolver you choose. Browsers do this with DNS over HTTPS. Phones often do it with DNS over TLS.

Use a filtering resolver: one that answers ordinary lookups and refuses names it already knows are used for phishing or malware. Two public examples are Quad9 and Cloudflare’s malware-blocking resolver. Quad9’s familiar address is 9.9.9.9, and its encrypted hostname is dns.quad9.net. Cloudflare’s malware-blocking addresses are 1.1.1.2 and 1.0.0.2, and the encrypted hostname is security.cloudflare-dns.com. They are examples. Any filtering resolver you trust is the same kind of step.

On an Android phone, open the network settings and set Private DNS to the provider hostname. That field wants a name such as dns.quad9.net or security.cloudflare-dns.com. An IP address will be rejected. Private DNS uses DNS over TLS, so the lookup is encrypted and the filter applies to the apps on that phone.

On an iPhone or iPad, Apple applies encrypted DNS through a configuration profile. Download the profile from the resolver you chose and install it in Settings. There is no hostname box that matches Android’s Private DNS field. The profile is the switch.

In Chrome, Edge, and Firefox, turn on the secure DNS setting. Chrome and Edge label it “Use secure DNS.” Firefox labels it “DNS over HTTPS.” Choose a filtering provider, or enter the resolver’s DNS over HTTPS address if the browser lets you set a custom one. For these two examples, those addresses are https://dns.quad9.net/dns-query and https://security.cloudflare-dns.com/dns-query. The browser setting covers that browser. Mail, other browsers, and the rest of the device still follow the system resolver, so set the phone or computer as well.

On a home router, set the DNS server the router gives to the network. Devices that do not pick their own resolver then inherit the filter, which is how a television, a console, and a guest phone get the same protection without a profile each. Many routers can only store a plain address such as 9.9.9.9 or 1.1.1.2. That still filters. Encryption on the router itself requires a router that speaks DNS over HTTPS or DNS over TLS. A browser with secure DNS turned on does not use the router’s DNS, so set both if you want the browser and the rest of the network covered.

A filtering resolver can refuse only names already on its list. A domain registered today may not be on that list yet. Encrypted DNS also leaves you exposed if you type a password into a page that loaded anyway. It is still worth doing today. A household can change the setting without waiting for a company to send a notice, and it stops names the resolver has already classified as phishing or malware.

Passkeys, and a second factor

A password by itself is what a phishing kit is built to collect. Microsoft recommends security software, passkeys, and multifactor authentication instead of only passwords. That is the same set I turn on for clients.

Keep the operating system updated on the computers and phones people actually use, and run a security tool from a vendor you already have a reason to trust. The kits in Baker’s article put a credible fake site in front of someone and collect the login. Updated software is the part you can finish before you change a single password. The passkey and the second factor still protect that login if the fake page loads.

A passkey stays on the device, or in a password manager, and the browser releases it only to the real site. The fake page can copy the logo, the layout, and the sentence asking you to sign in. The browser checks the site name before it hands the key over, so the copy fails that check. Turn passkeys on first for the accounts that can reset other accounts: email, then Apple, Google, or Microsoft, then the bank if it offers them. Store a second passkey, or the recovery method the service documents, so a lost phone is a nuisance.

Where a passkey is not offered yet, turn on multifactor authentication. Start with email. That inbox is how a stranger asks every other service to reset a password. When the service offers a choice, use an authenticator app or a passkey. A code that arrives by text can be redirected. Use the text-message code only when the service offers nothing stronger.

Do this at home and at the company. The shared inbox, the Microsoft 365 or Google Workspace administrator, and the account that controls the domain are the logins a kit is built to find. One person protecting a personal mailbox helps that person. The same switch on the account that can reset everyone else changes the outcome for the organization.

The message is how the kit arrives. The fake site is where the password is collected. Baker’s article describes kits that let less skilled criminals do both, and scammers then hosted the fake sites on stolen legitimate Microsoft or Google cloud servers.

When a message asks you to confirm a payment, reset a password, update a delivery, or verify an account, leave the link alone. Open the service from a bookmark, or type the address you already know. After the page loads, read the domain in the address bar. The display name on the message is the part the sender controls. A page on a stolen cloud server can look credible and still be the wrong organization. The cloud company’s name in the address is the host. The organization you meant is the name you typed yourself.

Use the same rule for SMS. A short link and a deadline are the whole design. If you were not already in the middle of that exact task, with that exact organization, the message can wait until you have opened the real site yourself.

People whose email addresses were recently leaked are the group these tools are believed to have been used against. In Nobody had to hack Japan’s earthquake warning I wrote about phishing already sent to addresses leaked from a local-government alert service. The takedown Baker reported is the supply side of that problem: the sites that sold CoGUI, IronMan, and the kits like them. Taking the shops down does not pull back the mail already sent.

If you run an organization, warn people before the lure arrives. Name the address you will use. Say that you will not ask for a password by email or text. Give them the real login to bookmark. Blood in the water covers the mail checks, SPF, DKIM, and DMARC, that make a forged message easier for a receiver to reject. Those checks are the organization’s job. Encrypted DNS, passkeys, and refusing the link are what a person can do the same day.

Where I come in

I’m an IT infrastructure advisor in Tokyo, with 14 years in Japan. I help organizations see what their domains, mail, and logins show the outside world, and turn on the controls that make a phishing kit less useful against them.

A good place to start is my external exposure check: up to three domains, public information only, with a written report in five business days and a 30-minute debrief, for ¥100,000 + tax. The check covers email authentication, DNS, the website, public login pages, and certificates. Diagnostics goes further, into the vendors, accounts, and access paths behind those systems. Write to me at matt@mkultraman.com, in English or Japanese.

Sources