An activity that provides an attacker access to resources after detection of an account compromise is called persistence.  One example of this is automatic forwarding of email.  Using leaked credentials, the attacker logs into a mailbox and configures mail to forward (usually to an external address).  Even after the account’s password is reset, the forwarding setting remains in effect.

In Office 365, there are numerous methods of achieving persistence.  Many take advantage of collaborative features and those that exist to increase user productivity.  It is important to be aware of these mechanisms and check for them after you become aware of a compromised account.  I wrote a script that not only reports on persistence configuration, but if the configuration occurred during the time that you believe the account was compromised.  It reports on these activities:

• Inbox rules that forward, to whom they forward, and if the rules were created/modified within the search window
• Forwarding configured via Outlook on the web Options (aka OWA Forwarding), to whom it forwards, and if it was created/modified within the search window
• Mailbox folder permission changes during the search window
• Anonymous calendar publishing is configured, and if it was enabled within the search window
• All applications that have access via user-based consent (known as OAuth grants), when the grant first occurred, and the last time the application signed in
• Files located in SharePoint Online (and OneDrive for Business) that were shared within the search window, whether they were anonymous links or secure links, and if the latter, with whom they were shared
• Members (internal and guest) added to a Microsoft Team or Office 365 Group within the search window, which Team/Group, and the UPN of the member
• Flows that were edited within the search window, the admin URL of the Flow, and the connectors used
• (Optional) Mobile device partnerships with the user’s mailbox, and the first and last sync time of each (This isn’t technically persistence, but can be included to show partnerships, usually to see if a new one was created)

Most of the information for these activities is available in the unified audit log. (Because the log is stored in a mailbox in Exchange Online, if you want to be sure that you have enabled unified logging, you can run  (Get-AdminAuditLogConfig).UnifiedAuditLogIngestionEnabled and check that the output is True.)  Some of the information, however, is available only via the Graph API:

• Applications that the user has granted consent (this is available via PowerShell, but not per user, so it is not practical in a production tenant)
• The date of the grant for an application’s consent
• Application sign-ins
• Members added to an Office 365 Group (though members added to a Team are available in the unified audit log…odd, yes)

Leveraging the Graph API requires that you register an application in Azure AD.  This is because you have to specify what permissions (access) you want the application to have, as well as how the application will authenticate. (There are multiple ways to authenticate, but I am using a client secret.)  I have created a separate post with those instructions.  Some admins may not want or have the ability to register an application, so it is not required, but the output will obviously not include the application consent information and Office 365 Group member additions.  For those that do, you will need to edit the script and set $useGraphApi  to $true , and provide the values for the $appId , $clientSecret , and $tenantDomain variables.

The script requires you to be connected to Exchange Online and have the Azure AD module installed and connected.  It will search, by default, for activities in the last seven days, but you can specify a start and/or end dates.  Bear in mind that the unified audit log retains entries for 90 days for non-E5 users (and one year for E5-licensed users or those assigned an Advanced Compliance add-on license).  Additionally, Azure AD audit and sign-in log entries are retained for 30 days for P1/P2-licensed users (seven days for Free and Basic users) (source).

Handling the output is something I spent a fair amount of time working through.  This is because of how PowerShell processes multiple objects in a script that contain different properties.  (It assumes the properties of the first object in the output apply to all successive objects, so those successive objects will only show properties that are also in the first object.)  I experimented with key/value pairs in generic properties, but it is ugly and requires much more work from you if you want to parse the values for further processing.

My compromise solution is that the default option will display the output to the screen as text and not native objects.  If you use the PassThru  switch, the objects are not output to the screen, but sent to the pipeline as native objects so you can do whatever you want with them.  Generally, this means you would assign the output to a variable and then work with each object in the collection, but you can even just output the variable to the screen and they will be displayed correctly.  (It is only when outputting them directly from the script that objects with different properties are displayed incorrectly.)

You can download the script or copy below.

  Get-O365PersistenceActions.ps1 (22.0 KiB)