If your organisation is looking at where to put some additional phishing protection right now, two campaign types should be near the top of the list: ClickFix and Device Code Phishing.
Based on phishing activity being observed across New Zealand and Australia during September and into October, these two techniques are currently accounting for almost half of the reported phishing cases being seen.
That makes them worth specifically targeting rather than relying solely on traditional phishing controls.
ClickFix and Device Code Phishing
ClickFix campaigns typically attempt to convince a user that something is wrong with their browser, document, account or device and that they need to perform an action to fix it.
The “fix” is often anything but.
Users can be socially engineered into copying and executing commands, visiting a malicious site, or interacting with content designed to ultimately provide the attacker with access.
Device Code Phishing takes a different approach, abusing legitimate authentication workflows to trick users into authenticating a device or session controlled by the attacker.
Both techniques exploit something that traditional email security can struggle with: the user is being manipulated into performing an action that may not initially look malicious.
Organisations should therefore consider whether their existing email, web, identity and endpoint controls specifically address these techniques.
The phishing infrastructure behind the initial URL matters
Another interesting trend is the longevity of what could be described as secondary phishing infrastructure.
Many phishing campaigns use legitimate or trusted services as the initial delivery mechanism. These “living off trusted services” URLs can often make it through email security controls because the domain itself belongs to a legitimate service.
The URL then redirects the victim to another domain where the actual phishing activity takes place.
These secondary domains appear to have a considerably longer lifespan than traditional phishing domains.
A normal phishing domain may appear, be reported and disappear within a day. In contrast, some of the secondary infrastructure currently being observed remains active 30 days or more after it was first identified.
For organisations maintaining blocklists, this suggests that a short blocking period may not be sufficient.
Our current recommendation is to consider retaining blocks against identified secondary phishing infrastructure for up to 90 days, subject to your normal blocklist management and validation processes.
A strange URL that redirects to a legitimate website?
There is another useful indicator for security teams investigating suspicious URLs.
Some phishing infrastructure appears to fingerprint the visitor before deciding where to send them. If the visitor’s IP address, location or other characteristics don’t match the campaign’s intended victim profile, the phishing site may simply redirect them somewhere harmless.
This can make investigation more difficult.
If a suspicious URL is reported by a user and checking it results in a redirect to one of the following sites, don’t automatically assume the original URL is benign:
superhonda.comx.comspacex.comquickbooks.intuit.comwikipedia.org
The redirect is the result of the phishing infrastructure deciding that the current visitor isn’t a suitable target, usually based on the country the user is based in not being the one targeted by the actors behinf the phishing.
In other words, what the URL does for the security analyst isn’t necessarily what it does for the intended victim.
Pay attention to the domain — but don’t rely on the TLD alone
There are also some domain endings appearing repeatedly in reported suspicious URLs in NZ and AUS.
Current observations include:
.cc.sbs.cfd.es.brworkers.devreplit.appvercel.app
The last three are particularly interesting because they are legitimate developer and hosting platforms. Their presence should not automatically make a URL malicious.
The same applies to .cc, .sbs, .cfd, .es and .br.
A domain ending is an indicator, not proof of phishing.
However, when these domains appear in a user-reported suspicious email, they should receive additional scrutiny rather than being dismissed simply because automated reputation systems haven’t flagged them.
Listen to your users
Perhaps the simplest recommendation is also one of the most important:
Take user-reported suspicious URLs seriously.
Users generally aren’t reporting URLs because they have nothing better to do. Something about the email, link, login page or request has made them suspicious.
That report is valuable security telemetry.
Security teams should consider feeding these reports into their detection and response processes and looking for common infrastructure across reports — particularly:
- ClickFix activity
- Device Code phishing
- redirects through trusted services
- recently observed secondary phishing domains
- suspicious developer-hosting infrastructure
- repeated URL patterns across multiple users or organisations
What should organisations do now?
For NZ and Australian organisations, some relatively simple defensive measures can make a difference:
1. Prioritise ClickFix and Device Code phishing.
Make sure your email, web, identity and endpoint controls are specifically considering these techniques.
2. Don’t just block the first URL.
Investigate redirects and the infrastructure sitting behind trusted-service URLs.
3. Extend blocklist lifetimes.
For confirmed secondary phishing infrastructure, consider a 90-day block period rather than assuming the infrastructure will disappear within a few days as we are seeing longer lifetimes.
4. Treat redirects as potentially evasive behaviour.
A suspicious URL redirecting to Wikipedia, X or another well-known website doesn’t prove that the original URL is safe and the 5 listed above certain should get a higher level of scrutiny.
5. Investigate user reports.
User-reported URLs can provide some of the best indicators of a campaign.
6. Hunt across the organisation.
When one phishing URL is reported, search email, DNS, proxy, firewall and endpoint telemetry for other users who may have interacted with the same infrastructure.
The broader lesson is that phishing defence is increasingly about understanding the infrastructure and behaviour behind the link, rather than simply asking whether the first domain in the email has a bad reputation.
And with ClickFix and Device Code phishing making up such a significant proportion of current reported activity across NZ and Australia, these are two areas where defensive effort is likely to pay dividends right now.
