When the Phishing Kit Is a SaaS Free Trial: Tracking a 21-Tenant Freshdesk Credential-Harvest Campaign

A note on the indicators below: all hostnames and URLs in this post are defanged (hxxps[:]//, [.]) so nothing in the page is clickable. Re-fang them only inside an isolated analysis environment. The detection rules in §9 are deliberately left in working form so they can be copied straight into a mail gateway or SIEM.

TL;DR

A client forwarded us a phishing email impersonating them. The payload URL pointed to adminmessagess.freshdesk[.]com (note the double "s"). One urlscan.io pivot later, we found 21 Freshdesk tenants all serving the same "New Secure Message From Admin" credential-harvest page, active May–August 2026.

The actor's trick: register throwaway Freshdesk accounts with admin-themed names and abuse the platform's own SSO login as the credential-capture page — no bespoke phishing kit required. In August 2026 the campaign evolved to add a JS-obfuscated Cloudflare Pages second-stage redirector.

This post walks the investigation from email to campaign.

1. The email that started it

A security team at a UK service forwarded us a phishing sample their staff had received. The email impersonated a different UK practice and used a classic "secure message / shared file" lure:

You have been sent a secure email.

Click here — linking to:
hxxps[:]//adminmessagess.freshdesk[.]com/en/support/solutions/articles/158000458571-new-secure-message-from-admin

— by 07-23-2026 5:38 UTC-4 to view your message. After this date you must access the message via the attachment.

The red flags were immediate:

The payload URL was the only phishing indicator. The rest of the .eml was the legitimate forwarding chain plus some unrelated newsletter content — we stripped that out before analysis.

2. The payload: a stock Freshdesk login page

We mirrored the payload URL (GET-only). The first surprise: it's not a bespoke phishing kit. It's a stock Freshdesk "visitor portal" SSO login page on a real Freshdesk tenant.

Figure 1: The adminmessagess.freshdesk[.]com payload page. What looks like a "secure message" is actually a Freshdesk tenant's SSO login form.

What the victim actually sees is a Freshdesk-branded login form posting credentials to /auth/google_login (Google SSO) and offering "Continue with Facebook", "Forgot your password?", and an "Are you an agent? Login here" link. The credential-capture surface is Freshdesk's own legitimate auth flow — the actor didn't need to build a fake login form because Freshdesk provides one for free.

The mirrored HTML contained account metadata, embedded as a JSON blob in the page boilerplate:

account: {"id":5000061,"name":"shernandez","time_zone":"Pacific Time (US & Canada)","companies":[]}

A Freshworks account.id is exactly what Freshworks' abuse team needs to suspend a tenant — see §7 for the per-tenant values, and §3 for why the shernandez label in this particular blob is not the tenant owner.

3. The platform-plumbing rabbit hole (and why you should verify your IOCs)

The mirrored page also contained a cross-tenant OAuth chain that looked very interesting at first glance:

shernandez.myfreshworks[.]com/login
  ?client_id=451979510707337272
  &redirect_uri=hxxps[:]//chadhousing.freshdesk[.]com/freshid/authorize_callback
      ?hd=hxxps[:]//adminmessagess.freshdesk[.]com

Three IOCs that screamed "attacker infrastructure": a Freshworks IDP host, a second Freshdesk tenant, and an OAuth client_id. We almost filed them.

Then we verified. Probing Freshdesk's own vendor support tenant (support.freshdesk[.]com) and several unrelated tenants revealed they all use the same client_id=451979510707337272. It's Freshworks' platform-wide FreshID SSO client_id, not an attacker indicator. The *.myfreshworks[.]com host is wildcard DNS — shernandez is just the IDP shard label, not a unique owner name. And chadhousing.freshdesk[.]com is a platform SSO plumbing tenant with no phishing article.

A fourth indicator went the same way: vault-service.freshworks[.]com matched as campaign infrastructure and was retracted as platform plumbing on review.

Lesson: Verify every IOC before reporting. Four "interesting" indicators collapsed into platform plumbing under a few minutes of probing. If we'd reported them, the takedown request would have asked Freshworks to suspend their own SSO infrastructure.

We also re-probed the 21 "admin paths" the mirror tool flagged (/admin.php, /victims.php, /shell.php, /.env, etc.) in a separate, explicitly requested pass — admin-path probing is off by default in the pipeline. All returned identical 403 / 42106-byte responses. The body turned out to be a Freshdesk/Cloudflare WAF "Access Denied" interstitial ("your activity has triggered security systems") — a probe-wordlist artefact, not live admin panels.

4. The campaign: 21 tenants, one fingerprint

The breakthrough came from a single urlscan.io title pivot:

page.title:"New Secure Message From Admin"

The pipeline scored 27 candidate URLs, of which 21 rated high phishing likelihood across 21 distinct Freshdesk tenants, spanning May–August 2026. All 21 share the same article-title fingerprint and the same /support/solutions/articles/<id>-new-secure-message-from-admin* URL pattern. Vision analysis classified the shortlisted pages as brand_impersonation, credential_phishing or malware_delivery, all at high confidence.

On attribution, worth being straight about: the pipeline scores "is this malicious?" and "is this the same actor?" separately. All 21 pages score high on the first, these are phishing pages, no ambiguity. On the second, none of them clear the bar: 20 rate possible and tqgt.freshdesk[.]com rates unattributed. A shared article title, URL shape and Cloudflare hosting prove these pages are bad; they don't prove one operator runs all of them. It could be one actor rotating tenants, or a kit that several people are using the same way. For defenders it makes little difference,the detection fingerprint in §9 catches all of them either way.

Figure 2: adminupdates0001.freshdesk[.]com (2026-08-19, the newest tenant). Same lure, same Freshdesk SSO page.

The campaign spans multiple victim sectors. A selection of the tenants (full list in the IOCs section):

Figure 3: ddt-admin-mm-mayormedicalco.freshdesk[.]com — UK medical target. The article title includes the victim brand ("MayorMedical").

Figure 4: 9vvtadmincityofchicago.freshdesk[.]com — US local government target. The actor named the Freshdesk account after the impersonated victim.

Figure 5: ukadmindevall.freshdesk[.]com - UK legal sector. The "ukadmin" prefix is a campaign naming fingerprint.

It is important to note that just because these companies appear in the tenant names, and the Freshdesk domains have been set up, it does not mean they have been successfully phished or are compromised, only that they have been a target of this campaign.

One related candidate: vgcgroup.freshservice[.]com (article 41000000425, 2026-06-29) surfaced in the same sweep on Freshservice rather than Freshdesk. It did not reach the high-confidence tier and is not counted in the 21. It is worth watching, because the same abuse pattern applies to Freshservice tenants, see the §9 detection logic, which covers both platforms.

4.1 The naming fingerprint

The subdomain names the actor chose when registering each Freshdesk account fall into clear patterns:

• admin* / admn* / adminmessages / adminmessagess (double-s) / adminupdates
• cctadmin* / cctrd*
• ddt-admin-* / tamgmt* / hrsadmin*
• vvt7* / vvt17* / 9vvt*
• ukadmin* / ukadmn* (UK-targeted batches)

These prefixes are themselves a detection signal — a legitimate Freshdesk tenant is usually named after the company (e.g. acmecorp.freshdesk[.]com), not a generic admin-themed string.

4.2 The "Administartor" typo

At least two tenants carry the misspelling "Administartor" in their page title ukadmnfarmerj ("Administartor - Farmerj.com") and 9vvtsamedaydoctorco ("Administartor - Samedaydoctor.co.uk") — and the same typo appears in the Freshdesk account's account.name field:

account: {"id":10000013217,"name":"Administartor - Farmerj.com","time_zone":"London",...}

Figure 6: ukadmnfarmerj.freshdesk[.]com the "Administartor" typo is carried from the Freshdesk account setup into the public-facing article title. A kit/actor fingerprint.

This is an actor fingerprint: the typo was entered once when the Freshdesk account was created and propagated to every article title on that tenant. It suggests the actor reuses a template (or copy-pastes the account name) rather than setting up each tenant from scratch.

4.3 The article-ID clusters

Article IDs fall into four Freshworks ID ranges 158000* (May–July), 39000* (June–August), 68000* (June–July) and a single 10000* plus the 41000* Freshservice candidate noted above. This clustering suggests multiple account-registration waves, with each wave assigned an ID range by the Freshdesk platform.

4.4 The hosting picture

Every one of the 21 high-confidence URLs resolves to Cloudflare CLOUDFLARENET for all 21, and server: cloudflare on all 21. Two shared-IP clusters stand out: 12 of the URLs on 172.66.0.145 and 9 on 162.159.140.147.

Those IPs are not actionable indicators. They are Cloudflare anycast edge addresses fronting Freshdesk itself, shared with an enormous volume of legitimate traffic. They are useful as a clustering signal inside an investigation and useless actively harmful as a blocklist entry. Same discipline as §3: the shared infrastructure is the platform's, not the actor's.

5. The attack pattern

Piecing it together:

1. Register a Freshdesk trial account, choosing an admin-themed subdomain (adminmessagess, cctadmin-mikeluckwell, ukadmindevall, etc.).
2. Create a single help article titled "New Secure Message From Admin" (sometimes with a victim-name suffix, e.g. "…-mayormedical", "…-group-anaesthetic-services").
3. Spam the article URL as a "secure email / Shared a File" lure exactly the email we received.
4. Harvest credentials via Freshdesk's own SSO flow victims land on the tenant's login page and enter Google/Facebook/password credentials into the genuine Freshworks auth flow.
5. Rotate to a new tenant for the next batch.

Each tenant = one send batch. The article-per-tenant ratio is 1:1 across all 21 tenants. The credentials live in the Freshdesk tenant's legitimate auth logs takedown requires Freshworks to suspend the tenant and preserve those logs.

6. The August 2026 evolution: a second-stage redirector

The older 20 tenants (May–July 2026) have no separate actor backend they rely solely on Freshdesk's SSO for credential capture. But the newest tenant, adminupdates0001.freshdesk[.]com (2026-08-19), contains something new.

Buried in the article body is a "download document" button image wrapped in a link to an attacker-controlled Cloudflare Pages host:

<a href="hxxps[:]//admin-rvyfl6ai-69zjfu.pages[.]dev" rel="noopener noreferrer" target="_blank">
  <img src="hxxps[:]//i.postimg[.]cc/s2K7d9Rb/downloaddoc.png" ...>
</a>

The pages[.]dev host is a JS-obfuscated redirector:

const TAG = ""; (function(){
  var K="TjbITFNvmNuiqHtgoH0Nfv7se1KegcB7BEcHLV6uUxw=",
      V="HBf1RUywj62XJzItMxAFJg==",
      D="B1fqOXd5swWGUH2RSmwO+uKlKlDDdtMEzMDZ5DagWLyAlxF5uc/Zzi/J6lxQ..."
  // ... atob() + client-side crypto + window.open()
})();

The K, V, D variables hold AES-encrypted blobs (~33 KB of ciphertext). The redirect destination is decoded at runtime in the browser it cannot be extracted statically without executing the JS. urlscan.io captured the page with title "Redirecting":

Figure 7: admin-rvyfl6ai-69zjfu.pages[.]dev a JS-obfuscated redirector on Cloudflare Pages. The redirect destination is AES-encrypted and decoded at runtime.

This is not Freshdesk/Freshworks/Froala boilerplate. It is actor-controlled second-stage infrastructure. The random subdomain (admin-rvyfl6ai-69zjfu) follows Cloudflare Pages' auto-generated project naming. The postimg[.]cc image URL is a Froala editor default (the Freshdesk rich-text editor uses Froala), so the actor reused a placeholder image that was already in the Freshdesk article editor's defaults — a small opsec convenience.

Campaign evolution implication: the actor added the pages[.]dev second stage in mid-August 2026, possibly to deliver a more effective credential-harvest page than the Freshdesk SSO login, or to deliver malware — consistent with vision classifying the 9vvtsamedaydoctorco tenant as malware_delivery rather than brand_impersonation. We did not execute the JS to decode the redirect destina tionthat's a job for a sandboxed detonation environment, not a passive-OSINT investigation.

7. Per-tenant account metadata (for takedowns)

We mirrored 10 of the 21 tenants (GET-only, analyst-selected) and extracted the embedded Freshworks account metadata from each. All share the same data_pipe_key (a Freshworks platform key), confirming they're on the same platform. The account.id values are what Freshworks abuse needs to suspend each tenant:

Note: ukadmnfarmerj is the only tenant with time_zone: London; all others use the Freshdesk default (Pacific Time). The actor didn't bother changing the timezone except once.

8. Why this works (and why it's hard to stop)

The actor has found a sweet spot in the SaaS-abuse design space:

1. Free infrastructure. Freshdesk trials are free to start. No hosting to pay for, no domains to register, no TLS certs to manage. Cloudflare fronts everything.
2. Legitimate auth flow. By abusing Freshdesk's own SSO login as the credential-capture page, the actor gets a real, functional login form for free no kit development, no HTML/CSS work. The form posts to a real Freshworks endpoint.
3. Rotate-per-batch opsec. One article per tenant, one tenant per send batch. When a tenant gets reported, the actor has 20 more ready.
4. Typosquat subdomains. Freshdesk allows arbitrary subdomain names on signup. adminmessagess (double-s) looks plausible in an email and isn't an obvious red flag to a busy recipient.
5. Hard to block wholesale. You can't wildcard-block *.freshdesk[.]com it's a widely-used legitimate support platform used by thousands of companies. The detection signal has to be the article-title + URL-path fingerprint, not the domain, and certainly not the shared Cloudflare IPs from §4.4.

The weakness in the actor's model is the fingerprint consistency: every tenant uses the same article title ("New Secure Message From Admin"), the same URL path shape, and the same admin-themed subdomain naming. One urlscan title pivot surfaces the entire campaign.

9. Detection

The rules below are left in working (non-defanged) form so they can be copied straight into tooling. They deliberately cover Freshservice as well as Freshdesk see the related candidate in §4.

urlscan.io pivots (for continued monitoring)

page.title:"New Secure Message From Admin"
page.body:"You have been sent a secure email"
page.body:"new-secure-message-from-admin"

Mail-gateway detection (pseudo-Sigma)

title: Phishing — Freshdesk "New Secure Message From Admin" Secure-Message Lure
description: Credential-harvest phishing abusing Freshdesk tenant SSO pages
logsource:
    product: email
detection:
    selection_url:
        body|contains:
            - "/support/solutions/articles/"
            - "new-secure-message-from-admin"
    selection_domain:
        url|endswith:
            - ".freshdesk.com"
            - ".freshservice.com"
    selection_lure:
        body|contains:
            - "You have been sent a secure email"
            - "Shared a File"
    condition: selection_url and selection_domain and selection_lure
level: high

Web-proxy block

Block any *.freshdesk[.]com / *.freshservice[.]com URL matching /support/solutions/articles/*new-secure-message-from-admin*.

Do not wildcard-block all of *.freshdesk[.]com, and do not block the Cloudflare IPs in §4.4.

10. IOCs

All indicators below are defanged. Re-fang only in an isolated analysis environment.

High-confidence campaign tenants (21)

adminmessagess.freshdesk[.]com
adminupdates0001.freshdesk[.]com
ddt-admin-mm-mayormedicalco.freshdesk[.]com
duncan-owen-workspaceco.freshdesk[.]com
nick-roditi4nroditi.freshdesk[.]com
cctadmin-mikeluckwell.freshdesk[.]com
cctadmin-groupanaestheticsco.freshdesk[.]com
tamgmtmarquiscompanies.freshdesk[.]com
thebrooksurgery.freshdesk[.]com
gaa.freshdesk[.]com
9vvtadmincityofchicago.freshdesk[.]com
hahealth.freshdesk[.]com
ukadmnfarmerj.freshdesk[.]com
ukadmindevall.freshdesk[.]com
9vvtsamedaydoctorco.freshdesk[.]com
vvt17outsecco.freshdesk[.]com
cctrdintergenchildcare.freshdesk[.]com
hrsadmin.freshdesk[.]com
vvt7-hollanderlaw.freshdesk[.]com
ffrotr.freshdesk[.]com
tqgt.freshdesk[.]com          (malicious, but attribution: unattributed)

Related candidate (not counted in the 21)

vgcgroup.freshservice[.]com   (Freshservice, candidate tier — monitor, do not action as campaign)

Second-stage redirector (August 2026 evolution)

admin-rvyfl6ai-69zjfu.pages[.]dev         (Cloudflare Pages, JS-obfuscated redirector)
i.postimg[.]cc/s2K7d9Rb/downloaddoc.png   (Froala default placeholder image reused in the lure article)

URL fingerprint

hxxps[:]//*.freshdesk[.]com/support/solutions/articles/*-new-secure-message-from-admin*
hxxps[:]//*.freshservice[.]com/support/solutions/articles/*

Freshworks account IDs (for abuse reports)

adminmessagess:                 account_id=158000270779
adminupdates0001:               account_id=39000053135
cctadmin-groupanaestheticsco:   account_id=68000049786
duncan-owen-workspaceco:        account_id=68000050195
hrsadmin:                       account_id=68000040722
tamgmtmarquiscompanies:         account_id=158000268608
ukadmnfarmerj:                  account_id=10000013217

NOT IOCs (platform plumbing — do not action)

shernandez.myfreshworks[.]com     — Freshworks FreshID IDP (wildcard *.myfreshworks[.]com)
chadhousing.freshdesk[.]com       — platform SSO plumbing tenant
client_id=451979510707337272      — Freshworks platform-wide SSO client_id
vault-service.freshworks[.]com    — Freshworks platform service (matched, then retracted)
172.66.0.145                      — Cloudflare anycast edge (12 campaign URLs, plus the rest of the internet)
162.159.140.147                   — Cloudflare anycast edge (9 campaign URLs, plus the rest of the internet)

11. Methodology and tools

This investigation was conducted entirely with passive OSINT — no forms submitted, no credentials entered, no bot protection bypassed. The pipeline:

1. Email analysis manual .eml parsing to separate the phishing lure from the legitimate forwarding chain and unrelated newsletter content.
2. phishing-tracker pipeline (own inhouse tool) — LLM marker extraction, query generation, passive pivots, scoring, screenshot download, vision-model analysis, clustering, audit-gated reporting.
3. Site mirroring GET-only wget mirrors of 10 analyst-selected tenants for source-code analysis. Ten sites were shortlisted on explicit content evidence; no site is mirrored without explicit analyst selection, and admin-path probing stays off unless separately requested.
4. Manual verification every "interesting" IOC was verified by probing Freshdesk's own vendor tenant and multiple unrelated tenants before being reported. Four platform-plumbing false positives were retracted.
5. Grounding discipline every candidate carries both a confidence tier (candidate/probable/high/confirmed) and an evidence state (direct/corroborated/correlative/inferred). Maliciousness and attribution are scored separately: page title, URL structure, shared hosting, reputation and vision affect maliciousness only, and a malicious page defaults to unattributed until a qualifying published IOC, campaign backend, source/hash match, distinctive fingerprint overlap or analyst-confirmed linkage exists. The pipeline's audit gate passed (deterministic consistency and attribution-policy checks). No LLM/vision prose is asserted as fact without tool evidence.

Passive sources 127 queries across five sources. Only two produced anything:

Worth noting for anyone building similar tooling: Certificate Transparency and Wayback contributed nothing here, because the actor never registered a domain the tenants live under *.freshdesk.com, whose certificate is Freshworks' problem, not the actor's. SaaS abuse quietly removes CT from your pivot toolkit.

12. Confidence summary

Acknowledgements

Thanks to the UK client security team for forwarding the original sample, and to the internal team for reporting it when the email was received. Fast internal reporting is what made this investigation possible.

If you're a Freshworks/Freshdesk customer and want to verify whether your tenant is being abused, run the urlscan.io pivot in §9 against your own subdomain. If you're a defender at one of the victim organisations named in the tenant list, feel free to reach out for the full per-tenant report.

Comments, corrections, and additional tenant sightings welcome.