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

Check ADFS for an increase Note

Yes * Must locate successful password attempts
Incident trigger Are you federated? 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

No

Check Azure AD sign-in for failed

password attempts, extranet Collect any successful sign-
lockout, authentication protocol ins, IP addresses and
and identity protection for authentication protocols
password spray alert used during the attack time

Is the IP address a
Is password spray No known address or Yes Troubleshoot as per
attack confimed? another explanation for operational process
the alert?

Yes
No

Collect any successful sign-ins

during this time and attacker IP
addresses*

Mitigation

Is the compromised Yes Change user s password and Has the attacker
Follow procedure for
password or mark as compromised in successfully
data loss
account identified? identity protection accessed data?

Block IP address of attack on

Firewall, Azure AD and ADFS

Is legacy No Block legacy

authentication
authentication **
blocked?

Yes

No
Is MFA enabled? Enable MFA

Yes

IP policies No Enable IP policies and

enabled? risk-based CA

Yes

Enable extranet lockout.

Is extranet No
Threshold must be less than
lockout enabled?
on-prem

Enable longer term

protections

May 2021 © 2021 Microsoft Corporation. All rights reserved.

 Incident response playbook:
App consent grant

​S igns of an ​Inventory apps with

application consent access using of these
grant attack three methods

Users enumerate
Azure AD poral PowerShell
their app access

The AllPrincipals look for

AzureADPSPermissions.ps1 high-risk impact
script output file permissions​. See
aka.ms/consentperms

Run AzureADPSPermissions
script

Filter the results

on ConsentType (column
G)

Search for value "All

Search for value "All
Principals" user consent
Principals" admin Yes Yes No Stop
only applicable to the
consent tenant-wide.
user who consented.

Look in column F, review

permissions for each
No delegated application. Look
for review "read", "write",
"*.all" permissions.

Review users that have Review apps with misspelled names, bland names,
consent granted. If high- hacker-sounding names
profile or high-impact users
have inappropriate consents ISP investigation
granted, then investigate - ReplyURL/RedirectURL
further. - 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?
Apps with - Is there a terms of service/agreement link in the
misspelled names, Check ClientDisplayName app registration? Is the content unique and
bland names, or (column C) for apps that specific to the application/publisher?
hacker-sounding seem suspicious. - Is the tenant that registered the application
names newly created or compromised? (for example, is
the app registered by an at-risk user?)

Confirmed attack No

Yes
​Completed
investigation
Revoke application's
permissions using one of
these methods:

Navigate to the Use PowerShell to revoke OAuth Use PowerShell to revoke Disable sign-in for the account, Disable integrated
affected user in the consent grant. Follow the steps Service AppRole Assignment. which will disable app access to applications for your
Azure AD portal. in Remove AzureAD Follow the steps in data in that account. Not ideal for tenancy (Not
OAuth2PermissionGrant RemoveAzureADServiceAppRole user, but useful for short-term recommended)
cmdlets. Assignment. remediation.

Navigate to Admin
Select Applications > In the Azure AD portal,
Remove AzureADOAuth2Permissi Remove AzureADServiceAppRole Center>Settings>Org
the suspicious app select User > Profile > Settings,
onsGrant -ObjectId <string> Assignment -ObjectId <string> settings>Services page,
> Remove. and block sign-in.
select UserConsent to apps.

May 2021 © 2021 Microsoft Corporation. All rights reserved.