OneLogin, Many Issues: How I Pivoted from a Trial Tenant to Compromising Customer Signing Keys

TL;DR OneLogin was found to have security vulnerabilities in its AD Connector service that exposed authentication credentials and enabled account impersonation. This research showed that attackers could access credentials and signing keys to generate valid JWT tokens, allowing user impersonation. Leaked AWS credentials allowed SpecterOps to register an unclaimed S3 bucket referenced in the OneLogin API that began receiving logs from a OneLogin customer. These logs leaked the customer API key that can be used to obtain the signing key and generate valid JWT tokens, enabling arbitrary user impersonation.

What is OneLogin?

OneLogin markets themselves as a “Market-Leading Identity and Access Management Solution”. Essentially, OneLogin is an identity solution that provides single sign-on (SSO), multi-factor authentication (MFA), and user-provisioning for cloud and on-premise applications. The product provides directory integrations with existing identity management systems like Active Directory, AWS Identity Center, Azure, GSuite, etc. For the purposes of this post, we will be looking at the Active Directory integration.

Fortunately, as a security researcher, there are two factors at play that aid our research efforts:

1. OneLogin has a great free trial program that gives potential customer’s a tenant to review features and functionality of the product
2. OneLogin Active Directory integration utilizes .NET binaries when integrating an on-premises Active Directory. This enables much faster disassembly and analysis with decompilation tools like dotPeek

Other Research

Before we get any further, I wanted to highlight Adam Chester’s (@xpn) public research on Identity Providers (IdPs), including OneLogin. You can find his amazing blog post here: https://blog.xpnsec.com/identity-providers-redteamers/.

A lot of the research done in this blog post builds on his excellent research. so if you haven’t read his post yet I would encourage you to check it out before continuing.

Lab Setup

The diagram above details the lab that I configured for this research. I was able to request a OneLogin trial tenant for a domain I control (i.e., inspired-sec.us) directly from OneLogin: https://www.onelogin.com/free-trial. Once I created a trial tenant, I deployed a small domain with one user and two hosts inside my Ludus lab. This small domain included one domain controller (DC) running the OneLogin AD Connect service, ConnectorService.exe, and a single Windows 11 workstation.

Setting up the AD Connector for OneLogin is relatively simple; I just followed the instructions posted here: https://onelogin.service-now.com/support?id=kb_article&sys_id=d02f849d971e1650c90c3b0e6253af88&kb_category=ff57e170db185340d5505eea4b961929

Essentially, you download the AD Connector installer and install it with the provided token. After installation completes, AD Connector will default to syncing all users in the current domain. From this point, I decided to add an application that federates authentication to an AWS account, but that isn’t necessary.

Local Analysis of the OneLogin AD Connector

Installation makes a few changes on the host that we can capture with the Sysinternals tool Procmon.exe. Of these changes, I found the following worth investigating:

• Application files are written to C:\\Program Files (x86)\\OneLogin, Inc\\OneLogin Active Directory Connector\\
• Logs are written to C:\\ProgramData\\OneLogin, Inc\\logs\\
• A service named OneLogin Active Directory Connector is created that executes ConnectorService.exe
• Registry keys are written to HKEY_LOCAL_MACHINE\\SOFTWARE\\WOW6432Node\\OneLogin, Inc.\\Active Directory Connector

