Chawkr logoChawkr

sidewinder

6 min read

Free

SideWinder's Click Once campaign - independent validation with ClusterHawk

We confirm Trellix's reporting on SideWinder's PDF ClickOnce chain and targets. Testing the method, we pivoted on VirusTotal-communicated IPs and separated CDN/search noise (about 85%) from a compact nginx micro-cluster (about 15%), then built ready-to-run SIEM/Sigma and Shodan/Censys hunts.

sidewinderaptclickoncephishingespionagec2-servershunting-queriesthreat-intelligenceinfrastructure-analysis
MU

By Marvin Uku

02/11/2025

TL;DR: We confirm Trellix's reporting on SideWinder's PDF → ClickOnce chain and targeting. We then intentionally added all "communicated-with" IPs linked to the verified malicious domains/IPs to see whether clustering could separate benign enrichment noise from real infrastructure. The result: about ~85% CDN/search baseline and a compact nginx micro-cluster (~15%) that's worth watching. Below are ready-to-run hunts (SIEM/Sigma + Shodan/Censys) and cluster fingerprints you can reuse as predictive seeds. (trellix.com)

What Trellix reported

  • Waves & targets: multi-wave operation in Mar-Sep 2025, including a European embassy (New Delhi) and public-sector entities in Sri Lanka, Pakistan, Bangladesh.
  • Tradecraft: a new PDF → ClickOnce infection chain (besides historic CVE-2017-0199/RTF), geofenced/time-locked stages, per-victim URLs & hashes, delivering ModuleInstaller → StealerBot.
  • Infra families (examples): hajjtraining2025.moragovt[.]net, cadetcollege.adobeglobal[.]com, hajjmedicalteam.adobeglobal[.]com, pimec-paknavy.updates-installer[.]store, cabinet-gov-pk.dytt888[.]net, adobe.pdf-downlod[.]com; C2 exosel[.]info & ostcone[.]site; sender *.pk-mail[.]org. (trellix.com)

Bottom line: Trellix is our content/TTP authority. We validated (and then enhanced) the infra picture by running their published IOCs through ClusterHawk's automatic pipelines and manually reviewing the results.

Dataset & the deliberate VT-pivot test

We combined Trellix-published SideWinder IOCs with a wide set of VT "communicated-with" IPs on purpose to test whether clustering can separate enrichment noise from real signal.

What ClusterHawk (Intermediate) produced:

  • Total clustered assets: 47 (plus 6 NIL excluded, these had no information available).
  • Five clusters, all with Good stability.
  • Distribution:
    • Cluster 0 (Akamai CDN): 20/47 (42.55%)
    • Clusters 1, 3, 4 (Google frontends): 10/47 (21.28%), 7/47 (14.89%), 3/47 (6.38%)
    • Cluster 2 (nginx micro-cluster): 7/47 (14.89%) → Legit baselines ≈ 85%, suspicious leads ≈ 15%.

