A wave of security concerns has emerged around OneLogin’s Active Directory (AD) Connector after a security researcher revealed a series of technical vulnerabilities that could allow attackers to obtain sensitive authentication credentials.
This incident has triggered concern throughout the cybersecurity community, given the popularity of OneLogin as an identity provider for organizations seeking to manage and secure access across cloud and on-premises resources.
Using detailed analysis, the researcher demonstrated how flaws in the way the AD Connector stores and transfers sensitive information can be exploited to gain unauthorized access to user accounts and enterprise data.
Technical Details And Attack Scenarios
The OneLogin AD Connector is typically installed as a Windows service that integrates on-premises Active Directory environments with the OneLogin cloud platform.
The core functionality involves reading local configuration files and registry entries, then synchronizing domain users and credentials to the cloud.
However, the researcher found that crucial application files and logs are stored in predictable directories on the host system.
Sensitive configurations, such as the directory token, are kept in the Windows registry, making them accessible to local attackers or malware with low-level privileges on the Connector host machine.
With access to these credentials, an attacker can interact with OneLogin’s internal API endpoints and request additional configuration details tied to the compromised Connector.
One of the most significant risks is that the configuration API can return not only an API key but also cloud provider credentials and a base64-encoded SSO Identity Provider signing key. These credentials create a chain of vulnerabilities.
The signing key is particularly valuable because it allows the attacker to generate cryptographically valid single sign-on tokens.
By understanding the structure of the Connector and the APIs it uses, an attacker with the directory token can programmatically fetch configuration data, including the signing key, via well-documented HTTP endpoints.

Once this signing key is decoded, it can be used to generate valid JSON Web Tokens (JWTs) that impersonate any user within the targeted organization.
The attacker needs to construct a JWT with appropriate fields for expiration, issuer, audience, and the target user’s identity.
These values can also be obtained either through the compromised API or by analyzing Connector logs.
The attack is further amplified by the fact that the API also provides AWS credentials used by the AD Connector for log storage and other back-end functions.
The researcher demonstrated that by using these credentials, it was possible to interact directly with Amazon S3 buckets, upload or download logs, and even access data for other tenants if resource identifiers were insufficiently segregated.
A particularly troubling aspect of this vulnerability was the discovery of misconfigured S3 buckets, where the researcher was able to register a bucket used by a real OneLogin customer and start receiving their log files.
These logs contained details such as user attributes and directory tokens, further enabling privilege escalation and lateral movement within the victim’s environment.
Mitigation Strategies And Defensive Recommendations
After disclosure, OneLogin addressed these vulnerabilities by introducing better encryption for API communications and rectifying improper cloud resource permissions.
However, at the time of reporting, independent researchers had not yet validated these fixes.

Organizations using the OneLogin AD Connector should urgently assess their own deployments for exposure, ensuring that critical credentials are not accessible from other applications or users on the same system.
Security experts recommend treating identity federation and synchronization servers as the highest security tier, segregating them from less trusted network segments, and limiting access to only authorized administrative users.
Rotating all relevant API keys, signing keys, and cloud credentials is advised, as is reviewing all cloud storage configurations to ensure that only trusted entities can write or read logs.
Additionally, organizations should actively monitor for unusual log transfers and API activity, which might indicate unauthorized access attempts.
Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.