On 20 August, Google Threat Intelligence published an analysis of a phishing cluster it tracks as UNC7005. Google assesses with moderate confidence that the cluster is connected to ICE RELIC, the Russian actor formerly tracked as APT29 and also known as Midnight Blizzard. One of its campaigns targeted individuals in the European defence industry, and it used a technique that has been reported on plenty of times before: harvesting Google OAuth tokens through an attacker-controlled cloud project, which sidesteps a password and a second factor alike.
The tradecraft is not what caught our attention. The calendar is.
The timeline
31 July 2026: domains impersonating the Finnish Operations Center, a legitimate organisation that supports Finnish companies in the defence and security markets, are registered.
6 August 2026: the first phishing emails go out to European defence-industry targets.
13 August 2026: the last day of the sending window Google observed.
Six days between the infrastructure existing and the infrastructure being used.
That gap is not unusual, and it is not luck. It is how this kind of operation is built. You register the domain. You point it somewhere. You get a certificate so the browser does not complain. You stand up a page convincing enough to survive ten seconds of a defence engineer's attention. Then you send. Each of those steps takes time, and every one of them happens in public.
DNS is the earliest of them, and it is the one nobody is watching.
Why nobody sees the first six days
The defences most organisations own are positioned after the send. A secure email gateway sees the message when it arrives. An EDR agent sees the payload when it runs. A user-reporting button fires when somebody is already suspicious. All of these are downstream of the moment the operator committed to a domain. In this case, by six days.
The reason the registration goes unseen is boring: nobody is looking. Watching your own DNS is standard practice. Watching the domains that are pretending to be yours means enumerating a permutation space (character swaps, insertions, omissions, transpositions, homoglyphs, hyphenation, TLD substitutions) that runs to thousands of candidates for a single brand, then checking, repeatedly, which of them have started resolving. It is not hard. It is just not something anyone does by hand, so mostly it does not get done.
This is the normal case, not the exceptional one
It would be easy to file UNC7005 as a state-actor problem and move on. The registration data says otherwise.
Interisle's Phishing Landscape 2026 study found that 74% of domains used in phishing were registered by the attacker for that purpose, as against 26% that were legitimate domains later compromised. That ratio has worsened across the six years of the series, and the maliciously registered share concentrates in fewer than fifty gTLDs.
Read that number the right way round: for roughly three phishing domains in four, there was a registration event before the attack. A moment when the domain appeared in DNS and did nothing yet. A window.
The window is not always six days. Sometimes it is hours. But it exists in the substantial majority of cases, and it is the only point in the chain where the defender is ahead of the attacker rather than behind them.
We have written about the same pattern twice before at very different scales: 498 fake FIFA World Cup domains registered ahead of the tournament, and look-alike domains dressed as Microsoft security alerts. Nation-state, commodity crime, and opportunistic fraud all build infrastructure before they use it.
What domain-layer monitoring would and would not have done here
We want to be exact about this, because the temptation to overclaim on an incident post is strong and it is the fastest way to lose a technical reader.
What it would have caught: the registration of a domain resembling the impersonated organisation, on 31 July, and the moment that domain began resolving. A team watching the permutation space around their brand would have had a named, dated, resolvable artefact roughly six days before the first email. Enough to warn recipients, brief a helpdesk, pre-emptively block the domain at the resolver, and start a registrar abuse report while the operator was still building.
What it would not have caught: anything downstream of that. The OAuth consent flow, the token harvest, the attacker's cloud project. None of that touches the victim's DNS, and no amount of DNS monitoring sees it. If the domain warning is missed or ignored, domain-layer monitoring contributes nothing to the rest of the incident.
It is one early signal, not a control. It happens to be the earliest one available, which is the entire argument for it.
What to actually do
In rough order of effort:
Find out what already exists. Before building any programme, establish the baseline: how many look-alikes of your domain are registered right now, and how many of them resolve. Most people are surprised, in both directions.
Watch the permutation space continuously, not once. A quarterly check finds what was registered last quarter. The whole value is in the six days, and a check that runs less often than the window is closed misses it by construction.
Alert on the state change, not the existence. Thousands of variants of any well-known brand are registered and parked forever by squatters. The signal is not "a variant exists". It is "a variant that was dormant yesterday is answering today, and has a certificate." Anything alerting on mere existence will be muted within a week.
Decide the response before you need it. Who files the registrar abuse report, who blocks it at the resolver, who tells the helpdesk. Six days of warning is worth nothing if it lands in an inbox nobody owns.
Watch your own records too. Look-alike registration is one attack shape. Getting your real records changed, at the registrar, at the DNS provider, or, as in the April 2026 CoW Swap incident, at the registry itself, is the other, and it needs the same continuous baseline-and-diff approach applied to zones you own.
Where DNS Spy fits
Phishing Sentinel enumerates look-alike permutations of the domains you monitor and re-checks them on a four-hour cycle, recording which variants resolve, what they resolve to, and how that changes over time. Alongside DNS records it captures resolved hosts (IP, ASN, geolocation, SSL certificate), so an alert arrives with the infrastructure detail an abuse report needs rather than just a string. Variants carry a lifecycle state, and one that disappears and later comes back is flagged again rather than staying quietly closed.
Two things we will not pretend about:
We do not perform takedowns. DNS Spy gives you the evidence to file one. Filing it, and chasing the registrar, is yours, or your brand-protection vendor's.
Phishing Sentinel is an Enterprise plan feature. It is not part of the entry-level DNS monitoring tier.
If you only want the first item on the list above, what is already registered against your brand, that does not need an account. Our free typosquatting scanner takes a domain, generates the permutation set, and tells you which variants resolve today. It is the same enumeration Phishing Sentinel runs. The difference is that Phishing Sentinel keeps running it.
Scan your domain for look-alikes
For the continuous version, see Phishing Sentinel and brand protection at the domain layer.
Sources
Google Threat Intelligence Group, Distinct clusters target individuals of interest to Russia, 20 August 2026: cloud.google.com. UNC7005 attribution, the 31 July registrations and the 6 to 13 August sending window.
The Register, 21 August 2026: Russian snoops add OAuth abuse to targeted phishing campaigns.
Interisle Consulting Group, Phishing Landscape 2026: Malicious Domain Registrations: interisle.substack.com. 74% maliciously registered versus 26% compromised.
Domain Name Wire, 17 April 2026: Domain hijack led to crypto heist. The CoW Swap registry-level hijack.
