MITRE ATT&CK T1598 Phishing for Information: Detecting Credential Harvesting by Email, Message and Phone

Phishing that asks for a password, an MFA code or a "connection code" never runs malware, so endpoint controls see nothing and the only evidence is in mail, web, phone and identity logs. MITRE ATT&CK T1598 Phishing for Information (tactic Reconnaissance) covers that elicitation: messages and calls designed to make someone hand over credentials or other information used for targeting. ATT&CK separates it from T1566 Phishing, whose goal is code execution. This guide covers the four v20 sub-techniques, the detection strategies MITRE maps, the identity provider signals that show harvested credentials being used, and the controls that make harvested data worthless. It is for email security, identity and SOC teams. Defence only: no lure or kit construction.

Key takeaways

• The target is identity material. Passwords, one-time codes, session cookies and OAuth consent or connection codes are what T1598 collects; each needs a different control.
• Four channels, one goal. v20 sub-techniques are T1598.001 Spearphishing Service, T1598.002 Spearphishing Attachment, T1598.003 Spearphishing Link and T1598.004 Spearphishing Voice.
• One-time codes do not survive real-time relay. ATT&CK describes EvilProxy and Evilginx2 proxying logins to capture session cookies; the 0ktapus campaign relayed OTPs through a Telegram bot.
• Detection is strongest after the hand-over. The phish may be invisible, but the sign-in from new infrastructure, the risky token or the new OAuth app is not.
• Phishing-resistant authentication is the decisive control. FIDO2 and passkeys bind the login to the genuine site, removing the value of most harvested credentials.

How the technique works

ATT&CK describes T1598 as phishing messages sent to elicit sensitive information, frequently credentials, through email, instant messages or other conversations, including messages that tell the victim to call a phone number. It often relies on posing as a trusted source, using accounts the adversary created (T1585 Establish Accounts) or compromised (T1586), on email spoofing (T1684.002), and on hiding replies with email hiding rules (T1564.008) in a compromised mailbox.

T1598 is usually fed by MITRE ATT&CK T1589 Gather Victim Identity Information, which supplies names, addresses and roles for convincing pretexts.

Where it shows up

• SMS credential harvesting: in the Twilio Breach 2022, staff received texts that appeared to come from IT, linking to look-alike domains such as twilio-sso.com and twilio-okta.com. Group-IB counted 9,931 credentials and 5,441 MFA codes across the wider 0ktapus campaign, which targeted more than 130 organisations.
• Vishing for OAuth consent: the ShinyHunters Salesforce Data Theft Campaign 2025 used callers posing as IT support to have staff enter a connection code that authorised an attacker-controlled connected app. ATT&CK v20 records this as campaign C0059 Salesforce Data Exfiltration under T1598.004. See the Callback Phishing (TOAD) Guide.
• Help desk impersonation at scale: ATT&CK links T1598 and T1598.004 to Scattered Spider (G1015) and LAPSUS$ (G1004). Microsoft reported Storm-1811 sending some Teams victims to an EvilProxy adversary-in-the-middle site to enter credentials.
• State-linked credential phishing: T1598.003 is linked to APT28, Star Blizzard, Kimsuky, Magic Hound and Silent Librarian, among others; Star Blizzard also appears under T1598.002.

Detection

MITRE's analytics for the link and attachment sub-techniques focus on mail and network: many accounts receiving messages from one unusual sender, DKIM and SPF failures, URL inspection including shortened and obfuscated links, homograph domains in browser logs, and unusual network flows. DET0886 suggests monitoring corporate call logs for known malicious numbers. Add the identity layer, where the harvested data is used.

For the mail layer, see the DMARC, SPF and DKIM Guide; for proxy kits and token theft, the AiTM Phishing Guide.

Detections to build first

1. Reported phish to sign-in correlation: when a user reports or clicks a phish, check their sign-ins for the next hours and revoke sessions automatically on any anomaly.
2. New MFA method after risky sign-in: a classic follow-on to harvested credentials and codes.
3. OAuth or connected app consent by non-admins: especially after a call or chat; the ShinyHunters pattern.
4. Look-alike domain registrations: brand plus identity provider terms, fed to takedown and to mail and web blocks.
5. Inbox rules hiding replies: rules that move or delete messages matching security or phishing terms.

Metrics

