# CRXfiltrate Detection Rules

Companion detection rules for the CRXfiltrate research published by 7AI Threat Research.
Two YARA rules and three Suricata signatures cover the strongest static and network signatures in the campaign.

**Public research:** [https://7ai.com/crxfiltrate](https://7ai.com/crxfiltrate)
**Last updated:** 2026-05-13
**Author:** 7AI Security Engineering

---

## Package contents

| File | Purpose |
|---|---|
| `CRXfiltrate.yar` | YARA rules for static detection of extension code and captured payloads |
| `CRXfiltrate.rules` | Suricata signatures for network-layer detection of C2 traffic |
| `README.md` | This file |

---

## What the rules detect

### YARA (file-layer)

| Rule | Detects | Scan target |
|---|---|---|
| `CRXfiltrate_FakeHeader_CSP_Stripping` | Themed fake-header padding in declarativeNetRequest rulesets | Unpacked extension directories (`Extensions/<ID>/<version>/`) |
| `CRXfiltrate_Gen2_Payload_Code_Fingerprint` | Generation 2 production payload (`m3011.js` / `g105.js`) | Captured payload files; proxy-captured `text/javascript` blobs from operator infrastructure |

### Suricata (network-layer)

| SID | Detects |
|---|---|
| 9000001 | POST to `/alk/g2.php` on `statsdata.online` or `secdomcheck.online` (JavaScript execution backdoor) |
| 9000002 | GET to `re.php?mk=doublestat` on `lottingem.com` (C2 round-trip with URL-parameter exfiltration) |
| 9000003 | GET to `/500b-bench.jpg` on `ahacdn.me` subdomains (CDN connectivity probe; highest-signal indicator) |

---

## Quick start

### YARA

```bash
# Syntax check
yara CRXfiltrate.yar /dev/null

# Scan an installed Chrome profile (macOS)
yara -r CRXfiltrate.yar ~/Library/Application\ Support/Google/Chrome/Default/Extensions/

# Scan an installed Chrome profile (Windows, from WSL or scan-tool)
yara -r CRXfiltrate.yar /mnt/c/Users/<user>/AppData/Local/Google/Chrome/User\ Data/Default/Extensions/

# Scan a captured payload file
yara CRXfiltrate.yar /path/to/captured/m3011.js
```

### Suricata

```bash
# Syntax check (Suricata 8.x)
suricata -T -S CRXfiltrate.rules -l /tmp/

# Replay a captured PCAP through the rules
suricata -r capture.pcap -S CRXfiltrate.rules -l ./output/

# Inspect alerts
jq -r 'select(.event_type=="alert") | "[\(.alert.signature_id)] \(.alert.signature)"' output/eve.json
```

---

## Test results

Rules validated against the captured CRXfiltrate evidence corpus on 2026-05-13.

**YARA Rule 1** (themed fake-header CSP-stripping): scanned across 265 operator-adjacent extensions. 3 matches, all confirmed cluster members. Zero false positives.

**YARA Rule 2** (Gen 2 payload code fingerprint): fires on every captured Gen 2 payload variant: MVA v0910 `m3011.js`, NVA v3003 `m3011.js`, NVA v0302 `g105.js`. Zero false positives in the 265-extension corpus. The `privatelayer` and `hasD1Already` tokens specifically enable detection of the NVA v3003 release that the three original MVA-era tokens alone do not match.

**Suricata rules** (all three): compile clean on Suricata 8.0.4. All three fire correctly on synthetic plain-HTTP traffic matching the documented patterns. URI patterns verified against actual captured operator HTTP requests via tshark TLS decryption of the RF sandbox PCAPs.

---

## Deployment notes

**Hash-based detection is unreliable.** The operator applies per-victim template substitution to `m3011.js` and `g105.js` at delivery time. No two endpoints receive the same bytes. YARA Rule 2 targets stable string tokens that survive template substitution rather than fixed file hashes.

**Network exfiltration timing.** Suricata Rule 2 (SID 9000002) is the highest operational urgency. The `re.php` endpoint carries exfiltrated data in the request URL and delivers the payload in the response body in a single HTTP transaction. Response-blocking proxies do not prevent the exfiltration; the request URL with the visited domain and page title has already left the network before the proxy evaluates the response. DNS-tier or pre-connection blocking is required to stop the exfiltration.

**TLS visibility required.** Suricata rules fire on decrypted HTTP. In environments without SSL inspection in front of the IDS, the rules cannot see `lottingem.com` or `statsdata.online` HTTPS traffic. Pair with DNS-tier domain blocking on those hosts for environments without TLS inspection.

**Process scoping.** Expected source process for all three Suricata rules is `chrome.exe`, `msedge.exe`, or another Chromium-based browser. Any non-browser process contacting these IOCs warrants its own investigation as a different threat.

**Suricata version compatibility.** Rules target Suricata 8.x syntax (sticky-buffer chaining on Rule 2 via `distance:0`; `nocase` omitted on `http.host` in Rule 3 because Suricata 8.x normalizes that buffer to lowercase). For Suricata 7.x or earlier, adjust accordingly.

**Local validation.** Re-evaluate all five rules against your local extension corpus and historical proxy logs before treating them as production-blocking alerts. The "zero false positives" claim is bounded by a 265-extension corpus filtered for operator-adjacent categories (color pickers, ad blockers, volume boosters, screen capture tools, cursor themes, font tools, sound enhancers). False-positive rate against the broader Chrome Web Store is unmeasured.

---

## Rule identifiers

If you import these rules into your own ruleset, do not rename the YARA rule identifiers (`CRXfiltrate_FakeHeader_CSP_Stripping` and `CRXfiltrate_Gen2_Payload_Code_Fingerprint`). Downstream alert routing and dashboards key on the literal names.

Suricata SIDs (9000001 through 9000003) may be re-keyed to your local SID space if they conflict with existing rules.

---

## Coverage geometry

The two YARA rules and three Suricata rules are complementary, not redundant. YARA catches the extension at the file layer (before runtime) and catches the production payload at the file layer (after sandbox or proxy capture). Suricata catches the live network traffic that delivers the payload, exfiltrates browsing data, and probes the CDN. Both layers are needed for full coverage; deploying only one leaves the other half of the campaign undetected.

---

## Support and updates

- **Public research:** [https://7ai.com/crxfiltrate](https://7ai.com/crxfiltrate)
- **Technical questions:** security@7ai.com
- **Latest version:** contact your 7AI account team
- **Operator note:** the CRXfiltrate infrastructure is in active rotation. Re-verify rule effectiveness against fresh captures periodically.

---

## License and attribution

These rules are released under the same publication license as the CRXfiltrate research and may be redistributed with attribution. The cluster naming and the original CSP-stripping mechanism analysis are credited to Wladimir Palant ([palant.info](https://palant.info), January 2025).