Anomaly engine: 3/47 (6.4%) flagged: CRITICAL: 184.28.81.200; HIGH: 192.178.209.138, 184.30.148.76, all on Akamai/Google edges (monitor, don't enforce).

Did VT "communicated-with" IPs overlap real IOCs? Yes. 10/53 VT IPs overlapped the verified set: 5.230.33.233, 75.2.115.196, 84.32.84.32, 84.32.84.33, 89.46.233.190, 89.150.57.220, 91.195.240.19, 91.242.163.218, 198.177.120.54, 199.59.243.228.

Interpretation: great as pivot fuel, but most of the VT list fell into Akamai/Google baselines, exactly the behavior our method is designed to separate: pivot wide → filter with clustering.

Cluster profiles you can actually hunt

Cluster 0: Akamai CDN baseline (42.55%, 20 assets)

  • Server/WAF: AkamaiGHost + Kona SiteDefender (100%).
  • TLS/certs: TLS 1.3; JA3S 09eeaa98d62f95fb7de5342ec4f7a55e; JARM 27d27d27d29d27d21c42d42d000000996c218236a1fd203fd29824aa76026c; cert DigiCert TLS Hybrid ECC SHA384 2020 CA1; subject a248.e.akamai.net.
  • HTTP: 400 Bad Request on :80 (100%).
  • Global match: ~158,980 hosts (at time of analysis, ~Oct-Nov 2025) → not an IOC; use as allow-list fingerprint.

Pivotable seeds (copy/paste):

  • Elastic/Splunk (baseline allow-list): product:"AkamaiGHost" AND http.waf:"Kona SiteDefender (Akamai)" AND tls.ja3s:"09eeaa98d62f95fb7de5342ec4f7a55e" AND destination.port:443
  • Shodan/Censys (context discovery): product:AkamaiGHost http.waf:"Kona SiteDefender (Akamai)" org:"Akamai Technologies, Inc." ssl.ja3s:09eeaa98d62f95fb7de5342ec4f7a55e port:443

Clusters 1/3/4: Google frontends baseline (10/7/3 assets)

  • Traits: Google web server, HTTP 301 on :80 → :443; TLS 1.3; JA3S 66e33336e3e99f75410126f42d44cc81; JARM 29d3fd00029d29d21c42d43d00041df61f6b5fa6973e9fa14c8155669c6633; security.txt (Google VRP).
  • Global match: ~30,528 hosts (at time of analysis, ~Oct-Nov 2025) → baseline, not IOCs. Use to detect impersonation outside AS15169.

Pivotable seeds:

  • Impersonation hunt (Elastic/Splunk): tls.ja3s:"66e33336e3e99f75410126f42d44cc81" AND NOT dest.asn:"AS15169" AND NOT destination.domain:*.1e100.net
  • Shodan/Censys (HTTP-only variant with 301 + VRP text): http.status:301 http.securitytxt:"Contact: https://g.co/vulnz" org:"Google LLC" http.favicon.hash:708578229

Cluster 2: nginx micro-cluster (lead bucket) (14.89%, 7 assets)

  • What it looks like: nginx on port 80 with a strong 403/400 response bias, no TLS on 86% of assets, and no DNS hostnames observed (100%).
  • When TLS is present: TLS 1.3 + AES-GCM with JA3S b210411e648f206db393c31561686aea and JARM 3fd3fd00000000000043d43d00043dc3b2afa8a5ec09b510a8559aff7899fb.
  • Where it lives: mainly on Sedo Domain Parking, IONOS SE, and UAB Nacionalinis Telekomunikacijų Tinklas.
  • How we read it: Based on manual review, roughly ~40% looks like potentially malicious infra (throwaway staging/relay/C2) and ~60% looks like parking/misconfig. Treat these as lead candidates, not hard IOCs, and correlate hits with SideWinder-linked domains/paths.

Pivotable seeds (run these now):

  • Elastic KQL / Splunk (tripwire: investigation-only, no shorthand):

    destination.ip:* AND
not cidrmatch(destination.ip, ["10.0.0.0/8","172.16.0.0/12","192.168.0.0/16","127.0.0.0/8"]) AND
http.response.status_code: (400 OR 403) AND
http.response.headers.server: "nginx" AND
NOT (http.request.headers.host:* OR tls.server_name:*)

    Optional strengthening: also require no recent DNS A/AAAA resolution to that destination.ip in your DNS index (±10-30 min).

  • Sigma (portable)

    title: Nginx_Anonymous_403_400_NoHost_NoSNI
status: experimental
logsource:
  category: network
detection:
  sel_err:
    http.status|contains:
      - 400
      - 403
  sel_server:
    http.server: nginx
  sel_nohost:
    http.host|absent: true
  sel_nosni:
    tls.server_name|absent: true
  sel_public:
    destination.ip|cidr:
      - "!10.0.0.0/8"
      - "!172.16.0.0/12"
      - "!192.168.0.0/16"
      - "!127.0.0.0/8"
  condition: sel_err and sel_server and sel_nohost and sel_nosni and sel_public
level: high
tags:
  - attack.t1071.001
  - sidewinder.cluster2
  - infrastructure.anonymous
falsepositives:
  - enterprise egress proxies stripping SNI/Host
  - benign scanners (add allowlist)

  • Shodan/Censys (internet pivot): product:nginx (http.status:400 OR http.status:403) -ssl.cert.subject:* -dns:* (Tighten with the JA3S/JARM above when TLS appears.)

What matched Trellix

  • Same delivery/C2 families present in the Trellix IOC set and our verified set: adobe.pdf-downlod[.]com, cadetcollege.adobeglobal[.]com, hajjmedicalteam.adobeglobal[.]com, hajjtraining2025.moragovt[.]net, pimec-paknavy.updates-installer[.]store, cabinet-gov-pk.dytt888[.]net, mos-gov-bd.snagdrive[.]com, mofa-gov-bd.filenest[.]live, plus C2 exosel[.]info, ostcone[.]site, and sender *.pk-mail[.]org. Confirmed.
  • Why IP-only fails: Trellix shows geofenced, per-victim, short-lived URLs/hashes in a PDF→ClickOnce chain, so domain/URL-first enforcement is required; CDN/search IPs ≠ IOCs and should be enrichment only. (trellix.com)

What we added beyond Trellix

Building only on Trellix's published IOCs and campaign details, ClusterHawk contributed:

  1. Quantified separation: 47 clustered / 6 NIL / 5 clusters, with Akamai+Google ≈ 85% baseline vs nginx 15% leads; 3 anomalies on CDN/search (monitor).
  2. Provider fingerprints you can paste (Akamai & Google JA3S/JARM + headers/certs) to reduce FPs without trusting every CDN-hosted domain.
  3. Unique tripwire for the nginx pocket (no Host header + no TLS SNI + 400/403; optionally no recent DNS): zero global matches in our scan space → high-precision lead generator when SideWinder rotates.

Threat actor & infrastructure preferences

  • Targets: diplomats/public sector in IN (embassy in New Delhi), LK, PK, BD; Mar-Sep 2025 waves.
  • Delivery: PDF → ClickOnce (plus RTF/CVE-2017-0199 fallback); geofenced/time-locked second stages; per-victim URLs & hashes; ModuleInstaller → StealerBot toolset.
  • Infra tastes: disposable look-alike domains on commodity hosting/CDNs; sender *.pk-mail[.]org; plus a tiny anonymous nginx pocket (Cluster 2) that likely serves throwaway staging or abandoned/parked boxes. Infra sophistication: 3/10 (Low-Moderate).

Ready-to-use detections & playbooks

1. Baseline / Allow-list (noise control, not trust)

Akamai allow-list:

  • AkamaiGHost + Kona SiteDefender, TLS 1.3, cert subject a248.e.akamai.net, JA3S 09eeaa…, JARM 27d27d….

Google allow-list (baseline) + impersonation context:

  • Legit baseline: 1e100.net, HTTP 301→443, TLS 1.3, JA3S 66e333…, JARM 29d3fd…, security.txt present.

2. Hunting queries (investigate hits)

  • Impersonation hunt (Elastic/Splunk): same Google JA3S/JARM outside AS15169 and not *.1e100.net → triage.
  • Nginx tripwire: use the KQL/Sigma/Shodan pivots from Cluster 2 above as investigation triggers, not block lists.

3. High-confidence escalation conditions

Escalate the nginx tripwire when:

  • It co-occurs with known families adobeglobal / moragovt / dytt888 / updates-installer / snagdrive / filenest or with exosel.info / ostcone.site, or
  • It shows per-victim URL entropy and short-lived paths consistent with Trellix's ClickOnce flow.

Trellix IOC box (input to our pipeline)

Delivery/C2: adobe.pdf-downlod.com, cadetcollege.adobeglobal.com, hajjmedicalteam.adobeglobal.com, hajjtraining2025.moragovt.net, pimec-paknavy.updates-installer.store, cabinet-gov-pk.dytt888.net, mofa-gov-bd.filenest.live, mos-gov-bd.snagdrive.com, exosel.info, ostcone.site

Sender: mod.gov.bd.pk-mail.org (and related *.pk-mail.org addresses)

Note: Treat Akamai/Google/IONOS/Sedo IPs as context; enforce on domain/URL + behavior. (trellix.com)

Conclusion

  • Alignment: Our results confirm Trellix's story: same delivery/C2 families and ClickOnce tradecraft; IP reputation alone won't catch this.
  • Methodology proof: The VT pivot produced many edges; clustering baselined ~85% (Akamai/Google) and preserved a unique nginx lead cluster (~15%). That's exactly what ClusterHawk is meant to do.
  • What's new & usable: concrete pivot queries, baseline fingerprints, and a rare nginx signature that can catch the next rotation with high precision.

Reference we validated against

  • Trellix ARC: "SideWinder's Shifting Sands: Click Once for Espionage" (Oct 22, 2025). (trellix.com)
Free
clickfixnetsupport-ratesentire+6

ClickFix to NetSupport: Validating ClusterHawk, Cluster Profiles, and What's New

We seeded ClusterHawk with eSentire's published NetSupport indicators and clustered the infrastructure behind ClickFix delivery. The results validate against eSentire TRU's reporting and IoCs, and add a predictive WinRM signature plus anomaly-led IP triage.

MU

Marvin Uku

01/11/2025

Read Full Analysis

This content requires premium access. Subscribe for full threat intelligence reports and analysis.

Premium

Premium content

SILENTLOOM: A Reused Device Pool Behind a Quiet Microsoft 365 Password Attack

Premium access required

Free
eviltokensphishingdevice-code+7

EvilTokens: Device Code Phishing Goes Industrial

We fed 95 EvilTokens campaign IPs into ClusterHawk and mapped a four-tier architecture. It spans a Cloudflare CDN frontend, DocuSign/Exim backend hosting, a bridge cluster on Google Trust Services certs, Cobalt Strike C2 fronted through the CDN, and an unreported IoT layer of Hikvision/Dahua cameras.

MU

Marvin Uku

09/04/2026

Read Full Analysis

Comments (0)