• Report rate and time to first report: NCSC advises measuring reporting as well as clicks.
• Time from report to session revocation: for users who entered credentials.
• Phishing-resistant MFA coverage: percentage of users, and of privileged and support staff, on FIDO2 or passkeys.
• DMARC enforcement: owned domains at p=reject or quarantine.
• User-consented OAuth apps without owner: count, trending to zero.

Prevention

Where identity fits

Every T1598 success ends in an identity event, and increasingly in a non-human one.

• Session tokens: adversary-in-the-middle kits take the session cookie, so MFA has already been satisfied. Short session lifetimes, token protection where available and revocation on risk matter more than password resets.
• OAuth apps and connected apps: the Salesforce campaign turned a phone call into a persistent app identity with API access that no longer needed the employee's credentials. See the Device Code Phishing Guide for the related device code flow.
• Help desk as a target: support staff are asked for resets and codes. Twilio moved staff to FIDO2 keys after 0ktapus. See the Vishing and Help Desk Social Engineering Awareness Guide.
• API keys and tokens: phishing developers for tokens or repository access gives machine credentials; after a supplier phish, rotate the keys your systems use with that supplier, as the Twilio analysis advises.

Responding to credential harvesting

1. Identify who interacted: message trace for all recipients, proxy logs for clicks, and user reports.
2. Revoke, then reset: revoke sessions and refresh tokens first, then reset passwords and remove any newly registered MFA methods.
3. Remove app grants: review and revoke OAuth consents and connected apps created in the window.
4. Block infrastructure: sender, domains, URLs and phone numbers at mail, web, DNS and telephony layers; request takedown of look-alike domains.
5. Hunt for use: mailbox rules, bulk exports, new devices and access to sensitive applications from the affected accounts.
6. Feed back: tell reporters what happened, and tune detections with the observed indicators.

Choosing where to start

• Small organisations: use the identity provider's built-in phishing-resistant methods and risk policies, turn on DMARC with the mail provider's defaults, block user consent to apps, and give staff one reporting address. That covers most of the value without a SOC.
• Large organisations: add reported-phish automation that searches and purges matching messages, correlation between mail, web and sign-in logs, look-alike domain monitoring with takedown, and telephony call records in the SIEM for vishing against support teams.
• Passkeys versus hardware keys: synced passkeys are easier to roll out to a large workforce; device-bound hardware keys suit administrators and help desk staff, where account recovery must not depend on a phone that can itself be socially engineered.
• Rollout order: pilot with IT and security staff, enforce for privileged and support roles, then expand by department, keeping a time-limited fallback for users who lose a key and logging every fallback use.

Common failure patterns

• OTP and push MFA treated as phishing-proof: 0ktapus relayed codes in real time.
• Password reset without session revocation: a stolen cookie keeps working after the password changes.
• Users allowed to consent to apps: vishing converts that permission into persistent API access.
• Email-only programme: SMS, QR, Teams and voice lures skip the mail gateway entirely.
• Click-rate metrics that punish reporting: NCSC advises a no-blame reporting culture.
• No look-alike domain monitoring: brand plus "sso" domains go live without anyone noticing.

Framework mapping

Practitioner checklist

• Move privileged, support and finance staff to phishing-resistant MFA first, then everyone.
• Enforce DMARC at quarantine or reject on all owned domains, including parked ones.
• Require admin consent for OAuth and SaaS connected apps.
• Correlate reported or clicked phish with sign-ins and revoke sessions automatically.
• Alert on new MFA methods, app consents and inbox rules after risky sign-ins.
• Monitor look-alike domain registrations and request takedowns.
• Restrict external chat contacts and label external users in collaboration tools.
• Give staff one easy reporting route for email, SMS, chat and calls, and reply to every report.

Standards and references

• MITRE ATT&CK: Phishing for Information (T1598)
• MITRE ATT&CK: Spearphishing Link (T1598.003)
• MITRE ATT&CK: Spearphishing Voice (T1598.004)
• NCSC: Phishing attacks: defending your organisation
• CISA, NSA, FBI and MS-ISAC: Phishing Guidance: Stopping the Attack Cycle at Phase One
• Microsoft Learn: What are risk detections? (Microsoft Entra ID Protection)
• Microsoft Threat Intelligence: Threat actors misusing Quick Assist in social engineering attacks leading to ransomware

Related NHI Mgmt Group resources: AiTM Phishing Guide · Callback Phishing (TOAD) Guide · MFA Fatigue and Bypass Guide · MITRE ATT&CK T1589 Gather Victim Identity Information · Phishing-Resistant MFA Guide