Phishing for Information

Phishing for information sits early in an intrusion, after the attacker has already used Gather Victim Identity Information (T1589) and Gather Victim Org Information (T1591) to build a target list, and before Valid Accounts (T1078) or a payload-bearing T1566 message gets sent. MITRE's own procedure examples show the range: APT28 ran spearphishing campaigns specifically to compromise credentials, Kimsuky used tailored spearphishing to gather victim information and identify further targets, and Scattered Spider combined credential phishing with social engineering to capture one-time passcodes directly from help-desk and MFA workflows.

What happens next depends on what was harvested. A working password feeds straight into Valid Accounts logins, often from new infrastructure within minutes of submission. A captured session cookie from an AiTM kit skips the password entirely and lets the attacker reuse an already-authenticated session. Scattered Spider's OTP-capture variant chains directly into live account takeover and, in several documented intrusions, follow-on help-desk social engineering to reset MFA on the same account. Because none of this requires a payload, it will not show up in an EDR alert queue; the email and identity layers are where this campaign stage is visible at all.

Legitimate password-expiry reminders, real vendor onboarding emails from a newly contracted supplier, and marketing platforms that rotate sending domains and IP pools all trip the same heuristics as credential-phishing lures: a rare sending domain, a link, and urgent-sounding subject lines. Transactional email providers (payment processors, HR platforms, ticketing systems) frequently send from freshly provisioned subdomains that look identical to a lookalike domain on paper.

The fix is correlation, not any single heuristic in isolation. Maintain an allow-list of verified SaaS and vendor sending domains, weight a DKIM or SPF pass heavily against alerting, and require at least two independent signals, such as a rare domain plus a cluster shared across multiple unrelated senders, or a flagged-domain URL plus urgent password-reset language, before treating a message as credential phishing rather than legitimate transactional mail. A single rare-domain alert with no cluster and no flagged URL is not worth an analyst's time.

When this fires, first establish whether anyone actually interacted with the message: did a recipient click the link, submit credentials, or call back a number in the email. Next check authentication: is SPF, DKIM, or DMARC failing while the sender spoofs an internal or vendor domain, and does the embedded URL resolve to a domain already flagged by a security-alert feed. Those two answers determine whether this is a contained near-miss or an active credential-theft event.

If credentials were submitted, force an immediate password reset and revoke active sessions for every targeted account, since AiTM kits capture the session token and a password change alone will not evict them. Pull sign-in logs for the affected accounts for new countries, ASNs, or device fingerprints appearing right after the click. Block the sending domain and the flagged URL at the gateway, and use the EmailClusterId or subject-line match to purge remaining copies of the same lure tenant-wide before more recipients open it.