AV-01 · Phishing and credential theft

Phishing works because it targets the person, not the system. Email lures, credential-harvesting pages, MFA fatigue, and session theft bypass firewalls and EDR by exploiting the authentication workflow itself.

$ action: Deploy phishing-resistant MFA, add conditional access controls, and build a fast account lock and session revocation playbook you've actually tested.

1. Why This Attack Vector Persists

Phishing works because it targets the person, not the system. A convincing email bypasses firewalls, EDR, and patch management in one click. Detecting it means watching for anomalies in the authentication layer — unusual login times, unfamiliar IPs, MFA prompts the user didn't initiate.

This category goes well beyond classic email lures. Credential harvesting pages, MFA fatigue attacks, token and session theft, and social engineering designed to push users into approving malicious access all belong here. The attacker doesn't need to exploit software if they can exploit trust.

Strong perimeter and endpoint controls don't protect an organization whose identity workflows, account recovery procedures, and user reporting culture are weak. Those gaps are exactly where this vector lands.

2. What Defenders Should Monitor

Pull authentication logs first. Look for impossible travel, repeated failed sign-ins followed by a success, new device registrations, abnormal MFA prompt volumes, and session tokens created from infrastructure you haven't seen before.

Email and web telemetry fill in what the identity provider misses. Track redirects to lookalike login domains, suspicious link clicks in email gateway logs, and user reports of prompts they didn't request. Fast user reporting is often the earliest signal available.

Correlate across sources — identity provider, email security gateway, VPN and SSO logs, and endpoint telemetry. A single anomalous login from an unusual country is noisy. That same login preceded by a suspicious email click and followed by a new inbox forwarding rule is a confirmed phish.

3. Defensive Response and Prevention

Push phishing-resistant authentication methods where your environment supports it. Add conditional access controls that check device posture, location, and risk score before granting access — not just a password match.

Speed matters after a credential theft event. Organizations that take hours to revoke sessions and lock accounts give attackers time to establish persistence, change MFA registration, and access mailboxes. Build the playbook before you need it.

Train users on what your actual login pages, MFA prompts, and account recovery flows look like. Generic 'don't click links' advice doesn't stick. Specific, system-tied training does.

detection-signals

$Authentication log shows a successful login from an IP, ASN, or country not in the user's recent history, immediately following prior failed attempts.
$MFA logs show 10+ push notifications to a single user within a few minutes, or an approval immediately following a burst of denials — classic fatigue pattern.
$A new device or unfamiliar user agent registers a session within minutes of a suspicious email click recorded in the gateway.
$High-value app access from an unmanaged device or browser profile that has never appeared in identity logs before.
$User reports an MFA prompt they didn't initiate, or calls IT about a login page that looked slightly wrong.

telemetry-sources

$Identity provider / SSO sign-in logs (success/failure, MFA events, device trust, risk scoring).
$Email security gateway logs and user-reported phishing messages.
$Web proxy / DNS logs for lookalike domains and suspicious redirects.
$Endpoint/browser telemetry for suspicious sign-in pages and token/session artifacts.
$VPN / remote access logs to correlate post-authentication behavior.

recommended-tools-and-guides

open /learning/linux-windows-logging-basics-for-defenders Learn host and auth logging basics before triaging identity events. open /learning/alert-triage-false-positives-detection-tuning Build a repeatable triage process for suspicious sign-in alerts. open Wireshark / TShark Validate suspicious network flows during post-phish activity or callback traffic. open Wazuh Centralize host/security telemetry and correlate authentication-related events. open Sigma Write and tune portable detections for suspicious auth behavior.

related-learning-modules

Build fundamentals and workflows that directly support defending against this threat pattern.

open /learning/linux-windows-logging-basics-for-defenders Linux and Windows Logging Basics for Defenders open /learning/alert-triage-false-positives-detection-tuning Alert Triage, False Positives, and Detection Tuning open /learning/incident-response-playbooks-framework-functions Incident Response Playbooks Aligned to Recognized Cybersecurity Framework Functions

related-tool-pages

Use these detailed tool guides to practice safe validation, evidence collection, and triage workflows for this threat.

open /learning/tools/wireshark-tshark Wireshark / TShark open /learning/tools/wazuh Wazuh open /learning/tools/sigma Sigma

lab-safe-detection-workflows

These commands are for learning, validation, and defensive triage in your own lab or authorized environment. Adapt to your tooling and log locations.

Quick DNS / URL triage (lab or approved proxy logs)

grep -i "login\|signin\|mfa" /var/log/proxy/access.log | tail -n 50 || true
tshark -r sample-phish.pcap -Y dns -T fields -e frame.time -e ip.src -e dns.qry.name
tshark -r sample-phish.pcap -Y http.request -T fields -e ip.src -e http.host -e http.request.uri

$ why: Use packet/proxy evidence to validate where a user was sent and which domains or hosts were contacted.

Authentication log review workflow (generic Linux/forwarded logs)

journalctl --since "-2h" | grep -Ei "auth|login|mfa|sso|token" | tail -n 100
grep -Ei "failed|success|mfa|token" /var/log/auth.log | tail -n 80 || true
printf "user,time,ip,event,confidence,next_action\n" > auth-triage.csv

$ why: Build a short evidence table before escalating so your conclusions are tied to timestamps and sources.

triage-questions

?Was the suspicious login preceded by a phishing email delivery, a link click in the gateway logs, or a redirect to an unfamiliar domain?
?Did the user report unexpected MFA prompts, or did they approve a push notification they didn't initiate?
?Was a new session or token created from a device, IP, or user agent that doesn't appear in the user's history?
?What high-value applications or admin paths were accessed after the suspicious sign-in, and for how long?
?Have active sessions been revoked and accounts reset or locked — and has MFA registration been reviewed for unauthorized changes?

defender-actions.checklist

$Enable phishing-resistant MFA where supported.
$Deploy conditional access policies for risky sign-ins and unmanaged devices.
$Monitor MFA fatigue patterns and unusual push approval bursts.
$Prepare an account lock / reset / session revocation playbook and practice it.
$Train users to report suspicious login prompts and credential pages quickly.

study-workflow

Learn what normal behavior looks like for this area (auth, exposure, config, or internal traffic).
Identify the logs and telemetry that should show the behavior.
Practice one safe validation in a lab or authorized environment.
Write a short playbook for detection, triage, and response.
Review the related tool guides under /learning/tools.

<- threats index Back to threat overview list -> next threat AV-02 · Exposed services and remote access weaknesses