Remediation and Hardening

white paper
Remediation and Hardening

Strategies for Microsoft 365
to Defend Against UNC2452
Version 1.0
WHITE PAPER | REMEDIATION AND HARDENING STRATEGIES FOR MICROSOFT 365 TO DEFEND AGAINST UNC2452 2
Table of Contents
Overview..................................................................................................................................................... 3
Background........................................................................................................................................ 3
Goals and Objectives...................................................................................................................... 3
Attacker Tactics, Techniques and Procedures (TTPs)............................................................. 4
Remediation Strategy........................................................................................................................... 4
Remediation Sequencing.............................................................................................................. 5
AD FS Attack Mitigation...................................................................................................................... 6
Attack Technique: Golden SAML Attack........................................................................................7

Active Directory Federation Service Overview.....................................................................7
Technique............................................................................................................................................ 9
Remediation......................................................................................................................................10
Hardening........................................................................................................................................... 11
Detection............................................................................................................................................18
Microsoft 365 Attack Mitigation......................................................................................................19
Attack Technique: Modify Trusted Domains..............................................................................20

Azure AD Federated Domains Overview.............................................................................20
Technique..........................................................................................................................................20
Detection...........................................................................................................................................20
Remediation..................................................................................................................................... 23
Attack Technique: Abuse Azure AD Privileged Roles...........................................................24

Azure Active Directory Privileged Roles Overview..........................................................24
Technique..........................................................................................................................................24
Remediation.....................................................................................................................................24
Attack Technique: Hijack Azure AD Applications...................................................................26

Azure Applications and Service Principals Overview......................................................26
Technique.......................................................................................................................................... 27
Detection........................................................................................................................................... 27
Remediation.....................................................................................................................................29
Microsoft 365 Hardening.................................................................................................................... 31
Conclusion................................................................................................................................................39
Overview
Background
In December 2020, FireEye uncovered and publicly disclosed a
widespread campaign conducted by the threat group we track
as UNC2452. In some, but not all, of the intrusions associated
with this campaign where Mandiant has visibility, the attacker
used their access to on-premises networks to gain unauthorized
access to the victim’s Microsoft 365 environment.
Goals and Objectives

UNC2452 and other threat actors have used several methodologies
to move laterally from on-premises networks to the cloud,
specifically Microsoft 365. This paper will help organizations
understand these techniques used by UNC2452, how to proactively
harden their environments, and how to remediate environments
where similar techniques have been observed.
It is important to note that there is no formal security boundary

between on-premises networks and cloud services provided by
Microsoft 365. If an organization discovers evidence of targeted
threat actor activity in their on-premises network, a thorough
review of the cloud environment is often necessary as well.
Organizations can use the Azure AD Investigator auditing

script, available from the FireEye GitHub repository, to
check their Microsoft 365 tenants for indicators relative to the
techniques detailed throughout this paper. The script will alert
administrators and security practitioners to artifacts that may
require further review to determine if they are truly malicious or
part of legitimate activity.
Attacker Tactics, Techniques

and Procedures (TTPs)
Mandiant has observed UNC2452 and other threat actors moving laterally to the Microsoft 365 cloud using a
combination of four primary techniques:
1. Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for
arbitrary users (sometimes described as Golden SAML). This would allow the attacker to authenticate into a
federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their
corresponding multi-factor authentication (MFA) mechanism.
2. Modify or add trusted domains in Azure AD to add a new federated Identity provider (IdP) that the attacker controls. This
would allow the attacker to forge tokens for arbitrary users and has been described as an Azure AD backdoor.
3. Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 and are assigned high
privileged directory roles, such as Global Administrator or Application Administrator.
4. Hijack an existing Microsoft 365 application by adding a rogue credential to it in order to use the legitimate permissions
assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc.,
while bypassing MFA.
Remediation Strategy
Developing a successful strategy to eradicate UNC2452 access to a victim’s environment is contingent upon many factors, so
each organization must develop their own unique plan. Two of the most important factors are the actions taken by the attacker
and the specifics of the victim’s environment.
To help victims plan their own strategy, Table 1 provides a high-level overview of techniques related to Microsoft 365 with links
to corresponding remediation and hardening steps.
Table 1. Overview of covered TTPs.
Technique MITRE ATT&CK Remediation Hardening
Attack Technique: TA0006 Step 1: Issue new AD FS Certificates Step 1: AD FS Service Account – Best Practices
Golden SAML Attack T1552
Step 2: Revoke Microsoft 365 Refresh Tokens Step 2: AD FS Logging and Auditing
T1552.004
T1199 Step 3: AD FS Servers - Account Access
Restrictions and Inbound Connectivity
Hardening
Step 1: Review Configured Domains and

Attack Technique:
T1550 Trusts Within Microsoft 365 and
Modify Trusted Domains Step 1: Filter accounts synced to Azure Active
Remove Untrusted Domains
Directory
Step 1: Review and Configure Cloud-Only Step 2: Limit Privileged Users to Trusted IPs
Accounts for Privileged Role Holders
Attack Technique: Step 3: Enhance Mailbox Auditing
TA0006 Step 2: Rotate All Passwords for Cloud-Only
Abuse Azure AD
T1552 Accounts Step 4: Review Azure Application and Service
Privileged Roles
Step 3: Invalidate Refresh Tokens for Each Principal Permissions
Cloud-Only Account
Step 5: Enforce multi-factor authentication
(MFA) for Accounts
Attack Technique: T1114 Step 1: Review and Remediate Keys
Hijack Azure AD T1114.002 Associated with Service Principals and Step 6: Review all registered MFA devices
Applications T1098.001 Applications
Step 7: Review Partner (Cloud Service
Step 2: Invalidate All Existing Refresh Tokens
Provider) Relationships
Remediation Sequencing 3. Rotate impacted on-premises credentials,

Timing and sequencing are critical for the successful which could include:
execution of a remediation plan, especially if an attacker a. Rotating the Kerberos ticket granting ticket account
remains active during the containment and eradication (krbtgt) credentials (twice)
timeframes. To maximize the probability of fully
eradicating this threat actor from hybrid Microsoft 365 b. Rotating credentials for “Tier-0” accounts in Active
environments, Mandiant recommends sequencing the Directory
remediation plan to: c. Rotating credentials and/or disabling compromised
accounts
• First, regain control of the on-premises environment.
This environment houses and protects the various d. Rotating credentials for other Active Directory
secrets that attackers often abuse to gain initial access accounts
and attack cloud environments. e. Rotating credentials for local administrator accounts
• Next, rotate secrets and credentials to regain control f. Rotating credentials for cloud connector accounts
of the Microsoft 365 environment and fully eradicate all
attacker access. i. On-premises Azure AD DS connector account
ii. Azure AD connector account

To accomplish these two goals, consider executing a plan
similar to the following, in order of operation. For actions iii. On-premises ADSync Service Account (that runs
directly related to the attacker techniques discussed in AD Connect services on servers)
this white paper, we included internal jump links to more iv. If Azure seamless single sign-on is utilized,
detailed instructions. For remaining actions, we have linked rotate the decryption key for the on-premises
to public sources where appropriate: AZUREADSSOACC computer account
1. Implement short term hardening measures to mitigate g. Rotating other internal credentials or secrets
risk of similar attacks
4. Rotate the AD FS token-signing and token-decrypting
2. Eliminate any attacker remote access to the certificates used with SAML tokens (twice)
on-premises environment, which could include:
5. Rotate credentials for impacted cloud accounts
a. Implementing network blocks and DNS sinkholes
b. Removing remote access backdoors, including 6. Remove attacker created identity providers and
impacted SolarWinds software custom domains
c. Un-enrolling attacker multi-factor authentication
7. Remove attacker certificates and passwords from
(MFA) tokens applications and service principals
d. Rotating secrets associated with remote access MFA
token generation 8. Revoke all existing refresh tokens for Microsoft 365
Note: this will force all users to re-enter their credentials
to utilize Microsoft 365 services through clients such as
Outlook and Teams.
AD FS Attack Mitigation
ATTACK TECHNIQUE:
Golden SAML Attack

