How to Detect OAuth Access Token Theft in Azure

Stealing access tokens to gain access to a user’s account in Azure is a technique that’s been actively used by threat groups over the past few years. I’ve observed this technique in several engagements across the past few years from Chinese APT groups. Generally, this is done through a spear phishing / phishing email with a link that requires a user to grant access to a malicious application through OAuth’s authorization code flow. This enables the attacker-controlled application to access the user’s data.

I’ve broken the blog into two components:

  • Attack overview
  • Detection methodology


ATTACK OVERVIEW
The attacker will register a malicious application and generate a phishing link in an email that takes a user to a page that looks like the image below. This will generally show information including the app name (in this instance it’s listed as “evilapp”) – whether the app is verified / unverified and then the option to accept or not. 


Just a side note: in almost every instance, the threat actors are not obtuse enough to name it “evilapp” – I usually see them give applications a very Microsoft-sounding name like “Microsoft OAuth Application” or something random like this (no shade intended). 

At this point, when the user presses “accept” what happens is:
  • The user authenticated with the application
  • Access token is now returned to the malicious attacker’s application via the re-direct URI 
In this instance, I’ve gathered the user “inversecos” access token along with the refresh token. The refresh token is what’s used to request new access tokens without requiring the victim to re-authenticate.



DETECTION METHODOLOGY

Step 1: OAuth Redirect Link
A quick review of a user’s browsing history will reveal all malicious OAuth URLs visited from a phishing email. If you look closely at the browser URL, you will see the malicious redirect link where the OAuth token will be directed to a malicious domain (where the threat actor’s application is running from). 

For the sake of “visibility”, I’ve pasted the full malicious URL below. Please note that in most of the instances where I have observed this, the combination of reviewing browsing artefacts followed by reviewing the URL and then reviewing audit logs have revealed the full attack chain and what the threat actors did:

https[:]//login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=6baa7a70-af41-4f1b-9b0f-52ab388a4c09&response_type=code&redirect_uri=http%3A%2F%2F127.0.0.1%3A5000%2FgetAToken&scope=User.Read+offline_access+openid+profile&state=9dec50b3-e211-4c88-9a34-4046e239c159

The main areas to observe in that URL string above are:
  • Client_id:  This is the client_id of the malicious application that the attacker has set up in the attacker’s tenant (or it could even be created in YOUR tenant which is more insidious)

  • Redirect_URI: This is the URL where the application is being hosted and run from. For this example, I ran this from my localhost hence the URL of “http://127.0.0.1:5000/getAToken”. However, in an attacker instance, this will generally show a malicious domain.

  • Scope: These are the API permissions that the attacking application is getting your consent to grant. In this example, only one permission is being requested “User.Read” 
From the attacker’s perspective this is how they register a malicious application. Please note here that there’s two attack vectors an attacker can take – they can register a malicious application within your organisation’s tenant, or they can do this inside their own malicious tenant and select this option of “Accounts in any organizational directory (Any Azure AD directory – Multitenant)”. 


Step 2: Review granted permissions
It’s important at this step you review all the permissions granted to the malicious application. Here is the official Microsoft documentation: https://docs.microsoft.com/en-us/graph/permissions-reference. In my example, I only granted one permission, however these are some you should look out for:

  • User.Read – Allows the application to read the profile of a user and basic company information

  • User.ReadWrite – Allows the application to read and update user profile information

  • User.ReadWrite.All – Read and write to all users full profiles. This can be used to create, delete, and reset user passwords.

  • Mail.ReadWrite – Allow application to read and write emails 

  • Calendars.ReadWrite – Allows the application to read and write to calendar

  • Files.ReadWrite – Allows the application ability to read and write files

  • User.Export.All – Application can request to export a user’s personal data 

Step 3: Audit Logs 
Reviewing the Azure audit logs will reveal THREE log entries that you need to take note of (see below). These will happen in a succession once a user grants permissions to the malicious application.

Hunt 1: Malicious delegated permission
This is the first event you will see when you perform the hunt. Look for the following details:
  • Category: ApplicationManagement
  • Activity: Add delegated permission grant
  • Target Property Name: Look for the permissions that were granted. In my instance you can see it was the “User.Read” permission.

Hunt 2: Malicious app role assignment 
To hunt for the initial granting of permissions to the application, look for the following details:
  • Category: UserManagement
  • Activity: Add app role assignment grant to user
  • Status: success
  • ObjectID: <Malicious application Object ID>
  • Target Display Name: <Malicious application name>

Hunt 3: Malicious application consent
Finally, the entry that shows the actual application consent can be seen by looking for the following entry in the audit log:
  • Category: ApplicationManagement
  • Activity: Consent to application
  • Initiated by (actor): Look for the malicious application Object ID
  • Target Display Name: Look for the malicious application name
  • Modified Properties: Look for the ConsentAction.Permissions and confirm the permissions consented by the user to the malicious application. I’ve highlighted here in purple the permission of “User.Read”. 

Step 4: Azure Sign-in Logs 
Finally, review the Azure sign-in logs for logons into a user account coming from an application. This should be done after step 3 to avoid false positives. In step 3, you will be able to gather the malicious application name along with the Object ID, this can be used to then filter through the sign-in logs.   In my instance this happened once:


This is what you look for:
  • User sign-ins (interactive)
  • Application: Malicious application name 
  • User ID: The client ID of the malicious application

Happy hunting UwU 

REFERENCES



Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more