ULTRA RED AI found that a fleet-telematics platform's SAML single sign-on endpoint accepted login assertions with no cryptographic signature at all. The SSO library only verified a signature if one was present - an assertion that simply omitted the <Signature> element was trusted unconditionally. Because the endpoint also accepted unsolicited SAML responses, there were zero prerequisites: no prior login flow, no credentials, no MFA, no interaction from the victim. To prove it end-to-end, ULTRA RED AI sourced a real employee's email off the company's own public blog and forged a valid session for that user. The same endpoint and the same misconfiguration were shared across all 25+ customer portals on the platform - every railroad on the service was one forged document away from full account takeover.
The Bug, in One Sentence
SAML's entire security model rests on one assumption: the assertion is signed, and the service provider verifies that signature. Break either half and the whole thing collapses. Here, the service provider verified signatures conditionally - only when a <Signature> element existed. Remove the element, and there was nothing to verify, so the document was accepted as authentic.
This is a signature-exclusion attack (sometimes called "signature stripping"), and it's exactly the kind of flaw a scanner can flag but can't finish - proving it requires forging a document, sourcing a real identity to put in it, submitting it, and interpreting the authentication result.
Why a Rule-Based Scanner Walks Right Past This
Give scanners their due: a good SAML test can catch the raw condition. Strip the <Signature> element, replay the assertion, watch the endpoint accept it, and emit "unsigned assertion accepted, possible misconfiguration." Detecting that one fact was never the hard part.
The hard part is what that fact is worth on its own: almost nothing. It lands in a backlog as an unvalidated, medium-severity note - one of hundreds, with no proof it's exploitable and no sense of blast radius. A dot on a page. The breach is the line connecting that dot to a real user and a real session, and drawing it is reasoning, not signature matching. Three connections a rule-based tool structurally can't make:
Sourcing a real identity. A forged assertion only authenticates as someone if it names a real someone. The scanner has no valid employee to assert, can't invent one the service provider will accept, and won't leave the target to go find one. ULTRA RED AI pivoted to the open internet, lifted a real employee's email off the customer's own company blog, and paired it with the issuer string recovered during recon.
Proving exploitability. "Accepts unsigned XML" is a hypothesis; "logged in as a named employee with a live session cookie" is a fact. ULTRA RED AI carried the forged document through to a validated, authenticated session, turning a maybe into a confirmed takeover with a working proof of concept.
Scoping the blast radius. A scanner evaluates one endpoint at a time. ULTRA RED AI reasoned that the same ACS endpoint and configuration backed all 25+ tenant portals, so one flaw meant every railroad on the platform was exposed, against any employee whose email could be sourced the same way.
Step 1 - Fingerprinting the SSO Flow
ULTRA RED AI identified the platform's ACS endpoint (/SSO.aspx) and recognized the SSO stack behind it - a commercial .NET SAML library. Two properties of the deployment stood out during recon:
The login redirect flow exposed the trusted identity providers' issuer strings - the public identifiers of, for example, an Azure AD tenant and an Okta org belonging to the platform's railroad customers. These aren't secrets; they travel in the clear as part of normal SAML.
The endpoint accepted unsolicited (IdP-initiated) responses, meaning it would process a SAMLResponse sent to it cold, with no prior AuthnRequest from the service provider. That removed the last technical prerequisite an attacker would otherwise need.
Step 2 - Sourcing a Real Identity From Company Files
A forged assertion is only as convincing as the identity it carries. A placeholder email proves nothing - to demonstrate a genuine account takeover, ULTRA RED AI needed a real employee of a real customer on the platform. So it did what a human attacker would: it left the target and turned to open-source intelligence.
Working from public sources - regulatory filings, conference proceedings, press releases, and professional profiles - ULTRA RED AI harvested a valid employee email address belonging to one of the platform's customers, and paired it with that customer's issuer string recovered in Step 1. That real identity is what converts a dry observation ("the endpoint parses unsigned XML") into a validated, end-to-end takeover of an actual user's account.
This is the step no rule-based scanner takes. It cannot correlate an asset to an organization, an organization to a named employee, and an employee to a live login, because it never leaves the asset. ULTRA RED AI treats the whole internet as in-scope for reconnaissance and the target as the place to validate - exactly the way a real adversary works.
Step 3 - Forging an Unsigned Assertion
With a real target identity in hand, ULTRA RED AI constructed a standard SAML response asserting that user - and simply left out the signature. Decoded and abbreviated, the forged document looked like this (note what is not there):
<samlp:ResponseVersion="2.0"Destination="https://<portal-host>/SSO.aspx"...><saml:Issuer>https://sts.windows.net/<tenant-guid>/</saml:Issuer><samlp:Status><samlp:StatusCodeValue="urn:oasis:names:tc:SAML:2.0:status:Success"/></samlp:Status><saml:AssertionVersion="2.0"...><saml:Issuer>https://sts.windows.net/<tenant-guid>/</saml:Issuer><!-- No <Signature> element anywhere in this document. --><!-- A legitimate response would carry a cryptographic signature here. --><saml:Subject><saml:NameIDFormat="...:emailAddress"><sourced-real-email></saml:NameID><saml:SubjectConfirmationMethod="...:bearer"><saml:SubjectConfirmationDataRecipient="https://<portal-host>/SSO.aspx".../></saml:SubjectConfirmation></saml:Subject><saml:ConditionsNotBefore="..."NotOnOrAfter="..."><saml:AudienceRestriction><saml:Audience>https://<portal-host></saml:Audience></saml:AudienceRestriction></saml:Conditions><saml:AuthnStatementAuthnInstant="..."><saml:AuthnContext><saml:AuthnContextClassRef>...:Password</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement><saml:AttributeStatement><saml:AttributeName="...:emailaddress"><saml:AttributeValue><sourced-real-email></saml:AttributeValue></saml:Attribute></saml:AttributeStatement></saml:Assertion></samlp:Response>
The document claims a trusted issuer (the customer's Azure AD tenant), the sourced employee's email as the identity, Password as the authentication method, and a validity window a few hours wide. It carries no proof of any of it, and it didn't need to.
Step 4 - One Request, Fully Authenticated
ULTRA RED AI base64-encoded the assertion and sent it, unauthenticated, straight to the ACS endpoint. No session, no prior redirect, no credentials:
POST /SSO.aspx HTTP/1.1
Host: <portal-host>
Content-Type: application/x-www-form-urlencoded
SAMLResponse=<base64oftheunsignedassertion-withheld>&RelayState=
The platform accepted the forged document as if it had come from the railroad's own identity provider and issued a live session:
Following the redirect landed ULTRA RED AI in the portal fully authenticated as the real target user (IsAuthenticated: true) - no password ever entered, no MFA prompt, and nothing that would appear anomalous to the railroad's own identity systems, because those systems were never touched.
Step 5 - Reasoning About Blast Radius
The finding didn't stop at one portal. ULTRA RED AI reasoned about the shape of the platform and confirmed that the vulnerable /SSO.aspx endpoint, the trusted-IdP configuration, and the library misconfiguration were shared across all 25+ customer portals on the platform. Every tenant, every railroad on the service, was exploitable through the same technique, against any employee whose email could be sourced the same way.
Impact Summary
Zero-Click Account Takeover
A single unauthenticated HTTP request and a publicly sourced email were enough to seize any employee's account - no password, no MFA prompt, no victim interaction of any kind.
Platform-Wide: 25+ Portals
The vulnerable ACS endpoint and misconfiguration were shared infrastructure. One flaw exposed every railroad customer on the platform, not just the one used to validate it.
Critical Infrastructure Visibility
A compromised session exposed live locomotive video, real-time fleet alerts, GPS positioning, telemetry, fuel data, and DVR downloads for the entire fleet tied to that account.
Invisible to the Real IdP
Because the forged assertion never touched the railroad's actual Azure AD or Okta tenant, none of it would appear anomalous in the customer's own identity provider logs.
The Takeaway
Signature-exclusion is a decade-old class of SAML bug, and it persists because it hides in a configuration default that looks reasonable ("verify signatures when present") and because the raw condition, even when a scanner flags it, reads like one more unvalidated note until someone connects it to a real identity and a real login. Catching it took more than crafting XML: it took recognizing the flow, forming the hypothesis, crossing to the open internet to source a real identity, forging the document around it, and validating a live login. That loop - recon, hypothesize, exploit, validate - is what ULTRA RED AI runs continuously across the external attack surface, and it's why this finding shipped with a real, validated proof of concept rather than a speculative "you may want to check your SAML config."
How ULTRA RED AI Detected It
ULTRA RED AI's SAML probe module noticed the ACS endpoint accepted an assertion stripped of its <Signature> element and flagged unsolicited-response handling on the same endpoint - two facts that, together, meant zero prerequisites for exploitation. Rather than stop at that observation, ULTRA RED AI pivoted to open-source reconnaissance, harvested a real employee email from the customer's public presence, forged a complete unsigned assertion naming that user, and submitted it live - validating a fully authenticated session end to end. It then reasoned across the platform's shared infrastructure to confirm the same flaw reached all 25+ tenant portals, and handed the research team a working proof of concept rather than a raw scanner alert.