Active Directory Federation Service Overview In this authentication scheme, two vital pieces of data
Active Directory Federation Services (AD FS) provides are the digital signature and the ImmutableID. The
an on-premises authentication workflow for cloud-based ImmutableID is a globally unique identifier (GUID)
resources. While other authentication workflows also associated with a user and stored in Azure Active
exist, AD FS is a popular option for enterprises that want Directory (Azure AD). A copy of this GUID is also stored
to maintain control of their own authentication. In this in the on-premises Active Directory as the ms-DS-
workflow, AD FS is an Identity Provider (IdP) because ConsistencyGuid attribute of the User object.
it facilitates user identity information to cloud-based This attribute is viewable by any authenticated user in
resources and applications. both Azure AD and on premises AD.
Microsoft AD FS uses a “claim-based” identity model The foundation of the security of AD FS is the
to identify roles, permissions, or groups associated confidentiality of the token-signing certificate, which is
with a user authentication. A claim can be any piece of used to digitally sign SAML tokens issued by the AD FS
information about the requesting user’s identity, such as a service. Exposure of the token-signing certificate and
group they belong to, or whether an MFA authentication private key, paired with any compromised AD account (to
was performed during login. For example, if MFA query users’ ImmutableIDs), would allow an attacker to
occurred during the AD FS login, then the claim shown in issue their own forged but verifiable SAML tokens. Taking
Figure 1 would be provided by AD FS. it a step further, a one-time extraction of all ImmutableIDs
and the token-signing certificate with private key would
Multiple claims associated with the authentication are allow the attacker to issue SAML tokens for any user in
packaged into an XML document, known as a SAML token, the organization regardless of their password and any
and digitally signed to ensure verifiability and to prevent password resets that occur afterwards. The attacker
unauthorized modification. When Microsoft 365 receives can insert any claim they want into the SAML token.
a SAML token issued by an AD FS service, it performs This could include the claim detailed in Figure 1, which
the following steps to ensure its validity before providing states that the user performed MFA at the AD FS service.
access to the resource (listed in no particular order): This forged SAML token will bypass MFA requirements
imposed by the cloud application.
• Verify that the digital signature of the SAML token is
valid and uses a known keypair The locations of the token-signing certificate and private
• Verify the SAML token is constructed properly and key depend on how an organization has chosen to
complies with the standard implement AD FS. On-premises AD FS infrastructure
can consist of either a single or multiple AD FS servers,
• Verify that the SAML token has not expired
a database instance, and either single or multiple AD FS
• Verify that the token was issued by a source that web application proxy server(s) housed in a DMZ (Figure
Microsoft 365 expects (the issuer) 2). Most organizations will likely leverage an AD FS server
• Verify that the unique identifier for the user (the farm, using a local Windows Internal Database (WID).
ImmutableID) matches a user in Azure AD
• Evaluate conditional access policies, if any
Figure 1. <saml:AttributeValue>http://schemas.microsoft.com/claims/multipleauthn</
Example SAML claim
saml:AttributeValue>
for Microsoft 365.
Figure 2.
https://docs.
microsoft.com/
en-us/windows-
server/identity/ad- NLB NLB
fs/deployment/
best-practices- Firewall Firewall
securing-ad-fs Active AD FS Web
Directory Application
Proxy
INTRANET DMZ
In the default installation of AD FS, the token-signing This data is stored within an Active Directory
certificate is automatically generated and valid for one attribute CN=ADFS,CN=Microsoft,CN=Program
year. The AD FS service will handle the certificate rollover Data,DC=<domain>,DC=<suffix>. In addition to
process. The following points detail how the token-signing obtaining the token-signing certificate, an attacker
certificate is stored on the AD FS server: would also need to obtain the value from Active
Directory for decrypting the token-signing certificate. By
• The token-signing certificate is stored as a base64 default, this value is only readable by the AD FS service
encoded encrypted blob within the database used by account and Domain Administrators.
the AD FS servers.
Note: If multiple AD FS certificate containers are
• The token-signing certificate is protected using a present in Active Directory, from an AD FS server,
Windows technology called Distributed Key Manager the PowerShell command (Get-AdfsProperties).
(DKM). AD FS uses a key derivation function to CertificateSharingContainer can be used to identify the
derive an AES key that is used to decrypt the token- container that will be used by DKM.
signing certificate stored in the AD FS database.
Figure 3.
Active Directory -
AD FS Container
Attributes.
The AD FS service also makes use of other certificates that First, the attacker must obtain the encrypted token-
are out of scope for this whitepaper. For example, each signing certificate. The threat actor has used a number
cloud application can define a token-decrypting certificate, of techniques to extract the encrypted blob from the
which is used to encrypt the SAML token as it is transmitted IdentityServerPolicy.ServiceSettings table. Mandiant has
to the cloud resource. This option is not widely used. observed techniques including:
Note: If an AD FS server farm model is leveraged, the • Stealing the backup files for the database: Connecting
same token-signing and decryption certificates are used to the server via SMB and copying the database file
by all the AD FS servers. AdfsConfiguration.mdf off the server
• Querying the database via PowerShell: Connecting to
The default configuration for AD FS uses a built-in MSSQL
the server to execute PowerShell that then connects to
database service called Windows Internal Database (WID).
and queries the WID service for the table rows.
The WID service is only accessible from the local host via
a specific named pipe and does not listen on the standard – SELECT ServiceSettingsData from
TCP port 1433. IdentityServerPolicy.ServiceSettings
• Querying the database via custom executable:
The WID service stores the backing files for the AD FS
Writing a custom executable to disk and executing it.
database in the following locations:
The executable queried the WID for the table row and
• C:\Windows\WID\Data\AdfsConfiguration.mdf wrote the output to disk.
• C:\Windows\WID\Data\AdfsConfiguration_log.ldf Next, the attacker must obtain the secret DKM value from
Active Directory to decrypt the token-signing certificate.
A default configuration of AD FS using the WID service will
Mandiant has observed the threat actor using open-source
generate a database table named IdentityServerPolicy.
tools such as ADFind to query Active Directory for the
ServiceSettings to store the token-signing certificate.
DKM value used to decrypt the encrypted token-signing
Technique certificate. Figure 4 details an ADFind query used by
Once UNC2452 had gained on-premises access to an UNC2452 to obtain this value.
organization’s environment, Mandiant observed them
With the certificate and DKM value, the attacker now has
targeting on-premises AD FS servers with the goal of
the data they need to forge SAML tokens and access
obtaining the token-signing certificate to forge SAML
cloud-based resources, while bypassing MFA requirements
tokens. There are two steps an attacker must take to
and the need to know a user’s password (GoldenSAML).
obtain the token-signing certificate and private key.
Figure 4. C:\Windows\system32\cmd.exe /C c:\windows\temp\srv.exe -h -sc fo:* -b

“CN=ADFS,CN=Microsoft,CN=Program Data,DC=acme,DC=com”
ADFind command
to query the secret
DKM value.
Remediation certificate will still be resident in Azure AD, and can

If an attacker is able to connect to an on-premises AD FS still be used to forge SAML tokens. To fully ensure
server and has credentials for either the service account that only new and trusted certificates are available,
that runs the AD FS service or an account that has local a “double-tap” is required.
administrative permissions on AD FS servers, this provides 2. Immediately revoke all existing refresh tokens for the
the threat actor with the access needed to extract the Microsoft 365 tenant.
token-signing certificate.
Step 1: Issue new AD FS Certificates
If an organization suspects an attacker has accessed their AD Note: The certificate rollover will temporarily impact single
FS token-signing certificate, two critical steps are required to sign-on communications with applications that use AD FS
remediate and protect against a GoldenSAML attack. as an IdP.
1. Issue new certificates on the AD FS server(s) and
To view the properties related to the AD FS certificates,
synchronize them to Azure AD (and any other cloud reference the PowerShell commands noted in Figure 5.
applications that use AD FS for authentication).
• Rotate the token-signing AD FS certificate in rapid To rotate the AD FS token-signing and token-decrypting
succession twice. certificates using PowerShell, the commands noted in
Figure 6 can be utilized. The commands must be run
• By default, if the certificate is only rotated once,
from the primary AD FS server (if an AD FS server farm is
a copy of the previous (potentially compromised) utilized).
Figure 5.
Get-ADFSCertificate -CertificateType Token-Signing
Command to Get-ADFSCertificate -CertificateType Token-Decrypting
review the
properties of AD
FS certificates.
Figure 6. ** 1st Iteration **

Commands to
rotate AD FS Set-ADFSProperties -AutoCertificateRollover $true
token-signing and
token-decrypting Update-AdfsCertificate -CertificateType Token-Decrypting -Urgent
certificates. Update-AdfsCertificate -CertificateType Token-Signing -Urgent
Set-ADFSProperties -AutoCertificateRollover $false
Connect-MSOLService
Get-MSOLFederatedProperty -DomainName <domain>
Update-MSOLFederationDomain -DomainName <domain>
** 2nd Iteration **
Set-ADFSProperties -AutoCertificateRollover $true
Update-AdfsCertificate -CertificateType token-signing

Update-AdfsCertfiicate -CertificateType token-decrypting
Set-ADFSProperties -AutoCertificateRollover $false
Connect-MSOLService
Update-MSOLFederationDomain -DomainName <domain>
Once completed, ensure that the output from the Get -MSOLFederatedProperty -DomainName command only includes
the certificate thumbprints and validity dates that match the recently rotated certificates, and that the certificate
thumbprint from the previously (potentially compromised) certificates are not present in Azure AD.
If an organization maintains backup copies of the token-signing and token-decrypting certificates, the certificate backups
should not be stored on the local AD FS servers and should be secured and password-protected using a separate
enterprise vaulting / backup-storage technology (preferably offline storage).
Step 2: Revoke Microsoft 365 Refresh Tokens

After rotating the AD FS certificates, organizations should immediately revoke all existing refresh tokens for their
Microsoft 365 tenant. While this will result in users being required to reauthenticate, this is a prudent step to ensure
that all logged in users authenticate to Microsoft 365 using the new and trusted SAML tokens. Using an account that
has Microsoft 365 Global Administrator permissions, the commands noted in Figure 7 can be used to invalidate
existing refresh tokens.
Figure 7. Connect-AzureAD
PowerShell commands to Get-AzureADuser -all $true | Revoke-AzureADUserAllRefreshToken
connect to Azure AD and
revoke existing refresh tokens.
Hardening
Proactive hardening steps can be leveraged to secure on-premises AD FS infrastructure. While the scope of
generalized on-premises hardening workstreams can be cumbersome and often represent multiple layers of defenses,
the most prudent steps related to AD FS hardening and mitigating the previously noted attacker techniques are
noted below.
• Step 1: Configure a Group Managed Service Account (gMSA) for AD FS services
– Alternatively, configure a dedicated on-premises account that is only leveraged as an AD FS service account and has
restricted access rights
• Step 2: Review AD FS Logging and Auditing Settings
• Step 3: Review Account and Network Access Restrictions for AD FS Servers
Step 1: AD FS Service Account – Best Practices

