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.
| Sub-technique (v20) | Channel | What ATT&CK describes | Detection strategy |
|---|---|---|---|
| T1598.001 Spearphishing Service | Social media, personal webmail and other non-enterprise services | Fake recruiter or contact profiles building rapport to ask about services, policies and the environment | DET0821 |
| T1598.002 Spearphishing Attachment | Email attachment | Forms the victim fills in and returns, or HTML smuggling (T1027.006) to fake login portals | DET0865 |
| T1598.003 Spearphishing Link | Email or message link, QR code | Cloned login portals, URL obfuscation, tracking pixels, browser-in-the-browser pop-ups, adversary-in-the-middle kits capturing cookies (T1539), quishing | DET0878 |
| T1598.004 Spearphishing Voice | Phone, callback numbers, robocalls | Vishing with spoofed numbers posing as partners or technical support; callback phishing | DET0886 |
| T1598 (parent) | Any electronic conversation | Mass credential harvesting or targeted elicitation | DET0823 |
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.
| Stage | Signal | Log source |
|---|---|---|
| Delivery | One external sender to many recipients; SPF, DKIM or DMARC failures; newly registered or look-alike domains combining your brand with "sso" or "okta" | Mail gateway and message trace; certificate transparency and domain monitoring |
| Click | Visits to uncategorised or newly seen domains from mail clients; homograph domains; QR-delivered URLs opened on mobile | Secure web gateway, DNS, browser telemetry, mobile threat defence |
| Voice and chat | Inbound calls from flagged numbers; external Teams or chat contacts using "Help Desk" or "IT Support" names | Telephony call detail records; collaboration platform audit logs |
| Hand-over | Sign-in from new infrastructure shortly after a click; adversary-in-the-middle risk detection (attackerinTheMiddle in Entra ID Protection); the same session token used from two locations | Identity provider sign-in and risk logs |
| Use | New MFA method registered, OAuth app consented or connected app authorised, mailbox rules created, bulk API export | Identity provider audit logs, SaaS audit and event monitoring |
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
- 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.
- New MFA method after risky sign-in: a classic follow-on to harvested credentials and codes.
- OAuth or connected app consent by non-admins: especially after a call or chat; the ShinyHunters pattern.
- Look-alike domain registrations: brand plus identity provider terms, fed to takedown and to mail and web blocks.
- 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
| Control | Effect on T1598 | Limits |
|---|---|---|
| Phishing-resistant MFA (FIDO2, passkeys) | Harvested passwords and codes cannot complete a login on the attacker's proxy | Recovery and fallback methods must be equally strong. See the Phishing-Resistant MFA Guide |
| M1054 Software Configuration: DMARC, SPF, DKIM, honouring sender DMARC policies | Stops direct spoofing of your domains | Look-alike domains and compromised supplier mailboxes still pass |
| Mail and web filtering, URL rewriting, DNS protection | Removes known bad links and blocks newly seen domains | QR codes and voice bypass it |
| M1017 User Training plus verification processes | Second-channel checks for requests involving credentials, codes or payments | NCSC warns not to rely on training alone |
| Admin consent for OAuth and connected apps | A vishing victim cannot authorise a new app | Needs an approval process to avoid shadow workarounds |
| Limit public information | Fewer details for pretexts, especially about senior staff | NCSC suggests a digital footprint policy; cannot remove everything |
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
- Identify who interacted: message trace for all recipients, proxy logs for clicks, and user reports.
- Revoke, then reset: revoke sessions and refresh tokens first, then reset passwords and remove any newly registered MFA methods.
- Remove app grants: review and revoke OAuth consents and connected apps created in the window.
- Block infrastructure: sender, domains, URLs and phone numbers at mail, web, DNS and telephony layers; request takedown of look-alike domains.
- Hunt for use: mailbox rules, bulk exports, new devices and access to sensitive applications from the affected accounts.
- 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
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | T1598, T1598.001 to T1598.004; related T1589, T1585, T1586, T1684.001, T1684.002, T1564.008, T1027.006, T1539, T1557; contrast T1566 | Technique and neighbours |
| ATT&CK mitigations | M1017 User Training; M1054 Software Configuration | Mapped mitigations |
| NIST SP 800-53 Rev 5 | AT-2 Literacy Training and Awareness; IA-2 Identification and Authentication; SC-7 Boundary Protection; SI-4 System Monitoring; SI-8 Spam Protection | Control baseline |
| NIST CSF 2.0 | PR.AT-01 personnel awareness; PR.AA-03 users and services authenticated; DE.CM-03 personnel activity monitored | Outcomes |
| CIS Controls v8.1 | 9 Email and Web Browser Protections; 6 Access Control Management (MFA); 14 Security Awareness and Skills Training | Safeguards |
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