Based on Adam’s previous research, you can use that directory token to obtain more credentials from OneLogins API endpoints. OneLogin exposes a configuration endpoint (i.e., https://api.onelogin.com/api/adc/v4/configuration) that returns the configuration of a given directory. Adam Chester’s (@xpn) public research shows us how to interact with this endpoint. A HTTP GET api call is made to the configuration endpoint with the following URL parameters:

• version — Set to the agent version
• token — Set to Directory Token taken from registry
• mux — Set to 1
• directory_token — Directory Token taken from registry
• directory_id — Directory ID of the OneLogin tenant
• adcVersion — Also set to the agent version

I was able to pull the following information from my trial tenant:

Reviewing this response, there are a number of things that stand out:

• Another API key is exposed under <api_key>
• AWS AKIA User credentials are returned in cleartext
• The SSO_IDP configuration is returned with a base64 <signing_key>

Wait… are those real credentials?

It looks like there are three different credentials in that API response, so let’s go through them one by one.

API Key

The API key exposed in this API call is separate from the directory token and can be used to obtain more information about the OneLogin directory that you may find useful in the future. For our purposes, we will use another endpoint Adam documented in his research: https://api.onelogin.com/api/adc/v4/users .

A HTTP GET api call is made to the users endpoint with the following URL parameters:

• api_key — API key returned from the configuration endpoint mentioned above
• directory_id — Set to Directory Token taken from registry
• directory_token — Directory Token taken from registry
• adc_version — Also set to the agent version

It should return a list of users in the directory.

In my test tenant, there is only one synced user (i.e., onelogin); however in most environments, this would contain all registered users synced to the OneLogin directory.

Signing Key

Reviewing the response from the configuration endpoint, it seems to be returning the SSO IdP configuration for the directory integration:

This configuration includes a base64 value labeled signing_key. If we can reverse engineer the ConnectorService.exe application to identify how it crafts JWT tokens, we can potentially craft our own matching JWT tokens. Good thing ConnectorService.exe is a .NET binary. We can disassemble it to code and identify exactly how it is crafting JWT tokens.

Based on the disassembled code, it was easy to identify that the fields the JWT token requires are as follows:

• exp: (Token Expiration)
• iss: (Token Issuer) In this case, the directory the token was crafted for
• aud: (Audience) the audience for this token is the OneLogin account number
• sub: (Subject) this is a custom identifier for each user synced with OneLogin

The OneLogin account id and the directory id are both returned by the previous API call to the /configuration endpoint. The subject value is returned by the /users endpoint as the external id. I built a short python script to compile valid JWT tokens. This script can be found on github here: https://github.com/n0pe-sled/OneLogin-JWTGen

With a valid JWT, all that is left is to authenticate to the SSO consumer URL exposed in the SSO IdP configuration. Copy the encoded JWT into the following request and then follow all the redirections until you are authenticated to the SSO portal as the impersonated user.

POST /trust/onelogin-sso/jwt?account_id=<target account id> HTTP/2

Host: <Onelogin Tenant Url>

User-Agent: ADC 5.1.8

Content-Type: application/x-www-from-urlencoded

token=<Encoded Token>

AWS Access Key

When I see AWS AKIA credentials, I can confirm they are valid with: aws sts get-caller-identity

Okay, so those credentials are valid. The next reasonable thing to check is if we can read the logs in S3:\\onelogin-adc-logs-production. Trying to list this bucket fails and the error in the response says the bucket doesn’t exist:

An error occurred (NoSuchBucket) when calling the ListObjects operation: The specified bucket does not exist

After realizing that S3 bucket was available, I quickly claimed it on a personal AWS account. I then opened the bucket permissions to allow the adc-logs-put-production user write access.

Compromising another OneLogin Customer

In mid-February, I began receiving log files from another customer’s production OneLogin tenant in the S3:\\onelogin-adc-logs-production S3 bucket. These adc.log files contained detailed information about the customer’s environment, including LDAP properties for all users synced with OneLogin and a valid directory token.

OneLogin has not communicated why these logs were being sent to my bucket or how widespread this issue was. However, using the directory token and information from the adc.log files, I was able to:

• Obtain a list of currently enrolled users in the customer’s tenant
• Retrieve the valid signing key for the customer’s OneLogin Tenant
• Craft valid JWT tokens for the customer’s OneLogin Tenant for any of the previously identified users

At this point, I had the ability to impersonate arbitrary users for the customer’s OneLogin tenant and access any applications assigned to the respective user. At this point, I escalated my vulnerability disclosure to OneLogin.

This customer has been informed and I have been working with OneLogin to disclose the vulnerabilities discussed in this post.

Defensive Guidance

Identity federation platforms like OneLogin should be classified and protected as Tier 0 assets within your environment. These systems are high-value targets; if compromised, they can provide attackers with broad and potentially unrestricted access across your organization.

To reduce risk exposure, implement strict network segmentation and access controls. Only explicitly authorized hosts should be permitted to communicate with OneLogin API endpoints or any systems running the AD Connect service for directory synchronization.

As of the time of this writing, OneLogin has stated that it has addressed previously disclosed vulnerabilities by introducing encryption mechanisms that affect API interactions. However, these mitigations have not yet been independently validated.

Disclosure Summary and Timeline

December 9, 2024 — Disclosure submitted through https://support.quest.com/contact-us/report-security-vulnerability

December 10, 2024 — Initial disclosure acknowledged

December 11, 2024 — Asked for access to ticketing platform to track ticket status

December 11, 2024 — Support instructed me to follow the ticket’s status through my OneLogin account manager

December 11, 2024 — Reiterated that I am not a customer nor do I have an account manager

January 8h, 2025 — I requested a status update

January 13, 2025 — OneLogin informed me that they closed the ticket and created a Jira ticket with a potential fix that I could track through an account manager

January 27, 2025 — I identified a OneLogin customer support phone line and attempted to obtain information about the security report, including progress toward implementing a fix. I also reopened the ticket and OneLogin informed me that I would receive an update via email

January 29, 2025 — Having not received an update, I asked again via email and reiterated that I am not a customer and do not have access to an account manager

January 29, 2025 — OneLogin replied, stating that all fixed tickets are noted in release notes of each new release, and advised me to monitor new releases for my ticket number to confirm if it has been fixed

February 7, 2025 — The case closed again without additional updates

February 13, 2025 — OneLogin customer data was uploaded to S3:\\onelogin-adc-logs-production [issue occurred independently]

February 25, 2025 — After previous channels proved ineffective, I contacted a OneLogin employee directly through LinkedIn requesting escalation of my report to the security team. Report resubmitted

February 25, 2025 — The OneLogin security team acknowledged my report

February 26, 2025 — Secure file share established to transfer log files and tools used to generate JWT tokens

February 27, 2025 — Received direct phone call from security team regarding the scope of leaked customer data and to arrange transfer of S3 bucket ownership

February 28, 2025 — Video call with security team demonstrating vulnerability and transferring ownership of the S3 bucket to OneLogin

March 17, 2025 — Followed up with OneLogin about the vulnerability and AWS keys that had not been rotated. Security team confirmed they were working on a permanent fix to remove vulnerable functionality entirely rather than just rotating the AWS keys

April 17, 2025 — Followed up with OneLogin requesting current status of the fix

April 28, 2025 — OneLogin responded stating they missed my previous inquiry and committed to providing information shortly

May 14, 2025 — Followed up with OneLogin after receiving no response to previous update request. OneLogin responded stating they would release a fix that week

May 19, 2025 — Followed up with OneLogin requesting trial tenant reactivation to verify the new release resolved the issue

May 21, 2025 — OneLogin responded stating they would investigate and follow up

June 2, 2025 — After no further response from OneLogin, I informed them of my intent to publish this blog post. Reiterated willingness to perform validation testing and requested additional details about the deployed fix

June 9, 2025 — OneLogin provided an update stating the vulnerability has been remediated. OneLogin confirmed they addressed the cloud information issues within the vulnerable API and implemented encryption components that affect API access