• Since AD FS v3.0 (Windows Server 2012 R2+), a group managed service account (gMSA) can be configured for running
AD FS services. The benefits of leveraging a gMSA include a complex (120 character) password that is automatically
managed and rotated on a pre-defined frequency (30 days by default). For additional information, reference https://
docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/configure-a-federation-server.
• If a gMSA cannot be leveraged, a dedicated (non-privileged) service account should be created in Active Directory
for running AD FS services. This account should not be used on any additional systems or services. Additionally, the
account should be configured with a strong (> 25 character) password and rotated on a periodic basis. For additional
information, reference https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/manually-
configure-a-service-account-for-a-federation-server-farm.
Note: If an organization needs to change the existing AD FS service account to leverage a gMSA (rather than a
static service account), this process can be complex and may require assistance from Microsoft support. For specific
information related to this process, reference:
• https://gallery.technet.microsoft.com/scriptcenter/Active-Directory-ddb67df0
• https://social.technet.microsoft.com/Forums/windowsserver/en-US/8f558762-f92c-4803-916c-cc36ecc7c988/adfs-
2016-change-service-account-to-gmsa?forum=ADFS#75f9b050-ad0b-461a-92a4-796180d6c6d2
• https://github.com/Microsoft/adfsToolbox/tree/master/serviceAccountModule
Step 2: AD FS Logging and Auditing

AD FS utilizes two primary event logs on servers that Figure 8. AD FS audit logs.
run AD FS services: Admin log and Tracing/Debug log.
With the default settings, the AD FS service registers

its own Windows event log group called “AD FS”. The
“Admin” event log in this group records high-level events
related to the AD FS service status, service requests
and overall service health. If debug logging is enabled,
an additional Windows event log group called “AD FS
Tracing” will be present—housing the “Debug” event log.
Note: Mandiant does not recommend enabling debug

logging unless there is a specific need to perform
troubleshooting for AD FS services. Enabling debug
logging will generate a large volume of events in a
short timeframe, and can greatly impact operational
performance of the AD FS server(s).
Organizations can verify their current AD FS audit level by

using the Get-AdfsProperties PowerShell cmdlet. AD FS
logging levels can be configured and adjusted using the
Set-AdfsProperties PowerShell cmdlet.
Note: For an AD FS server farm, any changes to AD FS

audit levels will need to be configured on each server
within the farm.
For AD FS services running on Windows Server 2012R2,

there are six configurable audit levels:
• Errors
• FailureAudits
• SuccessAudits
• Information
• Verbose
• Warnings
Mandiant’s recommended settings for configuring the Enable AD FS Security and Service Account Auditing
audit level for AD FS services running on Windows Server In addition to audit levels, Mandiant recommends enabling
2012R2 are shown in Figure 9. security auditing in AD FS. Security auditing provides
visibility to authentication events performed through the
For AD FS services running on Windows Server 2016+, AD FS service, including issued claims, security token
there are three configurable audit levels: validation failures, IP addresses for requests and user
agent information. By default, both “Success audits” and
• Basic (default): no more than 5 events will be logged
“Failure audits” are not enabled, which can severely affect
for a single request
monitoring and investigative efforts.
• Verbose: all events will be logged
To enable security auditing for AD FS events, implement
• None: auditing is disabled (not recommended)
the following steps:
Mandiant’s recommended settings for configuring the
1. On each AD FS server - Navigate to Local Security
audit level for AD FS services running on Windows Server
Policy > Security Settings > Local Policies > User Rights
2016+ is shown in Figure 10.
Assignment > Generate security audits (Figure 11)
Note: While Mandiant’s recommendation of including • Local Security Setting tab > verify that the AD FS
Verbose auditing will provide the most information related service account is listed. If not listed, add the account.
to AD FS events, this setting will likely cause event logs
to rotate faster and should be utilized in conjunction with
event log forwarding to a SIEM.
Figure 9. Set-AdfsProperties -LogLevel

Errors,FailureAudits,Information,Verbose,SuccessAudits,Warnings
Recommended AD FS audit
level for AD FS services on
Windows Server 2012R2.
Figure 10. Set-AdfsProperties -AuditLevel Verbose

Recommended AD FS audit
level for AD FS services on
Windows Server 2016+.
Figure 11.
Local Security Policy -
Generate Security Audits
configuration.
2. To record audits generated by the AD FS service within the Security event log, on each AD FS server - Navigate to
Local Security Policy > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Object
Access
• Audit Application Generated tab > Select both “Success” and “Failure” (Figure 12)
• This can also be accomplished using an elevated command prompt, and running the command noted in Figure 13.
Figure 12.
Local Security Policy – Audit
Application Generated
configuration.
Figure 13. auditpol.exe /set /subcategory:”Application Generated” /

failure:enable
Command to enable AD FS
service account auditing. /success:enable
3. For the AD FS Server Farm – navigate to Start >

Programs > Administrative Tools, > AD FS Management Figure 14. Federation Service Properties - Recommended
Auditing Actions (per AD FS Farm).
• Actions pane > Edit Federation Service Properties
• Federation Service Properties > Events tab
– Select Success Audits and Failure Audits

(Figure 14)
Note: Enabling AD FS service auditing can increase

the volume of events logged on AD FS servers. It is
recommended that events captured within event
logs on AD FS servers be forwarded to a SIEM, for
enhanced correlation and offline storage for historical
review purposes.
Once AD FS auditing is configured, any successful

changes to the AD FS service configuration will result in
Event ID 307 (ConfigurationChangeSuccessAudit) or
Event ID 309 (WmiConfigurationChangeSuccessAudit)
being recorded within the Security event log on the AD
FS server(s). For correlation, Event ID 510 will contain
additional information related to the configuration
changes that were enforced (Figure 15).
Figure 15. Event IDs related to AD FS configuration setting modifications.
For additional information related to AD FS logging and auditing—in addition to specific Event IDs (per Operating
System platform) which can be leveraged for troubleshooting and investigative purposes, reference:
https://adfshelp.microsoft.com/AdfsEventViewer/GetAdfsEventList
Enable Domain Auditing for AD FS Distributed Key Manager Access Requests

The DKM secret value is required to decrypt the AD FS token-signing certificate and is stored in Active Directory.
The Active Directory container should only be accessed periodically by the AD FS service account and AD FS service
process. To detect anomalous access requests targeting the AD FS Distributed Key Manager (DKM) container in Active
Directory, the following monitoring should be configured.
1. On Domain Controllers, ensure that the “Audit Directory Service Access” subcategory (within the “DS Access”
category) is configured for auditing. This configuration can be enforced using settings defined within a Group Policy
Object (GPO) linked to Domain Controllers (Figure 16).
2. Ensure that auditing for “Read All Properties” is configured for the CN=ADFS,CN=Microsoft,CN=Program
Data,DC=<domain>,DC=<suffix> parent (and child) containers in Active Directory. This can be accomplished using
ADSIEdit (Figure 17).
Figure 16.
GPO configuration example
for enforcing “Directory
Service Access” auditing for
Domain Controllers.
Figure 17.
Configuring auditing for
the ADFS container using
ADSIEdit.
3. Within Security event logs on Domain Controllers, monitor for Event ID 4662. Targeted monitoring related to EID 4662
events for potential DKM access include:
• ObjectName contains the GUIDs of the AD FS DKM Containers for the token-signing and token-decrypting
certificates (can be found using ADSIEdit and navigating to CN=ADFS,CN=Microsoft,CN=Program
Data,DC=<domain>,DC=<suffix>)
• ObjectName contains the path of CN=CryptoPolicy,CN=ADFS,CN=Microsoft,CN=Program
Data,DC=<domain>,DC=<suffix>
Figure 18. Example Event ID 4662 - recorded when accessing the DKM container in AD using PowerShell.
Note: When an AD FS server is rebooted or the AD FS additional correlation on AD FS servers related to the
service is restarted, the service account legitimately detections noted above can be leveraged, including:
running AD FS services will access the containers in
Active Directory for certificate decryption using DKM. To • System Event Log - Event ID 7036
further enhance monitoring and reduce false positives, • System Event Log – Event ID 1074
Figure 19.
System Event Log - Event ID
7036.
Figure 20.
System Event Log - Event ID
1074.
Step 3: AD FS Servers - Account Access Restrictions and In addition to authentication considerations, inbound
Inbound Connectivity Hardening access to AD FS servers should be restricted to the
On-premises AD FS servers should be considered Tier following small subset of ports / protocols required for
0 assets. Mandiant recommends restricting access to inbound connectivity (Figure 21).
the AD FS servers to an even smaller subset of unique
accounts than the typical “Domain Administrators” group. • TCP/80 (HTTP)
Furthermore, Mandiant recommends that the accounts • TCP/443 (HTTPs)
in this subset are explicitly prevented (via Group Policy)
• TCP/5985 (WinRM)
from authenticating to Tier 1 and Tier 2 assets, to prevent
their credentials from being potentially recoverable on less • TCP/808 (Windows Server 2012R2) or
secure systems. Particular attention should also be paid TCP/1501 (Windows Server 2016+)
to the local administrator account on the AD FS system,
ensuring that its password is strong and unique.
Figure 21. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs
AD FS Required Ports and Protocols
Protocol Port (TCP/UDP) Description
HTTP 80 (TCP/UDP) Used to synchronize

with Azure AD
HTTPS 443 (TCP/UDP) Used to synchronize

with Azure AD
Configure, Sync Sync

