Incident response playbook:

Phishing investigation (part 1)

Start with
initial phishing email / Subject /
email address(es)

Get the list of users /

identities who got the email

Who else got/read the same

email?

Get timestamp when the

Is there delegated Is there a forwarding List of users / user / identity had access to
access to the mailbox? rule for the mailbox? identities the mailbox

Yes
Yes Investigate sign-in
To which user(s) is it events for the identity
delegated /
forwarded?

Stop / Remove the user /

Did the user read the
No identity off the potential
email? list

Did the email

Was there payload in Record hash
contain an Yes Yes
the attachment? / iOC
attachment?

No

A No

May 2021 © 2021 Microsoft Corporation. All rights reserved.

 Incident response playbook:
Phishing investigation (part 2)

Check email header for

Record the source IP Verify IP addresses to
the true source of the
address attackers/campaigns
sender

Record destination IP
Did the user click the
Yes address /
link in the email?
destination URL

No

On what endpoint(s) For each

Get Device ID
was the email opened? endpoint

Attachment was Get device

Yes Process creation event?
executed? investigation package

No

Perform device forensics

Was code Yes

Was the dest IP / URL
Yes downloaded /
touched/opened?
executed?

No

Investigate sign-in
events for the identity

Record time stamps, devices,

Investigate source IP
source IP addresses, app IDs, user- Identify device
address
agent string

Investigate each App ID App Investigation flow

May 2021 © 2021 Microsoft Corporation. All rights reserved.

 Incident response playbook:
Password spray
Incident trigger Are you federated?
No
Check Azure AD sign-in for failed
password attempts, extranet
lockout, authentication protocol
and identity protection for
password spray alert
Is password spray
attack confimed?
Yes
Collect any successful sign-ins
during this time and attacker IP
addresses*
Mitigation
Is the compromised Yes
password or
account identified?
Block IP address of attack on
Firewall, Azure AD and ADFS
Is legacy
authentication
blocked?
Yes
Is MFA enabled?
Yes
IP policies
enabled?
Yes
Is extranet No
lockout enabled?
Enable longer term
protections
May 2021
Check ADFS for an increase Note
Yes * Must locate successful password attempts
in failed passwod attempts
and/or extranet lockouts even if the "complete" login was unsuccessful.
For example, password was correct but MFA
challenge failed.
** Potential business impact
Collect any successful sign-
ins, IP addresses and
authentication protocols
used during the attack time
Is the IP address a
No known address or Yes Troubleshoot as per
another explanation for operational process
the alert?
No
Change user s password and Has the attacker
Follow procedure for
mark as compromised in successfully
data loss
identity protection accessed data?
No Block legacy
authentication **
No
Enable MFA
No Enable IP policies and
risk-based CA
Enable extranet lockout.
Threshold must be less than
on-prem
© 2021 Microsoft Corporation. All rights reserved.
 Incident response playbook:
App consent grant
​S igns of an
application consent
grant attack
Azure AD poral
Search for value "All
Principals" admin
consent tenant-wide.
No
Apps with
misspelled names,
bland names, or
hacker-sounding
names
Navigate to the Use PowerShell to revoke OAuth
affected user in the consent grant. Follow the steps
Azure AD portal. in Remove AzureAD
OAuth2PermissionGrant
cmdlets.
Select Applications >
Remove AzureADOAuth2Permissi
the suspicious app
onsGrant -ObjectId <string>
> Remove.
May 2021
​Inventory apps with
access using of these
three methods
PowerShell
AzureADPSPermissions.ps1
script output file
Run AzureADPSPermissions
script
Filter the results
on ConsentType (column
G)
Principals" user consent
Yes Yes
Look in column F, review
permissions for each
delegated application. Look
for review "read", "write",
"*.all" permissions.
Review users that have
consent granted. If high-
profile or high-impact users
have inappropriate consents
granted, then investigate
further.
Check ClientDisplayName
(column C) for apps that
seem suspicious.
Confirmed attack
Yes
Revoke application's
permissions using one of
these methods:
Use PowerShell to revoke
Service AppRole Assignment.
Follow the steps in
RemoveAzureADServiceAppRole
Assignment.
Remove AzureADServiceAppRole
Assignment -ObjectId <string>
Users enumerate
their app access
The AllPrincipals look for
high-risk impact
permissions​. See
aka.ms/consentperms
Search for value "All
No Stop
only applicable to the
user who consented.
Review apps with misspelled names, bland names,
hacker-sounding names
ISP investigation
- ReplyURL/RedirectURL
- Look for suspicious URLs ( Is the URL hosted on a
suspicious domain? Is the URL compromised, is it
recently registered? Is it a temporary domain?
- Is there a terms of service/agreement link in the
app registration? Is the content unique and
specific to the application/publisher?
- Is the tenant that registered the application
newly created or compromised? (for example, is
the app registered by an at-risk user?)
No
​Completed
investigation
Disable sign-in for the account, Disable integrated
which will disable app access to applications for your
data in that account. Not ideal for tenancy (Not
user, but useful for short-term recommended)
remediation.
Navigate to Admin
In the Azure AD portal,
Center>Settings>Org
select User > Profile > Settings,
settings>Services page,
and block sign-in.
select UserConsent to apps.
© 2021 Microsoft Corporation. All rights reserved.