How AI Catches APT-Style Credential Phishing Early

APT groups don’t need fancy zero-days to cause real damage. They just need you to type your password into the wrong page once.

That’s why the recent reporting on APT28’s long-running credential phishing against Ukrainian UKR-net users is so instructive. The mechanics are almost boring: PDFs in email, link shorteners, legitimate hosting, redirection chains, and a fake login that asks for both credentials and a 2FA code. But the persistence is the point. APT operators are professional. They’ll run the same play for months, adjust their infrastructure when it gets burned, and keep going until the target population is tired, distracted, or overwhelmed.

This post sits in our AI in Defense & National Security series for a reason: national security threats aren’t only missiles and malware implants. They’re also identity compromises at scale—the kind that quietly feed intelligence collection, influence operations, and follow-on intrusions. If you’re defending an agency, a defense contractor, a logistics provider, or any org tied to geopolitical outcomes, credential phishing is not a “user training” problem. It’s a detection-and-response engineering problem.

What the APT28 campaign tells defenders (and what changed)

Answer first: APT28’s UKR-net campaign shows that modern credential phishing is a multi-stage identity attack, and defenders must detect behavior and infrastructure patterns—not just “bad domains.”

Recorded observations describe a sustained effort (mid‑2024 through early‑2025) using:

• PDF lures delivered via phishing email
• Shortened links (common consumer services) to mask destination
• Legitimate hosting for the phishing page (for example, simple page hosting services)
• Two-tier redirection using popular platforms (including blog subdomains) to complicate analysis
• Real-time 2FA interception by asking users for one-time codes
• A shift from compromised routers to proxy/tunneling services (for example, tools commonly used for exposing local services)

The “what changed” matters. When infrastructure takedowns make certain paths expensive, capable actors adapt quickly. Free hosting plus anonymized tunnels gives them fast rotation, plausible legitimacy, and low operational friction.

Why this is hard to stop with traditional controls

Answer first: Traditional email gateways and URL blocklists struggle because the attacker hides behind trusted platforms and churns infrastructure faster than lists update.

Most security stacks still over-weight these signals:

• domain reputation
• attachment hashes
• known-bad URL indicators

APT28-style phishing often slips through because:

• The initial URL is a well-known shortener.
• The hosting platform is legitimate, so reputation is “clean.”
• Redirectors are spread across services defenders can’t reasonably block wholesale.
• The phishing page is themed correctly (UKR-net branding), and it’s often live for a short window.

And if the page is built to capture both password and 2FA, the attacker doesn’t even need to “break MFA.” They just persuade the user to hand it over.

Three early signs of credential phishing—and how AI spots them

Answer first: AI-driven threat detection works here because it can correlate weak signals across email, web, identity, and endpoint telemetry—fast enough to stop the login before it becomes an incident.

Here are three signs defenders can catch early, plus the AI approach that actually scales.

1) “Legit service” hosting + brand impersonation

What you see: A login page hosted on a benign platform, branded to match a real service (like a regional webmail provider).

Why it fools people: Visual trust beats technical skepticism. Users recognize the logo and move on.

How AI helps: Use computer vision + DOM fingerprinting to detect “brand lookalikes” even when domains are clean.

Practical patterns an ML model can score:

• logo similarity to known brands
• page layout similarity to known login templates
• suspicious form behavior (posting credentials to unrelated endpoints)
• presence of “enter your verification code” prompts that don’t match the real service flow

If you’ve never tried this, it’s eye-opening: the page can live on a trusted host, but the rendered experience is still a counterfeit.

2) Short links and redirection chains that don’t match user behavior

What you see: A PDF contains a short link. That short link bounces through one or two redirectors and lands on a themed login page.

Why it fools tools: Each hop may look harmless in isolation.

How AI helps: Model the chain as a graph and score it for phishing likelihood.

High-signal features include:

• number of redirects and time-to-final landing
• platform mix (shortener → blog subdomain → static page host)
• newly created paths, random-looking URL tokens, or mismatched language/locale
• unusual user-agent or referrer behavior (e.g., PDF viewer → shortener → login)

Graph-based anomaly detection shines because it doesn’t need every hop to be “known bad.” It needs the chain to be weird in a way that correlates with credential theft.

3) 2FA interception behavior at the identity layer

What you see: A user enters credentials and then quickly enters a 2FA code—followed by a login attempt from an unfamiliar network/location/device.

Why it’s dangerous: Once the attacker has a fresh one-time code, they can create a session and often register a new factor or app password, depending on policy.

How AI helps: Combine risk-based authentication with real-time session correlation.

A useful stance is simple and aggressive:

• If a user’s 2FA entry is followed within minutes by a new session from a novel ASN/geo/device, treat it as high confidence phishing.
• Trigger step-up (hardware-backed factor), or block and force password reset.
• In parallel, auto-hunt for other recipients who clicked the same lure chain.

This is where AI earns its keep: it can spot the sequence (click → credential entry → 2FA entry → novel login) and act before the attacker establishes persistence.

