The Certificate Validation Path That Became a Credential Harvester

The email arrived from the organization's own ticketing system. The From address was an internal IT alias. The subject line carried the organization's tag prefix and a ticket number. To anyone scanning their inbox, this looked like an internal notification routed through their own help desk.

The body contained a DocuSign-style e-signature lure. "VIEW COMPLETED DOCUMENT." A fabricated security code: A6756F11989F4294AD8256DB8CB89D713. Clean formatting. The kind of notification that passes through inboxes hundreds of times a day at organizations that use e-signature workflows.

The link behind the button resolved to google[.]it. From there, it redirected to a path that most URL reputation systems would never flag.

The ACME Challenge Path

Let's Encrypt and other certificate authorities use the ACME protocol to validate domain ownership during TLS certificate issuance. The standard process works like this: the certificate authority tells the domain owner to place a specific file at /.well-known/acme-challenge/[token]. The CA checks for the file, confirms the requester controls the domain, and issues the certificate.

The .well-known/acme-challenge/ directory is infrastructure. It exists for automated certificate validation. It is not meant to serve web pages, host applications, or deliver content to end users.

The attacker registered jrinnovativesolutions[.]us in July 2025, obtained a TLS certificate (proving control of the domain through the ACME challenge process), and then repurposed that same .well-known/acme-challenge/ path to host the credential harvest page. The full destination URL resolved to jrinnovativesolutions[.]us/.well-known/acme-challenge/rss/.

This is MITRE ATT&CK T1608.005 (Stage Capabilities: Link Target). The attacker prepared infrastructure specifically for credential collection, using a path that carries implicit trust in URL scanning systems. Many web application firewalls, URL reputation feeds, and security crawlers exclude .well-known paths from inspection because flagging certificate validation infrastructure would generate false positives at scale. The attacker exploited that gap.

The registrant information for the domain was not privacy-shielded. The WHOIS record listed a name and a Gmail address (innovatives637@gmail[.]com). Whether that identity is real or fabricated is secondary. The domain served its purpose as a disposable credential collection endpoint.

See Your Risk: Calculate how many threats your SEG is missing

The Google Redirect Layer

The CTA button in the email did not link directly to the harvest domain. It pointed to google[.]it/url?q=... with the destination URL passed as a query parameter.

Google's URL redirect service is one of the most commonly abused redirect mechanisms in phishing campaigns, and for good reason. The domain the scanner evaluates first is google.it (or google.com, depending on the variant). Google is on every allowlist. It has maximum reputation. A URL scanner that evaluates the first hop and stops there marks the link as clean.

The redirect resolves to the attacker's domain on the second hop. By the time a sandbox follows the full chain, it is evaluating jrinnovativesolutions[.]us/.well-known/acme-challenge/rss/, a path that itself carries the implicit trust of certificate infrastructure.

Two layers of trust laundering. One from Google's redirect service. One from the ACME challenge path convention. The credential harvest page sitting at the end of both layers was the only thing that needed to look convincing.

The Internal Delivery Problem

This email did not arrive from an external sender. It was processed through the target organization's own Exchange environment. The authentication status showed it as internal mail, meaning it bypassed the SPF, DKIM, and DMARC checks that apply to inbound email from external sources.

The From address used the organization's internal IT ticketing alias. The subject line carried the organization's group tag and a ticket number, formatted identically to legitimate internal notifications. A recipient scanning the From field and subject line would see what appeared to be a routine IT ticket update.

The Reply-To header revealed the compromise. The From domain was the organization's primary domain (geegroup[.]com, registered since 2004). The Reply-To pointed to geegroup[.]rmmservice[.]com, a subdomain on a completely different domain associated with remote monitoring and management (RMM) tooling. That split, same organizational name but different domain, is the kind of detail that gets missed when defenders focus on the From field alone.

The email also contained unrelated padding: a YouTube link and a Facebook page link that had no connection to the e-signature lure. These serve a dual purpose. They dilute the ratio of malicious-to-benign links in the message body (a metric some detection systems weight), and they add visual noise that makes the email feel more like a forwarded thread than a targeted attack.

What the Scanners Said

The scanner verdict on this email was Clean.

That verdict reflects the challenge. The email originated internally, so external authentication checks did not apply. The Google redirect presented a trusted first-hop domain. The ACME challenge path carried implicit reputation from its association with certificate infrastructure. The DocuSign-style template was visually consistent with legitimate e-signature notifications. The fabricated security code added authenticity padding.

Themis evaluated the behavioral context and flagged the campaign at 50% confidence. That score reflects the ambiguity: the internal delivery path raised the baseline trust level, and the absence of a clearly malicious URL on the first hop limited the confidence of link-based signals. The Reply-To mismatch and the first-time appearance of the e-signature lure pattern from this internal alias were the signals that pushed it above the detection threshold.

Four mailboxes were affected.

The Infrastructure Lifecycle

This attack mapped two techniques from the MITRE ATT&CK framework: T1566.002 (Spearphishing Link) for the delivery mechanism and T1036 (Masquerading) for the DocuSign brand impersonation.

The infrastructure lifecycle tells a clear story. Domain registered July 2025. TLS certificate obtained through the ACME challenge process (validating domain control). Certificate validation path repurposed as a hosting location for the credential harvest page. Google redirect configured to mask the destination. E-signature lure template deployed. Campaign launched through a compromised internal ticketing system.

Each step was designed to pass a specific layer of automated inspection. The internal delivery bypassed authentication. The Google redirect bypassed URL reputation. The ACME path bypassed web content scanning. The DocuSign template bypassed visual inspection.

The detection surfaces that remain are behavioral. Reply-To domain mismatches. Internal aliases sending e-signature lures for the first time. Links that resolve through multiple hops to paths associated with infrastructure tooling rather than document signing. These are the signals that catch what the scanner stack was designed to trust. Community intelligence across thousands of organizations helps surface these patterns faster than any individual security team can.

---

Indicators of Compromise