Co-Authors: Wendy Willner, and Milan Patel.
In the lights of the recent SUNBURST cyber-attack, adversaries are abusing the Security Assertion Markup Language (SAML) protocol in a nasty way, where they can create like an authenticated ticket (SAML response) for any user and any role, without the need for the identity provider … The adversaries themselves became an identity provider!
What is SAML?
“Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider.”
Different cloud vendors support the authentication via SAML, in this way the organization wont need to copy their identity database to every cloud vendor … federation style!
Legitimate authentication process flow via SAML
This is a nice flow charts from Sygnia showing the normal flow of the authentication process via SAML
The user starts by sending a request to the service provider like: AWS, Office 365, Azure, ..
The service provider redirects the user to the federated identity provider like Active Directory Federation Services (ADFS).
ADFS will check and validate the user, and will create a signed response that includes the user details and the authorized roles.
(Image credited to Sygnia)
The ADFS federation server will log the following events when validates the user’s credentials, or when creates a new token:
Event id 1202 – “The Federation Service validated a new credential”.
Event id 1200 – "The Federation Service issued a valid token”.
Normal SAML Authentication Event Flow in QRadar:
In the above scenario, we can see that the AWS – Assume Role with SAML event is proceeded by the ADFS credential validation and token creation events for the same user.
Golden SAML … A Hacker Style!
This attack technique assumes that the attacker has already compromised the ADFS server, and he has managed to dump the ADFS Token-Signing Certificate, which is what he needs to create and sign his own SAML responses.
In the later sections, we will dive into how the attackers can get hold of the token-signing certificate, and how we can behaviorally detect it using QRadar, as there are many different available tools to dump the ADFS certificate.
At this stage, we will assume the attacker already managed to get the ADFS token signing certificate, to simulate this Golden SAML attack, we used shimit, a tool created by CyberArk.
The following screen shot shows how we successfully logged into AWS even using a non-existing username. The only things we needed were:
- ADFS token-signing certificate
- AWS account ID
- AWS role name
Attackers can get all of the necessary information by simply querying the ADFS config database!
The following screen shot shows the successful exploitation of the Golden SAML attack. First, you can see we tried to list the S3 buckets and it failed and then you can see later after the exploitation it worked!
In order to detect for these attacks, Security analysts need to look for any “role assume” events via SAML that are not proceeded by the (1) “ADFS credential validation” and (2) token creation events.
To detect it, we can correlate the SAML authentication events between the identity and service providers.
An example detection would be if an attacker tried to login to AWS using the fake/forged SAML response:
we would have an “AWS Assume Role with SAML” event
and it would not be preceded by the two ADFS events (1202, 1200)
You can get the QRadar Rules to do the above correlation from the following QRadar Correlation Rules to detect the Golden SAML attack.
Hunting For the Certificate Dumping Process
Its not an easy task for attackers to steal ADFS token-signing certificates as it involves two stages.
1) Get the ADFS token-signing public and private keys from the ADFS database. Which is difficult because they are stored in an encrypted format!
2) The attacker needs to find the decryption key somewhere, and then use it.
We will start with the second step to find and get the decryption key
Hunting the Retrieval of the Decryption Key
The necessary decryption key is stored in a thumbnailPhoto attribute of a specific active directory object.
The following screen shot shows how the decryption key is stored in the thumbnailPhoto attribute:
To get the decryption key, the attacker needs to perform a search in the active directory for that specific object and to read the thumbnailPhoto attribute
This is a PowerShell command to retrieve the decryption key:
$key = (get-adobject -filter 'ObjectClass -eq "Contact" -and name -ne "CryptoPolicy"' -SearchBase "CN=ADFS, CN=Microsoft, CN=Program Data, DC=mutaz_dc, DC=com" -Properties thumbnailPhoto).thumbnailPhoto
$hexString = ($key | ForEach-Object ToString X2) -join ''
To detect it:
1) We need to make sure that the auditing for Directory Service Access is enabled, as follows:
2) We need to enable the auditing for that specific active directory object.
In order to enable auditing, right click that specific active directory object, → properties → Security tab → Click Advanced → move to the Auditing tab.
In the auditing tab, (1) click Add, and (2) change the principal to be Everyone
3. Scroll down to select which properties to monitor, and select the Read thumbnailPhoto:
click Apply and then OK.
After enabling the above auditing options, we will be able see and detect the stage when the attacker queries the active directory to get the content of the thumbnailPhoto (which contains the decryption key).
This is the logged event in QRadar, which indicates that the thumbnailPhoto attribute has been accessed / read.
The following screen shot shows the logged events when any tool tries to access the thumbnailPhoto attribute.
You can also use the following QRadar AQL query to search for that as well:
Select DATEFORMAT(starttime,'YYYY-MM-dd hh:mm') AS 'Start Time', QIDNAME(qid) as 'Event Name', logsourcename(logSourceId) as 'Log Source', categoryname(category) as 'Low Level Category', "sourceIP" as 'Source IP', "destinationIP" as 'Destination IP', "userName" as 'Username' from events where devicetype = 12 and "EventID"='4662' AND "Properties" ilike '%8d3bca50-1d7e-11d0-a081-00aa006c33ed%' Last 24 HOURS
Hunting for Dumping of ADFS Token-Signing Public and Private Keys From the ADFS Database
Adversaries needs to connect to the ADFS Configuration database to get more insights, like:
- Token-signing Certificate (public and private key pairs)
- The configured federated services (relying parties)
- Authorization rules, …
The ADFS Configuration database is a Windows Internal Database (WID), specifically a Microsoft SQL Server, usually applications can connect to Microsoft SQL Server databases via TCP/IP or a named pipe. A named pipe is used in the ADFS server.
The used pipe name in Windows Server 2012 and above is:
in previous server versions, its:
Now to get the encrypted certificate, the attacker needs to connect to the ADFS database, and execute the following select statement to retrieve it.
SELECT ServiceSettingsData from AdfsConfigurationV3.IdentityServerPolicy.ServiceSettings
This is a sample C# code to do that:
After the above code is executed the attacker will get the encrypted certificate, then he can decrypt it using the decryption key obtained earlier.
Therefore, blue teams needs to monitor the ADFS database activities ( db login/logoff, executed SQL queries …)
In the recent attacks, adversaries utilized the ADFSDump tool to dump out all the needed data to perform the Golden SAML attack, The following screen shot
shows the executed queries on the ADFS database by the ADFSDump utility.
if we look into the tool code, we can see its doing exactly those queries here:
There are several interesting artifacts here. First, there was a database login event by the administrator user, which is a suspicious one, as we don’t expect really anyone to connect to the ADFS database in the first place!
The login activity is followed by the execution of the above series of SQL queries, Its full of reconnaissance activities, retrieving the database name, token-signing certificate, access control rules, ...
This is the needed SQL query to get the token-signing certificate, and we have seen multiple ADFS certificate dumping tools executing the same query:
SELECT ServiceSettingsData from AdfsConfigurationV3.IdentityServerPolicy.ServiceSettings
This is another example of an ADFS dump utility, its based on PowerShell:
Enable the Auditing of the ADFS Database
Blue teams need to consider auditing the ADFS database to have a visibility into the executed SQL queries, Database logins, and other Database activities.
In this section, we will go over the needed steps to enable SQL auditing.
To enable the SQL audit on the ADFS database:
1. Open the Microsoft SQL Server Management Studio and login to the ADFS database as following:
2. Expand Security → audit →right click and choose new audit
3. Choose the path to determine the path of the local log file, where the logs will be saved in a binary format.
4. Create a new Server Audit Specification
From Security → Server Audit Specification → right click and choose new Server Audit Specification
**You might want to consider auditing more database activities, the above is just a sample for our proof of concept.**
5. Add the database Audit Specification, as follows:
notice we added the action type “Select” → to monitor any select SQL query.
6. Now we can right click in each one of the above created objects, and click enable.
The logs will be saved in a binary format or it can be saved in a shared network folder as well. We will use LOGbinder for SQL Server to read the local binary file, convert the events to a readable format, and forward them to QRadar.
The following screen shot shows the ADFSDump executed queries on the ADFS database detected by QRadar:
Putting it All Together
Security analysts needs to look for any unusual login activity, QRadar User Behavior Analytics app helps to profile the users behavior, detecting malicious and anomalous user behaviors help security analysts to detect different kind of attacks.
Security analysts also need to look for things like:
- Risky and suspicious users - using the QRadar UBA.
- The execution of any unusual processes.
- The execution of credential dumping utilities, like Mimikatz.
- The execution of any unusual PowerShell commands, especially commands like: Export-ADFSSigninCertificate, Get-AdfsCertificate, Export-PfxCertificate, export-certificate
- The execution of certutil -exportPFX
- To behaviorally hunt for the decryption key dumping process, as outlined in the above sections, where we will get an event 4662 about the retrieving the thumbnailPhoto attribute.
- Correlate the SAML authentication events between the identity and service providers, this XForce collection has a content pack that includes the needed correlation rules.
- To monitor the logins activity to the ADFS database
- To monitor the executed SQL queries in the ADFS database#QRadar#Featured-area-2#Featured-area-2-home