Where AI fits in an “APT-grade” phishing defense stack

Answer first: AI is most effective when it’s embedded across the kill chain—email triage, web protection, identity risk, and automated response—not as a single standalone “phishing detector.”

Here’s a practical blueprint that I’ve found works better than buying yet another point solution.

Email layer: prioritize for human review, don’t promise perfection

AI at the email layer should focus on ranking and clustering:

• Cluster similar lures (same PDF structure, same redirect chain pattern, similar language).
• Prioritize messages sent to high-value roles (finance, ops, comms, leadership, cleared staff).
• Flag “rare sender + attachment + link” combos that deviate from org baselines.

This reduces analyst fatigue. And it matters in December especially: end-of-year invoicing, holiday staffing gaps, and “last chance before break” urgency are exactly when phishing success rates rise.

Web layer: detonate, render, and score

Instead of relying only on URL reputation, use AI-assisted browsing defenses that:

• follow redirects in a sandbox
• render the page and analyze visual/DOM similarity
• detect credential collection forms
• identify tunneling/proxy patterns and suspicious post destinations

If you can only do one thing, do this: treat “login page reached via shortener from a document” as high risk and inspect it deeply.

Identity layer: make the IdP your tripwire

A lot of orgs treat identity logs as audit trails. They’re more valuable as detectors.

AI-driven identity analytics should watch for:

• impossible travel and rapid geo shifts
• novel device + sensitive app access
• abnormal token issuance patterns
• new MFA enrollment following a risky login
• mailbox rule creation, forwarding, and OAuth consent anomalies

If your identity provider can’t feed these events to your detection stack in near real time, you’re giving attackers a time advantage they don’t deserve.

Response layer: automate the 80% actions that stop the bleed

Automated response doesn’t mean “auto-close tickets.” It means containment you can trust.

For suspected credential phishing with 2FA interception, the safe automation set is usually:

1. Disable active sessions / revoke refresh tokens
2. Force password reset
3. Require phishing-resistant MFA at next login
4. Quarantine similar emails across mailboxes
5. Block the redirect chain artifacts (where feasible)
6. Open an investigation bundle (email + web + identity timeline) for an analyst to confirm

The goal is to prevent the attacker from turning one phished account into lateral movement, data access, and persistence.

What “good” looks like for national security and defense orgs

Answer first: For defense and national security environments, success is measured by time-to-detect and time-to-contain identity compromise—because that’s what determines whether phishing becomes intelligence collection.

APT28’s historical targeting profile (government institutions, defense-adjacent supply chains, policy organizations) aligns with an uncomfortable reality: many strategic intrusions start with a single mailbox.

A pragmatic maturity target for 2026 planning cycles:

• Detect suspicious credential phishing journeys within minutes, not hours.
• Contain high-confidence identity compromise within 15 minutes (session revoke + forced reset).
• Hunt for campaign spread (similar lures, shared redirect infrastructure) the same day.

If those numbers sound aggressive, good. APT operators are running an industrial process. Defenders need one too.

People also ask: “If we already have MFA, why is this still working?”

Answer first: MFA blocks password-only attacks, but it doesn’t stop real-time phishing when users hand over the one-time code or approve a prompt.

Mitigations that consistently reduce this risk:

• phishing-resistant factors (hardware-backed keys, passkeys where supported)
• number matching / higher-friction approvals
• conditional access tied to device health and location
• blocking new MFA enrollment unless the session is strongly verified

People also ask: “Can AI reduce false positives in phishing detection?”

Answer first: Yes—if AI is used for correlation and context, not just classification.

False positives drop when the system asks, “Is this behavior abnormal for this user and this org?” rather than “Does this email look phishy in general?”

A practical next step: build an APT28-style simulation

Answer first: You’ll defend better if you test the full chain—PDF lure → short link → redirect → fake login → suspicious IdP login—because that’s the chain AI needs to detect.

Run an internal purple-team exercise (safely, with controls) that simulates:

• a PDF attachment containing a shortened link
• a redirection chain
• a credential collection page (in a training environment)
• an attempted login from an external network

Then measure:

• How quickly your tooling flags the email and the URL chain
• Whether identity risk triggers step-up or blocks access
• Whether your SOC can see a single timeline without manual stitching

Most companies get this wrong by testing only the email filter. The real test is whether the identity layer and response automation prevent session establishment.

Where this is heading in 2026

APT28’s campaign is a reminder that phishing is adapting faster than policy memos. The organizations that stay resilient will be the ones that treat identity telemetry as a sensor grid and use AI to connect the dots across systems.

If you’re responsible for security in a defense, government, critical infrastructure, or defense-adjacent supply chain environment, you don’t need another awareness poster. You need an AI-assisted detection pipeline that can spot multi-stage phishing patterns and shut down compromised sessions fast.

What would change in your incident count if every “entered credentials into a fake login” event triggered containment in 10 minutes—before the attacker ever reads the inbox?