Azure
On-premise Azure AD Active
Active Directory Connect Server Directory SaaS
TCP/80 Your Apps Applications
TCP/443
TCP/5985
Port 808 (Windows

Server 2012R2) or
Port 1501 (Windows
Server 2016+) is the Sign-on Sign-on
Net.TCP port AD FS
uses for the local WCF
endpoint to transfer Protocol Port (TCP/UDP) Description Protocol Port (TCP/UDP) Description
configuration data to HTTPS 443 (TCP/UDP) Used for authentication HTTPS 443 (TCP/UDP) Used for device User Devices
the service process AD FS Web authentication
and Powershell Application
TCP 49443 (TCP) Used for device
Proxy authentication
Common ports leveraged for lateral movement can be Detection

restricted (inbound) for AD FS servers using a Windows Detection of forged SAML tokens actively being used
Firewall configuration. Administrative connectivity and against an organization has proven to be difficult. One
access to AD FS and AD Connect servers should only possibility is to compare entries in the Azure AD Sign-Ins
be initiated from dedicated Tier 0 Privileged Access log against the security event logs of the on-premises AD
Workstations (PAWs) or hardened jump hosts and can be FS servers to ensure that all authentications originated
defined as exceptions within Windows Firewall rulesets. from AD FS. Technically, every sign-in recorded in Azure
Ports where inbound connectivity on AD FS servers should AD will have a corresponding event in the on-premises
be restricted using Windows Firewall rules include: security event logs. However, in real-world environments,
this exercise is impractical for most organizations due to a
• Predefined Windows Firewall Rule: File and Print Sharing variety of reasons:
– TCP/445, TCP/135 - TCP/139 (SMB)
• Sign-ins in Azure AD may not be recorded for up to 24
• Predefined Windows Firewall Rule: Remote Desktop hours after the event occurs
– TCP/3389 (RDP) • One sign-in may generate multiple sign-in records in
• Predefined Windows Firewall Rule: Windows Azure AD
Management Instrumentation (WMI) • One sign-in may generate multiple security event log
– Multiple ports events on the AD FS server
• Time skew between multiple systems
For specific Windows Firewall rule configurations that
can be leveraged to restrict inbound access to these • Event log retention
ports, reference:
Other resources have also suggested looking for
https://www.fireeye.com/content/dam/fireeye-www/
anomalous attributes in the SAML tokens themselves.
current-threats/pdfs/wp-ransomware-protection-and-
Mandiant has observed UNC2452 using non-standard
containment-strategies.pdf.
claims in the forged SAML tokens, as well as extending the
lifetime of the forged SAML tokens beyond the standard
one hour. These attributes are not visible to customers in
the Azure AD sign-in logs to be used for detection.
To detect the use of forged SAML tokens, organization

should instead focus on traditional logon analysis
techniques. Microsoft’s Cloud Application Security and
Azure AD portal’s “Azure AD risky sign-in” reports can
be useful to identify sign-in events from anonymous
VPN providers and infrequently used devices or
locations. Impossible travel events can also help identify
suspicious logons.
Organizations with Sysmon or other process and

command auditing tools installed on AD FS servers may
be able to identify suspicious connections to the AD FS
WID from unexpected processes.
Microsoft 365 Attack Mitigation

ATTACK TECHNIQUE:
Modify Trusted Domains

