What is AI-powered phishing?
By Identra · Updated
AI-powered phishing uses AI to write, personalize or automate deceptive messages, calls or impersonations that trick people into handing over information, access or money. AI makes the lure more convincing, but the weakness it exploits is still a person trusting a request.
How does AI-powered phishing work?
The attacker uses a model to research the target, draft the lure, translate it and keep the conversation going. LinkedIn profiles, job posts and press releases supply the details. Delivery can be email, Slack, Microsoft Teams, SMS or a social DM.
Voice cloning and generated video help on calls. They don't have to be perfect. Urgency and a familiar approval process do most of the work.
Most lures mix human and generated text anyway. For the person reading one, 'was this written by AI?' leads nowhere. 'What is this asking me to do?' is the useful question.
How is AI-powered phishing different from ordinary phishing?
AI changes how the lure gets made. The compromise at the end looks the same. Spear phishing describes the targeting and AI-powered describes the tooling, so one campaign can be both.
Clean grammar proves nothing. Bad grammar was never a real control either. A correct reference to an internal project doesn't mean the sender is who they claim.
Writing the lure
- Conventional phishing
- Human-written or a reused template
- AI-assisted phishing
- Generated drafts, translations and variants
Personalization
- Conventional phishing
- Details picked by hand
- AI-assisted phishing
- AI helps pull in details about the target
Back-and-forth
- Conventional phishing
- Scripted or human replies
- AI-assisted phishing
- AI drafts or automates replies
What defenders do
- Conventional phishing
- Verify the request and protect access
- AI-assisted phishing
- The same, whoever wrote it
What does an AI-powered phishing attack look like?
Say an analyst in finance is working on an acquisition. An attacker uses the public deal news to write an email posing as the outside adviser. It asks the analyst to open a deal document and connect a 'secure review' app to their Microsoft 365 account.
The link lands on the real Microsoft sign-in page. The analyst approves an app that asks for mailbox access. That's consent phishing. A genuine Microsoft login page says nothing about whether the app behind the request is trustworthy. Microsoft's consent phishing guidance walks through it.
AI made the email believable. The damage came from the grant. An Entra ID admin consent workflow for sensitive permissions would have stopped it, and so would a call to the adviser's known number. Neither requires figuring out who wrote the email.
Where can a convincing phishing lure lead?
A fake login page collects passwords. An adversary-in-the-middle kit such as Evilginx relays the real login and grabs the session cookie, which makes one-time codes useless. Either way it ends in account takeover of mail, files and connected apps.
Device-code phishing uses the real sign-in page. The victim types an attacker's code at microsoft.com/devicelogin and signs the attacker in. Microsoft documented a campaign built on exactly this. Nobody should complete a sign-in for a device they aren't holding.
Some lures skip sign-in altogether. A fake CAPTCHA tells the user to press Win+R and paste a command. A cloned voice that sounds like the CFO asks for a wire.
How can organizations defend against AI-powered phishing?
Phishing-resistant MFA does the most. Passkeys and FIDO2 security keys bind the login to the real domain, so a lookalike site gets nothing it can replay. CISA's implementation guidance explains how.
It won't stop a consent grant, a pasted command or a wire transfer. Those need enterprise browser security, endpoint controls and finance procedures that hold even when the caller sounds right.
- Restrict user consent to apps and route sensitive permissions to admin review.
- Block the device-code flow where nobody needs it.
- Close weak fallback methods in account recovery.
- Verify payment changes and access requests through a number from the company directory.
- Make reporting one click. Run drills with QR codes, Teams messages and voice calls, as well as email.
- Keep accounts and apps on least privilege so one compromise doesn't reach everything.
What should responders do after someone takes the bait?
First find out what the person actually did. Opening an email, typing a password, approving an app and running a command are four different incidents. Keep the message, the URL, timestamps and the sign-in logs.
Reset the password and revoke sessions. A reset alone can leave a stolen cookie working, so treat session hijacking as its own question. Remove rogue app grants, newly added MFA methods and mailbox forwarding rules.
If they ran a command, the laptop needs a look. If money moved, call finance and the bank now.
How Identra thinks about it
Identra protects people in the browser from phishing pages, typosquatted domains and QR and device-code lures, flags fake-CAPTCHA pages that tell users to run commands, and steps in on Microsoft and Google OAuth consent screens. Security teams can revoke risky app grants and, with approval, sign-in sessions, and the result of each response is recorded.
Go deeper: Identra in the browser
Frequently asked questions
Can you tell whether a phishing message was written by AI?
Not reliably from the writing. Judge the sender, the link, the request and whether it fits how your business works.
Does MFA stop AI-powered phishing?
Phishing-resistant MFA protects the login against fake sites. It doesn't stop a fraudulent payment, a harmful app grant or a command someone chooses to run.
Does AI-powered phishing require a deepfake?
No. Often AI only drafts or translates the text. Voice and video impersonation are optional extras.
Is AI-powered phishing the same as prompt injection?
No. Phishing fools people. Prompt injection tries to manipulate an AI system through instructions hidden in content it reads.
Should incident responders prove AI was involved?
Not before containing it. Establish what the victim did, what access the attacker got and whether that access still works.