Azure AD Federated Domains Overview A threat actor could also modify the federation settings
Similar to on-premises Active Directory, Azure AD uses the for an existing domain by configuring a new, secondary,
concept of “domains” to manage directories of identities. token-signing certificate. This would allow for an attack
By default, an Azure AD instance will represent a single (similar to Golden SAML) where the threat actor controls a
domain that is commonly called the “cloud-only” or private key that is able to digitally sign SAML tokens and is
“onmicrosoft” domain. The domain’s name will be in the trusted by Azure AD.
form of <domain name>.onmicrosoft.com.
Both of these techniques would allow the threat actor to
For a user’s email address to match the organization’s authenticate to Microsoft 365 as any user—bypassing the
domain name (such as fireeye.com), an organization requirement to leverage a valid password for the account
must add their registered domain to Azure AD and prove and perform MFA.
ownership. If the organization intends to use a third-
party identity provider such as AD FS for authentication, A more detailed discussion of this attacker technique can
the domain must then be configured as federated and a be found in the FireEye blog post, “Detecting Microsoft 365
federated realm object will be created. The federated realm and Azure Active Directory Backdoors.”
object tracks information such as the URL for the federated
Detection
login page, the URL for the federation metadata, and the
The Azure AD Audit log and Unified Audit log records
public portion of the token-signing certificate that Azure AD
when a domain is configured for federated authentication
will use to validate digitally signed SAML tokens it receives.
and the modification of federated realm objects. In most
Any verified domain can be configured as a federated
organizations, domain federation settings will be updated
domain. Importantly, a SAML token issued by a federated
infrequently. Organizations should create rules to alert
domain can be used to authenticate users that belong to
on the log events generated by these activities and audit
any of the configured domains in the Microsoft 365 tenant.
them to ensure they are legitimate.
Technique
Figure 22 shows a sample event from the Unified Audit Log
The threat actor must first compromise an account with
that is recorded when a new domain is federated resulting
permission to modify or create federated realm objects.
in the creation of a federated realm object. This event
Accounts with the “Global Administrator” or “Hybrid
records the user that performed the action and the source IP
Identity Administrator” role can perform this action.
address, in addition to important details about the federated
Global Administrators, in particular, can also add new
realm object itself. Outside of traditional analysis techniques
domains and configure them for federation. In an earlier
such as user activity and IP address analysis, organizations
investigation of suspected UNC2452 activity, Mandiant
should pay attention to the IssuerUri value. This value
observed connections to a Microsoft 365 tenant with
records the address of the IdP that is configured to issue
MSOnline PowerShell followed by the configuration of a
SAML tokens. The address should match an expected value,
new, attacker-controlled domain as federated.
such as the organization’s AD FS server.
Figure 22.
{
Event recorded
when a new “OrganizationId”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
domain is “CreationTime”: “2020-06-23T23:03:32.0000000Z”,
federated, and a “RecordType”: 8,
federated realm “Operation”: “Set domain authentication.”,
object is created.
“UserType”: 0,
“Workload”: “AzureActiveDirectory”,
“ClientIP”: “1.1.1.1”,
“Version”: 1,
“UserId”: “doug@victim.onmicrosoft.com”,
“ObjectId”: “Not Available”,
“ResultStatus”: “Success”,
“ModifiedProperties”: [
{
“Name”: “IssuerUri”,
“NewValue”: “[\r\n \”http://any.sts/16B45E3B\”\r\n]”,
“OldValue”: “[]”
},
{
“Name”: “Included Updated Properties”,
“NewValue”: “IssuerUri,LiveType”,
“OldValue”: “”
},
{
“Name”: “LiveType”,
“NewValue”: “[\r\n \”Federated\”\r\n]”,
“OldValue”: “[\r\n \”Managed\”\r\n]”
}
],
}
Figure 23 shows a sample event recorded in the Unified the user that performed the action, the IP address the
Audit Log when an existing federated realm object for action was performed from, as well as the domain that
a domain is modified. In most organizations, domain was modified. It does not record what elements of the
federation settings will be updated infrequently. federated realm object were modified. Additional analysis
Organizations should create rules to alert on the log using MSOnline PowerShell (detailed in the hardening and
events that get generated by these activities and audit remediation sections) will be needed to identify whether
them to ensure they are legitimate. The event records the signing-certificate was modified.
Figure 23.
{
Event recorded
“OrganizationId”: “ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx “,
when an existing
federated realm “CreationTime”: “2020-12-04T18:41:45.0000000Z”,
object is modified. “RecordType”: 8,
“Operation”: “Set federation settings on domain.”,
“UserType”: 0,
“ClientIP”: “1.1.1.1”,
“Version”: 1,
“UserId”: “victim@test.onmicrosoft.com”,
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“ObjectId”: “Not Available”,
“ModifiedProperties”: [],
“AzureActiveDirectoryEventType”: 1,
“ExtendedProperties”: [
{
“Value”: “{}”,
“Name”: “additionalDetails”
},
{
“Value”: “Domain”,
“Name”: “extendedAuditEventCategory”
}
],
“SupportTicketId”: “”,
“ActorIpAddress”: “1.1.1.1”,
“Target”: [
{
“Type”: 1,
“ID”: “test.com”
}
],
“
}
Remediation
The Azure AD Investigator auditing script, available from the FireEye GitHub repository, contains a module that
will enumerate all domains in a Microsoft 365 tenant. The script will output all unverified domains, domains that are
configured for federation, as well as domains with a federated realm object that is evidence of the AADBackdoor tool.
Administrators should review this output to ensure that only expected domains are configured as federated and that the
federation login pages are expected as well.
Step 1: Review Configured Domains and Trusts Within Microsoft 365 and Remove Untrusted Domains
1. Enumerate all Registered Domains
Organizations should proactively review the scope of configured domains within a Microsoft 365 tenant, including the
configured authentication methods (Managed or Federated). The PowerShell cmdlets noted in Figure 24 will provide a
listing of configured domains and the associated authentication methods.
2. Remove unrecognized or suspicious domains
Organizations should assess each domain’s verification status and authentication mode. These settings should be
reviewed for legitimacy and functional operation. If a domain is no longer in use, or the domain’s existence cannot be
readily identified, it should be investigated and removed from the tenant (Figure 25).
Figure 24. Connect-MsolService

PowerShell cmdlets to review Get-MsolDomain
domain configurations.
Connect-ExchangeOnline
Get-FederatedOrganizationIdentifier -IncludeExtendedDomainInfo
Get-FederationTrust

PowerShell commands to
remove an Azure AD or ** Will delete a domain from Azure Active Directory. **
federated domain. Remove-MsolDomain
** Will remove a domain and the associated relying party trust

settings in AD FS. **
Remove-MsolFederatedDomain
ATTACK TECHNIQUE:
Abuse Azure AD Privileged Roles

Azure Active Directory Privileged Roles Overview Table 2 details some of the highest privileged directory
Azure Active Directory uses the concept of roles to confer roles that threat actors often target – and should be
administrative privileges. Roles can be assigned to users, closely monitored by organizations. This should not be
groups, applications, and service principals (covered later treated as an exhaustive list of privileged roles. For a
in this white paper). There are over 50 roles available in full listing see https://docs.microsoft.com/en-us/azure/
Azure AD and some are more sensitive than others. active-directory/roles/permissions-reference.
Table 2. Azure AD - Highly Privileged Roles.
Role Description Impact
Can create and manage app registrations and

Application administrator Backdoor existing applications
enterprise apps
Can create and manage app registrations and

Cloud application administrator Backdoor existing applications
enterprise apps
Grant access to user mailboxes

Exchange administrator Manage all aspects of exchange
Change mail settings
Manage all aspects of Azure AD and Microsoft services Complete control over the Microsoft 365
Global administrator
that use it environment
Privileged role administrator Manage role assignments Privilege escalation via privileged roles
Assign roles in all subscriptions and management

User access administrator Privilege escalation via privileged roles
groups
Complete control over SharePoint including access

SharePoint administrator Can manage all aspects of SharePoint
to sites and documents
Hybrid identity administrator Can update federation settings for domains Ability to install an azure AD backdoor
Technique Remediation
Organizations will often grant privileged roles to user Step 1: Review and Configure Cloud-Only Accounts for
identities that are synced from on-premises Active Directory. Privileged Role Holders
Most commonly, this includes a privileged on-premises Organizations should review the scope of accounts
account being used to manage Azure AD and Microsoft 365 assigned privileged permissions and roles in Microsoft 365.
resources. This can present a security risk as it facilitates Additionally, the roles and accounts with privileged access
lateral movement from the on-premises environment to the should be cloud-only accounts (not accounts synced from
cloud environment. Mandiant has observed threat actors on-premises identity stores such as Active Directory).
performing reconnaissance to identify on-premises AD All privileged cloud-only accounts should leverage MFA
accounts that hold privileged roles and target them for through either conditional access polices or security defaults.
credential theft. Once in possession of credentials for an
account that holds a privileged directory role, the threat 1. Review Accounts assigned Privileged Roles
actor uses it to connect to Microsoft 365 and establish a
foothold for directly accessing cloud resources without the Using the PowerShell commands referenced in Figure
continued need for on-premises access. 26, review each account that is assigned to a privileged
role in Azure AD. Any identified on-premises synced
accounts that are configured with a privileged role
in Azure AD should be replaced with a cloud-only
account. Cloud-only accounts are denoted by the
@<tenant>.onmicrosoft.com domain suffix.

$Role = Get-AzureADDirectoryRole
PowerShell
commands to $Role | ForEach-Object {
review privileged $ObjectId = $_.ObjectId
role assignments $displayname = $_.displayname
in Azure AD. $a = Get-AzureADDirectoryRoleMember -objectid $ObjectId | Select-Object
ObjectID, UserPrincipalName
$a | Add-Member -NotePropertyName GroupID -NotePropertyValue $ObjectId
$a | Add-Member -NotePropertyName GroupName -NotePropertyValue
$DisplayName
$a | Export-csv Get-AzureADDirectoryRoleMember.csv -Append
-NoTypeInformation
2. List and review ImmutableID values for cloud-only accounts
ImmutableIDs act as an anchor attribute between synced on-premises identities and their cloud account counterpart.
If a cloud-only account has an ImmutableID, then a threat actor could forge a SAML token for the account, even though
it is considered cloud-only. For this reason, all cloud-only accounts should not be configured with an ImmutableID.
The PowerShell command noted in Figure 27 can be leveraged to review cloud-only accounts with an ImmutableID.
3. For accounts that contain an ImmutableID value, delete and recreate the account

PowerShell command to Get-MsolUser -All | Where-Object {$_.
identify cloud-only accounts UserPrincipalName -like “*.onmicrosoft.com”}| Select
with an ImmutableID. DisplayName,UserPrincipalName,ImmutableID
Step 2: Rotate All Passwords for Cloud-Only Accounts

Once the final set of privileged accounts have been determined, force password changes for all cloud-only accounts that
have not had their passwords recently rotated. The PowerShell command noted in Figure 28 will list all enabled cloud-only
accounts and the corresponding last password change value.

PowerShell command to Get-MsolUser -All | Where-Object {($_.UserPrincipalName -like
determine the last password “*.onmicrosoft.com”) -and ($_.BlockCredential -eq $false)} | Select
change date for accounts.
DisplayName,UserPrincipalName,LastPasswordChangeTimeStamp
Step 3: Invalidate Refresh Tokens for Each Cloud-Only Account

After rotating credentials for existing accounts, organizations should immediately revoke existing refresh tokens for each
account. This will result in users being required to reauthenticate. Using an account that has Microsoft 365 Global Administrator
permissions, invalidate each existing account’s refresh token using the PowerShell commands noted in Figure 29.

PowerShell commands to Get-AzureADuser -Identity <UPN> | Revoke-AzureADUserAllRefreshToken
ATTACK TECHNIQUE:
Hijack Azure AD Applications

Azure Applications and Service Principals Overview There are two different models when assigning
Applications are created in Azure AD to provide API permissions for applications to access an API:
access to Microsoft 365 data by third parties. Different
terms are used to refer to applications depending on how • Delegated Permissions, also known as
they are created and how they are interacted with. This OAuth2PermissionGrants, enable an application to
section defines these terms before a discussion of the perform API operations that access or manipulate data
threat actor techniques and how to protect against them. on behalf of a signed-in user. A user must sign-in and
consent to, or allow, the application to access data on
• App Registrations, also known as Applications or their behalf. An administrator can also consent on the
Application Objects, define the initial instance of an behalf of all users. Delegated permissions are out of
application, including API permissions, application scope for this white paper.
secrets, and branding elements. The app registration • Application Permissions, also known as AppRoles and
resides in the tenant where it was created. For example, AppRoleAssignments, enable an application to perform
the Exchange Online application resides in the Microsoft API operations that access or manipulate data without
Corporation tenant and the custom application created a signed-in user. Application Permissions allows the
by the IT team resides in the organization’s tenant. application to interact with an API as itself, without a
Application objects serve as a “blueprint” to create a session that is acting on behalf of a specific user.
service principal in any tenant that uses the application.
• Enterprise Applications, also known as Service Both Applications and Service Principals can have
Principals or Application Instances, represent delegated or application permissions associated with them.
applications that are being used within a Microsoft 365
In order to authenticate to Microsoft 365 and access the
tenant. These can be third-party applications such as
APIs, Applications and service principals can also have
a Salesforce integration, or custom applications built
credentials in the form of secrets or certificates associated
by the organization. There are also “first-party” service
with them. These are roughly analogous to API keys in other
principals used for components of Microsoft 365 itself.
cloud services. Administrators can add a credential that
Examples include Exchange Online, Microsoft Graph,
is then used to connect to Microsoft 365 with the identity
and the Azure Portal. Every tenant using an application
of the application or service principal. Once the credential
will automatically create a service principal for it. There
has been added to Microsoft 365, its value cannot be
is a one-to-many relationship between applications and
extracted. An attacker that is able to add a new secret
service principals.
or certificate can connect to Azure AD as the application
The term “applications” is often used to refer to both and perform API operations using whatever Application
App Registrations and Enterprise Applications as many Permissions that are assigned to it. For example, an
concepts apply to both. This white paper will follow the organization may configure a backup application with the
same practice going forward and refer to specific terms mail.read Application Permission to allow it to read all mail
when needed. in the tenant and create backups. Hijacking an application
(by adding a rogue secret or certificate) with granted
permissions will allow the attacker to access data that is
normally protected by MFA requirements.
Technique Detection
Mandiant has observed UNC2452 adding additional The Azure AD Audit log and the Unified Audit Log record
certificates or secrets to existing applications and service when credentials are added to both service principals
principals. To accomplish this, the threat actor first needed and App Registrations. In most organizations, credentials
to compromise an account with a privileged directory will be added to service principals and App Registrations
role that was granted the ability to modify Enterprise infrequently. Organizations should create rules to alert on
Applications or Application Registrations. A frequently the log events that get generated by these activities and
targeted role was the Application Administrator, because audit them to ensure they are legitimate. For example,
it allowed complete control over applications in Azure Microsoft has published suggested hunting rules using
AD. Once in possession of those credentials, UNC2452 Sentinel to identify these activities.
modified the application by using one of the following
techniques: Figure 30 shows a sample event from the Unified Audit
Log that is recorded when a credential is added to an App
• Modification of an application via the browser: Registration. The event includes the user that performed
The attacker connected to the Azure Portal with a web the action, the ID of the application that was modified,
browser and added a new secret to an App Registration details on the credential that was added, and more. Of
that had permissions to read all mail. There is no note are the ClientIP and ActorIPAddress fields. When
supported way to add a credential to an Enterprise the credential is added via the Azure Portal, the IP address
Application (service principal) via the browser. that gets recorded is a Microsoft IP address. This hides the
true IP address of the action and can make searching for
• Modification of an application via PowerShell:
activities by IP address prone to missing data.
The attacker connected to the Microsoft 365 tenant
using Azure AD PowerShell. Once connected they
added certificates to App Registrations and
Enterprise Applications that had the mail.read and
files.read permission.
Mandiant has observed UNC2452 first performing
reconnaissance of an organization’s Azure AD to
identify existing applications that already have sensitive
permissions set, such as mail.read and files.read. Once a
viable application was identified, UNC2452 added a rogue
credential to it using one of the methods detailed above.
At a minimum this allowed UNC2452 to access any user’s
data in the victim tenant without MFA.
An important note about hijacking an App Registration:

App Registrations are the original copy of an application
that resides in the creator’s tenant. Any other tenant
that uses this application creates a copy of it called a
service principal. If a threat actor were to hijack the
App Registration of an application that is used by other
organizations, the threat actor would be able to access
the data of those organizations as well.
Figure 30.
{
Sample event
“OrganizationId”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
recorded when
a credential is “CreationTime”: “2021-01-09T18:40:16.0000000Z”,
added to an App “RecordType”: 8,
Registration. “Operation”: “Update application – Certificates and secrets management “,
“UserType”: 0,
“ClientIP”: “20.190.130.49”,
“Version”: 1,
“UserId”: “doug@testing.onmicrosoft.com”,
“ObjectId”: “Application_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Id”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
{
“Name”: “KeyDescription”,
“NewValue”: “[\r\n \”[KeyIdentifier= xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx
xxx,KeyType=Password,KeyUsage=Verify,DisplayName=test]\”\r\n]”,
},
{
“Name”: “Included Updated Properties”,
“NewValue”: “KeyDescription”,
“OldValue”: “”
}
],
“AzureActiveDirectoryEventType”: 1,
“ExtendedProperties”: [
{
“Value”: “{\”User-Agent\”:\”Mozilla/5.0 (Macintosh; Intel Mac OS
X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88
Safari/537.36\”}”,
“Name”: “additionalDetails”
},
}
}
A similar event is recorded when credentials are added to a service principal. Figure 31 details a sample log event from the
Unified Audit Log.
When a credential that has been added to an application is used to login to Microsoft 365, it is recorded differently than
an interactive user sign-in. In the Azure Portal these logins can be viewed by navigating to Sign-Ins under the Azure
Active Directory blade and then clicking the service principal Sign-ins tab. The sign-in log records the IP address that
performed the sign-in, but not the credential that was used. Note that currently these sign-ins are not recorded in the
Unified Audit Log.
Figure 31.
Sample event {
recorded when “OrganizationId”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
a credential is “CreationTime”: “2021-01-07T21:32:13.0000000Z”,
added to a service “RecordType”: 8,
principal.
“Operation”: “Add service principal credentials.”,
“UserType”: 0,
“ClientIP”: “1.1.1.1”,
“Version”: 1,
“UserId”: “doug@test.onmicrosoft.com”,
“ObjectId”: “xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx”,
“Id”: “ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx “,
{
“Name”: “KeyDescription”,
“NewValue”: “[\r\n \”[KeyIdentifier=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx
xx,KeyType=Symmetric,KeyUsage=Verify,DisplayName=]\”\r\n]”,
},
}
Remediation
The Azure AD Investigator auditing script, available from the FireEye GitHub repository, contains a module that will
enumerate all applications and service principals in a Microsoft 365 tenant. The script will output all applications and
service principals that have both certain high-risk application permissions assigned to them and an assigned credential.
These are applications that a threat actor may have used to connect to Microsoft 365 and access data. Administrators
will need to work with their security and IT teams to validate that the credentials added to the applications and service
principals are legitimate.
Step 1: Review and Remediate Keys Associated with Service Principals and Applications
Organizations can leverage Azure PowerShell to review and remediate service principals or applications that may be
configured with credentials for remote authentication using either a static secret or certificate.
1. Search for suspicious service principal credentials

To search for evidence of credentials that have been configured or added to a specific service principal, the PowerShell
command noted in Figure 32 can be leveraged. The command output will include the KeyId, StartDate, EndDate, and key
type (password / certificate).
2. Remove suspicious service principal credentials

To remove a suspicious credential associated with a specific service principal, the PowerShell commands noted in
Figure 33 can be leveraged.
3. Search for suspicious Application credentials
To search for evidence of credentials that have been configured or added to a specific Azure application,
the PowerShell command noted in Figure 34 can be leveraged.
4. Remove suspicious Application credentials
To remove a suspicious credential associated with a specific application, the PowerShell commands noted in Figure 35
can be leveraged.
Figure 32. Connect-AzAccount

PowerShell command to Get-AzADServicePrincipal -ApplicationID <> | Get-AzADSPCredential
review a service principal –
and any associated credentials
that may be configured.

PowerShell commands ** Remove all credentials associated with a service principal **
to remove credentials Get-AzADServicePrincipal -ObjectId <> | Remove-AzADSpCredential
associated with a service ** Remove a specific credential (KeyID) associated with a service
principal – or remove a
principal **
specific service principal.
Remove-AzADSpCredential -ObjectId <> -KeyId <>
** Remove a specific service principal **
Remove-AzADServicePrincipal -ObjectId <>

PowerShell command to Get-AzADApplication -ApplicationID * | Get-AzADAppCredential
review a service principal –
and any associated credentials
that may be configured.
Figure 35.
Connect-AzAccount
PowerShell commands to ** Remove all credentials associated with a service principal **
remove credentials associated Get-AzADApplication -ObjectId <> | Remove- AzADAppCredential
with an application – or
remove a specific application.
** Remove a specific credential (KeyID) associated with a service
principal **
Remove-AzADAppCredential -ObjectId <> -KeyId <>
** Remove a specific application **
Remove-AzADApplication -ObjectId <>
Step 2: Invalidate All Existing Refresh Tokens

After removing malicious credentials, organizations should immediately revoke all existing refresh tokens for their
Microsoft 365 tenant. This will result in users being required to reauthenticate. Using an account that has Microsoft 365
Global Administrator permissions, invalidate all existing refresh tokens using the PowerShell commands noted in
Figure 36.

PowerShell commands to Get-AzureADuser -all $true | Revoke-AzureADUserAllRefreshToken
Microsoft 365 Hardening

This section contains hardening recommendations for Microsoft 365 that are associated with the attacker techniques
described in this white paper. A comprehensive discussion on Microsoft 365 hardening is outside the scope of this
white paper.
Step 1: Filter accounts synced to Azure Active Directory

On-premises Active Directory users that are synced to Azure AD should follow the concept of least privilege. Only
identities that utilize cloud services should be synced using AD Connect, and any accounts that are deemed to
have a level of on-premises permissions should not be synced and assigned permissions in Azure AD. This can be
accomplished using AD Connect sync filtering, where four options are available:
• Filter by Domain • Filter by Security Group
• Filter by OU • Filter by Attribute
1. Review Azure AD Sign-In logs
To identify on-premises Active Directory users that do not utilize Azure AD, Azure AD Sign-in logs can be reviewed
(Figure 37 - Figure 39).
Review user Azure AD Sign-ins by user UPN:
Figure 37.
PowerShell Connect-AzureAD
command to Get-AzureADAuditSignInLogs -Filter “UserPrincipalName eq <UPN>” | Select-
review Azure AD Object UserPrincipalName, CreatedDateTime, AppDisplayName, AppId, IpAddress |
sign-in logs to Export-csv signins.csv -Append
identify potentially
dormant accounts
by UPN.
Review user Azure AD Sign-ins by Active Directory OU:
Figure 38.
#Export members of AD OU to CSV
PowerShell
Get-ADUser -Filter * -SearchBase “<OU PATH>” | Select-object
commands to
review Azure AD UserPrincipalName | Export-csv OUMembers.csv
sign-in logs to
identify potentially #Import CSV into variable
dormant accounts $Users = Import-csv OUMembers.csv
by AD OU.
#Review OU member logins against Azure AD Sign-in logs

Connect-AzureAD
Foreach ($user in $users) { $u = $user.UserPrincipalName Get-
AzureADAuditSignInLogs -Filter “UserPrincipalName eq ‘$u’” | Select-Object
UserPrincipalName, CreatedDateTime, AppDisplayName, AppId, IpAddress |
Export-csv signins.csv -Append
}
Review user Azure AD Sign-ins by Active Directory Security Group:
Figure 39. #Export members of AD Security Group to CSV

PowerShell Get-ADGroupMember -Identity <Group Name> -Recursive | Select-object
commands to UserPrincipalName | Export-csv GroupMembers.csv
review Azure AD
sign-in logs to
#Import CSV into variable
identify potentially
dormant accounts $Users = Import-csv GroupMembers.csv
by security group
association. #Review Group member logins against Azure AD Sign-in logs
Connect-AzureAD
Foreach ($user in $users) { $u = $user.UserPrincipalName Get-
AzureADAuditSignInLogs -Filter “UserPrincipalName eq ‘$u’” | Select-Object
UserPrincipalName, CreatedDateTime, AppDisplayName, AppId, IpAddress |
Export-csv signins.csv -Append
}
2. Configure filtering with Azure AD Connect c. Cloud apps or admins > Include
For more information regarding Azure AD Connect i. Select All cloud apps
filtering, reference: d. Conditions > Locations
https://docs.microsoft.com/en-us/azure/active-directory/
hybrid/how-to-connect-sync-configure-filtering i. Under Configure, select Yes
ii. Include > Any Location

Step 2: Limit Privileged Users to Trusted IPs
When privileged accounts are leveraged to access and iii. Exclude > select Locations > Choose newly
administer Microsoft 365 resources, connectivity from added location
the accounts should only be permissible from trusted e. Grant > Block Access
locations, usually representing public IP address blocks
managed by an organization. Note: Prior to enabling the policy, to prevent an account
from being locked out of Microsoft 365, it is highly
To Configure Trusted Networks: recommended to test the policy in Report-Only mode to
1. Login to https://portal.azure.com > Azure Active ensure the configuration acts as expected.
Directory > Security > Named Locations
For additional information related to conditional access
2. Click New Location
policies, reference
3. Provide a Name and IP Ranges
• https://docs.microsoft.com/en-us/microsoft-365/
a. Check Mark as Trusted location
security/office-365-security/identity-access-policies
4. Select Save
• https://docs.microsoft.com/en-us/azure/active-
Conditional Access Policy Configuration: directory/conditional-access/plan-conditional-access
1. Under Security > Conditional Access
2. Select New policy
a. Users and Groups > Include
i. Select Directory Roles
• Check All Roles
b. Users and Groups > Exclude
i. Add Break-Glass Global Administrators
• Break-Glass Global Administrators should

exempt from all CAPs in the event CAPs are
not being applied as expected.
Step 3: Enhance Mailbox Auditing

Enabling mailbox auditing for users will provide greater visibility into potentially suspicious activity. Mailbox auditing
provides organizations with visibility related to logon events for mailboxes as well as specific actions that occurred based
upon either the mailbox owner, delegate, or an administrator. With optimized audit logging in Microsoft 365, organizations
are empowered to enhance detection, monitoring, and investigative activities.
1. Review Mailbox Auditing Settings

To verify mailbox auditing settings for configured mailboxes, the PowerShell command noted in Figure 40
can be leveraged.
Figure 40. Connect-ExchangeOnline

Get-Mailbox -Resultsize Unlimited -Filter {(RecipientTypeDetails
PowerShell command to verify
mailbox auditing settings. -eq “UserMailBox”) -and (SKUAssigned -eq “True”)} | Select
userprincipalname, Audit* | export-csv EnableMailBoxAudtingSettings.
csv
2. Enable Audit Status for all Mailboxes

To enforce that mailbox audit logging is enabled for all mail accounts, the PowerShell command noted in Figure 41
can be leveraged.

Get-Mailbox -Resultsize Unlimited -Filter {(RecipientTypeDetails
PowerShell command to
enforce mailbox auditing. -eq “UserMailBox”) -and (SKUAssigned -eq “True”)} | Set-Mailbox
-AuditEnabled $True
3. Set Mailbox audit logging retention

At a minimum, Mandiant recommends that auditing for mailbox audit logs be retained for at least 90 days. To enforce
this configuration, the PowerShell command noted in Figure 42 can be leveraged.

PowerShell command to Get-Mailbox -Resultsize Unlimited -Filter {(RecipientTypeDetails
enforce a mailbox audit log -eq “UserMailBox”) -and (SKUAssigned -eq “True”)} | Set-Mailbox
retention period. -AuditLogAgeLimit 90
4. Enable Verbose Mailbox Auditing Settings
Note: Before applying verbose Mailbox Auditing settings, an organization should verify that their centralized log or SIEM
platform can handle the increased logging volume.
Verbose E3 Licensing Auditing Settings

At a minimum, the MailboxLogin action for the Owner Logon Type should be added to each mailbox’s audit settings.
The PowerShell command noted in Figure 43 will add the MailBoxLogin auditing setting to the AuditOwner logon type
for each mailbox:
Figure 43.
PowerShell command to add Get-Mailbox -Resultsize Unlimited -Filter {(RecipientTypeDetails
the MailBoxLogin setting for
-eq “UserMailBox”) -and (SKUAssigned -eq “True”)} | Set-Mailbox
the AuditOwner logon type.
-AuditOwner @{Add=MailBoxLogin}
To enable the highest level of logging available with E3 licensing, the PowerShell command noted in Figure 44 can be run
on each mailbox to replace auditing settings for each logon type,
Figure 44.
PowerShell Set-Mailbox -Identity <UPN> `
command to
-AuditAdmin MoveToDeletedItems,SoftDelete,HardDelete,SendAs,SendOnBehalf,
replace auditing
settings with UpdateFolderPermissions,UpdateInboxRules,UpdateCalendarDelegation `
optimized E3 -AuditDelegate MoveToDeletedItems,SoftDelete,HardDelete,SendAs,
settings for each SendOnBehalf,UpdateFolderPermissions,UpdateInboxRules `
logon type. -AuditOwner MoveToDeletedItems,SoftDelete,HardDelete,MailboxLogin,
UpdateFolderPermissions,UpdateInboxRules,UpdateCalendarDelegation
Verbose E5 Licensing Audit Settings

E5 and E5 Compliance Add-on licensing includes the audit setting MailItemsAccessed. MailItemsAccessed is a
reliable logging mechanism which replaces the MessageBind logging mechanism. For incident responders, having
access to MailItemsAccessed events will provide a better understanding of the scope and the depth of a potential
compromise.
Mandiant recommends that MailItemsAccessed be enabled for all logon types for highly sensitive mailboxes.
The PowerShell command noted in Figure 45 will add the MailItemsAccessed audit setting for the AuditOwner,
AuditDelegate, and AuditAdmin logon types for a specific mailbox.

PowerShell command to Set-Mailbox -Identity <UPN> -AuditOwner @{Add=MailItemsAccessed}
add the MailItemsAccessed -AuditDelegate @{Add=MailItemsAccessed} -AuditAudit @
setting for the AuditOwner, {Add=MailItemsAccessed}
AuditDelegate, and
AuditAdmin logon types.
To enable the highest level of logging available for E5 licensing, the PowerShell command noted in Figure 46 can be
ran on each mailbox to replace auditing settings for each logon type.

PowerShell Set-Mailbox -Identity <UPN> `
command to -AuditAdmin MoveToDeletedItems,SoftDelete,HardDelete,SendAs,
replace auditing SendOnBehalf,UpdateFolderPermissions,UpdateInboxRules,
settings with
UpdateCalendarDelegation,MailItemsAccessed `
optimized E5
settings for each -AuditDelegate MoveToDeletedItems,SoftDelete,HardDelete,SendAs,
logon type. SendOnBehalf,UpdateFolderPermissions,UpdateInboxRules,MailItemsAccessed `
-AuditOwner MoveToDeletedItems,SoftDelete,HardDelete,MailboxLogin,
UpdateFolderPermissions,UpdateInboxRules,UpdateCalendarDelegation,
MailItemsAccessed
Note: If Microsoft releases new auditing settings, the new settings will not be automatically applied to mailboxes where
custom audit settings have previously been configured. New auditing settings will need to be manually applied.
For more information regarding mailbox auditing, reference:

https://docs.microsoft.com/en-us/microsoft-365/compliance/enable-mailbox-auditing?view=o365-worldwide
Step 4: Review Azure Application and Service

Principal Permissions
Azure applications and service principals can be granted access to protected resources in Microsoft 365. For example,
a token can be granted to allow a third-party application to read a user’s mailbox or download the contents of a user’s
OneDrive account.
Once an application has been granted permissions, an attacker can utilize the application to access user accounts with
little to no other security controls. This is commonly leveraged by attackers since they can bypass MFA requirements
and maintain persistence to targeted employee’s data.
For this reason, it is important to have visibility over which applications have been granted OAuth access to user
accounts within the tenant.
1. Run Create-AppConsentGrantReport.ps1 Script
Create-AppConsentGrantReport.ps1 is an open-source PowerShell script that will enumerate all permission grants
for all applications in a Microsoft 365 tenant. This output can then be reviewed to identify overly permissive and
suspicious applications.

PowerShell command to execute the .\Create-AppConsentGrantReport.ps1 -AdminUPN
Create-AppConsentGraphReport. globalreader@contoso.onmicrosoft.com -Path .\output.xlsx
ps1 script - enumerate all permission
grants for all applications.
Many applications have legitimate use cases that warrant permissive access to applications (email applications and
cloud-based collaboration platforms) in a Microsoft 365 tenant. The output from this script report should be thoroughly
reviewed to determine which applications can be removed from the tenant or have their privileges reduced.
2. Apply Application Access Policies
For applications that are granted the ‘Application’ Consent Type for mail permissions (Mail.Read,Mail.Send,Mail.
ReadWrite,Mail.ReadBasic,Mail.ReadBasic.All), these applications are granted the rights to all mailboxes in the tenant,
without needing specific account credentials to access a mailbox. Applications assigned these permissions can be
reviewed by filtering the PermissionType column by Application on the ConsentGrantData tab generated within the
Create-AppConsentGrantReport report (Figure 48).
Figure 48. Output to review assigned application permissions.
While some legitimate applications require this privilege grant, they commonly do not need access to every mailbox.
To limit which mailboxes the application can access, it is recommended to apply an Application Access Policy to the
application.
For more information on configuration Application Access Policies, reference:

https://docs.microsoft.com/en-us/powershell/module/exchange/new-applicationaccesspolicy?view=exchange-ps
3. Require Admin Consent to Apps
• Login to https://portal.azure.com
• Select Enterprise Applications
• Select User Settings
• Set Users can consent to apps accessing company on their behalf to No
• Users can consent to apps accessing company data for the groups they own to No
• Set Users can request admin consent to apps they are unable to consent to No
• Select Consent and permissions
• Under User Consent for Applications select Do not allow user consent
• Under Group owner consent for apps accessing data select Do not allow group owner consent
For more information regarding illicit application consent grants, reference:

https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-
grants?view=o365-worldwide
Step 5: Enforce multi-factor authentication (MFA) for Accounts

To protect against attacks that take advantage of single factor authentication for access to Microsoft 365 services,
MFA should be enforced for all accounts with access to a Microsoft 365 tenant. At a minimum, MFA should be used for
administrative access to a Microsoft 365 tenant, including when Exchange Online and Azure AD PowerShell management
functionality is required.
For smaller organizations that need a quick baseline of enabled security settings (including MFA enforcement and blocking
legacy authentication protocols) to create a hardened security posture for Microsoft 365, the grouping of settings known
as “Security Defaults” should be considered. Security Defaults are free (available at any tier) and replace the older and
deprecated baseline policies.
Some notes and caveats when using Security Defaults:
• If Conditional Access policies are currently being leveraged (Azure AD Premium P1 license), Security Defaults should not be
used.
• If an organization has complex security requirements, Conditional Access policies should be used over Security
Defaults.
• If an organization has Azure Active Directory Premium licenses, Security Defaults should not be used.
• If an organization uses Security Defaults and then decides to migrate to using Conditional Access policies, Security
Defaults will first need to be disabled.
Step 6: Review all registered MFA devices

As a proactive best practice, organizations should develop a process to perform periodic reviews of all registered MFA
devices to identify any potentially malicious registrations. For any devices that do not align to an expected registration,
this process may potentially require re-enrollment for privileged and/or user-based accounts.
Note: This process should also include reviewing any accounts that can bypass MFA requirements, to include evaluating
the operational impact and associated risk of leveraging such a configuration.
The PowerShell script syntax noted in Figure 49 can be used to generate a report of MFA devices registered with Azure AD.
Figure 49.
Connect-MsolService
PowerShell script
to identify all MFA
$Result=@()
devices registered $users = Get-MsolUser -All
with Azure AD. $users | ForEach-Object {
$user = $_
$mfaStatus = $_.StrongAuthenticationRequirements.State
$phoneApp = $_.StrongAuthenticationPhoneAppDetails
$methodTypes = $_.StrongAuthenticationMethods
if ($mfaStatus -ne $null -or $methodTypes -ne $null)

{
if($mfaStatus -eq $null)
{
$mfaStatus=’Enabled (Conditional Access)’
}
$authMethods = $methodTypes.MethodType
$defaultAuthMethod = ($methodTypes | Where{$_.IsDefault -eq “True”}).
MethodType
$verifyEmail = $user.StrongAuthenticationUserDetails.Email
$phoneNumber = $user.StrongAuthenticationUserDetails.PhoneNumber
$alternativePhoneNumber = $user.StrongAuthenticationUserDetails.
AlternativePhoneNumber
}
Else
{
$mfaStatus = “Disabled”
$defaultAuthMethod = $null
$verifyEmail = $null
$phoneNumber = $null
$alternativePhoneNumber = $null
}
$Result += New-Object PSObject -property @{

UserName = $user.DisplayName
UserPrincipalName = $user.UserPrincipalName
MFAStatus = $mfaStatus
AuthenticationMethods = $authMethods
DefaultAuthMethod = $defaultAuthMethod
MFAEmail = $verifyEmail
PhoneNumber = $phoneNumber
AlternativePhoneNumber = $alternativePhoneNumber
DeviceName = $phoneApp.DeviceName
}
}
$Result | Select
UserName,UserPrincipalName,MFAStatus,DefaultAuthMethod,MFAEmail,
PhoneNumber,AlternativePhoneNumber,DeviceName | export-csv MFAReport.CSV
Step 7: Review Partner (Cloud Service Provider) Relationships

Organizations should review any configured partner relationships that exist within a Microsoft 365 tenant. Partner
relationships can exist as various partner types, including resellers, advisors and delegated administrators.
The scope of permissions assigned to partners should be reviewed and verified – as partners can exist as Global Admin
or Helpdesk Admin roles. Delegated admin roles (Admin Agents and Helpdesk Agents) are also available when partner
relationships are present. Based on the roles assigned, members of either groups can access the customer’s Azure AD
tenant and Microsoft 365 services using their partner credentials and perform administrative actions on behalf of the
customer.
Per Microsoft, when a customer grants delegated administration privileges to a partner:
• The Admin Agent group is assigned to the Global Administrator role in the customer’s Azure AD tenant.
• The Helpdesk Agent group is assigned to the Helpdesk Administrator role in the customer’s Azure AD tenant.
1. Review Microsoft 365 Partner Relationships that have Delegated Admin Privileges
– Option 1: Navigate to https://admin.microsoft.com/AdminPortal/Home#/partners within the in Microsoft 365

Admin Center.
– Option 2: Using PowerShell (Figure 50), review any present DapEnabled values using the
Get-MsolPartnerInformation command
2. Remove DapEnabled Cloud Service Provider Delegated Admin Privileges
Any cloud service provider delegated administrative privileges should be reviewed and potentially removed.
Proactively, an organization would want assurance from the cloud service provider that the provider’s network and
Microsoft 365 tenant are secured and hardened appropriately.

PowerShell command to
review partner relationships. Get-MsolPartnerInformation
Conclusion
While UNC2452 has demonstrated a level of sophistication and evasiveness,
the observed techniques are both detectable and defensible. This white paper
outlines steps that represent actionable measures that can be leveraged to not
only remediate observed techniques, but also to empower organizations to
detect and harden against similar tactics.
As new information is derived from Mandiant’s frontline visibility, this white

paper will be updated with additional techniques and the associated detection,
remediation and hardening measures.
To learn more about FireEye, visit: www.FireEye.com/mandiant
FireEye, Inc. About Mandiant Solutions

601 McCarthy Blvd. Milpitas, CA 95035 Mandiant Solutions brings together the world’s leading
408.321.6300/877.FIREEYE (347.3393) threat intelligence and frontline expertise with continuous
info@FireEye.com security validation to arm organizations with the tools
needed to increase security effectiveness and reduce
business risk.
©2020 FireEye, Inc. All rights reserved.
FireEye and Mandiant are registered trademarks
of FireEye, Inc. All other brands, products, or
service names are or may be trademarks or
service marks of their respective owners.
I-EXT-WP-US-EN-000343-01

Remediation and Hardening - O365

Uploaded by

Copyright:

Available Formats

Remediation and Hardening - O365

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Remediation and Hardening - O365

Uploaded by

Copyright:

Available Formats

What remediation strategies are outlined in the document?

What remediation strategies are outlined in the document?

What attacker techniques are discussed in the document?

What attacker techniques are discussed in the document?

white paper

Attacker Tactics, Techniques and Procedures (TTPs)............................................................. 4

Attack Technique: Golden SAML Attack........................................................................................7

Microsoft 365 Attack Mitigation......................................................................................................19

Attack Technique: Modify Trusted Domains..............................................................................20

Attack Technique: Abuse Azure AD Privileged Roles...........................................................24

Attack Technique: Hijack Azure AD Applications...................................................................26

Microsoft 365 Hardening.................................................................................................................... 31

Goals and Objectives

It is important to note that there is no formal security boundary

Organizations can use the Azure AD Investigator auditing

Attacker Tactics, Techniques

Table 1. Overview of covered TTPs.

Technique MITRE ATT&CK Remediation Hardening

Step 1: Review Configured Domains and

Remediation Sequencing 3. Rotate impacted on-premises credentials,

ii. Azure AD connector account

Golden SAML Attack

Figure 4. C:\Windows\system32\cmd.exe /C c:\windows\temp\srv.exe -h -sc fo:* -b

Remediation certificate will still be resident in Azure AD, and can

Figure 6. ** 1st Iteration **

Set-ADFSProperties -AutoCertificateRollover $false

Set-ADFSProperties -AutoCertificateRollover $true

Update-AdfsCertificate -CertificateType token-signing

Set-ADFSProperties -AutoCertificateRollover $false

Step 2: Revoke Microsoft 365 Refresh Tokens

• Step 1: Configure a Group Managed Service Account (gMSA) for AD FS services

• Step 3: Review Account and Network Access Restrictions for AD FS Servers

Step 1: AD FS Service Account – Best Practices

Step 2: AD FS Logging and Auditing

With the default settings, the AD FS service registers

Note: Mandiant does not recommend enabling debug

Organizations can verify their current AD FS audit level by

Note: For an AD FS server farm, any changes to AD FS

For AD FS services running on Windows Server 2012R2,

Figure 9. Set-AdfsProperties -LogLevel

Figure 10. Set-AdfsProperties -AuditLevel Verbose

Figure 13. auditpol.exe /set /subcategory:”Application Generated” /

3. For the AD FS Server Farm – navigate to Start >

• Federation Service Properties > Events tab

– Select Success Audits and Failure Audits

Note: Enabling AD FS service auditing can increase

Once AD FS auditing is configured, any successful

Figure 15. Event IDs related to AD FS configuration setting modifications.

Enable Domain Auditing for AD FS Distributed Key Manager Access Requests

Figure 21. https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

AD FS Required Ports and Protocols

Protocol Port (TCP/UDP) Description

HTTP 80 (TCP/UDP) Used to synchronize

HTTPS 443 (TCP/UDP) Used to synchronize

Configure, Sync Sync

Port 808 (Windows

Common ports leveraged for lateral movement can be Detection

To detect the use of forged SAML tokens, organization

Figure 6. 1st Iteration