extuno
What detection rules does Extuno run on extensions and packages?
Extuno's static engine carries 1100+ rules spread across distinct threat categories. Each rule names a concrete code pattern, a severity, and the evidence to report, and new rules ship as YAML packs without touching the engine.
How do the 1100+ rules break down by category?
The catalog is dominated by leaked-credential detection, then a spread of behavior and capability rules. Rough counts by category:
- Secret and API-key detectors: 1000+ anchored patterns for cloud keys, tokens, webhooks, private keys, and connection strings.
- Malicious code and behavior: ~50 rules for exfiltration, miners, drainers, and dead-drop logic.
- Proxyware and PAC abuse: ~15 rules.
- Manifest surface and taint dataflow: ~10 each.
- Capability, MV3 abuse, credential theft, remote code, evasion, surveillance, covert C2: 4 to 8 rules each.
- Obfuscation and permissions: a handful each.
See the static analysis page for how these run without executing code.
Why are most rules secret detectors?
A shipped extension or package bundle frequently carries credentials the developer never meant to publish: build environment variables, service-account JSON, private keys, and provider tokens. Extuno's 1000+ secret detectors each anchor to a provider's distinctive token format, so the match is the credential itself, not a guess. The same engine doubles as a CI/CD secret scanner, where a leaked key has to be found, shown in full, and rotated. Every secret finding reports the file, the line, and the exact value so an analyst can grep for and revoke the leak. Anchoring to provider formats keeps the false-positive rate near zero.
What does taint dataflow detection add?
Single patterns miss multi-step attacks, so a subset of rules track data from a source to a sink within proximity. These taint rules fire when a sensitive source (cookies, auth-named storage, clipboard, keystrokes, form data, or an identity token) flows into a network sink. To stay precise, taint matching requires the source to precede the sink, suppresses sanitizer-wrapped flows, ignores known telemetry endpoints, and demands a dynamic argument so a static URL never trips. The result is a confirmed capture-and-send pattern rather than a bare API mention, which is what separates a credential stealer from an extension that merely reads a cookie.
How do capability, evasion, and C2 rules work?
Beyond raw code patterns, dedicated packs cover the techniques modern malicious extensions use. Capability and MV3 rules flag debugger attachment, disabling other extensions, dynamic content-script registration, and offscreen execution. Credential-theft rules catch Set-Cookie capture and unfiltered cookie harvests. Remote-code rules catch dynamic imports and remote WASM. Evasion rules catch long delay timers, geoip keying, and scheduled remote checks that escalate when paired with eval. Covert-channel rules catch WebRTC data channels, WebTransport, DoH lookups, and canvas-to-network exfil. Manifest rules catch broad externally_connectable, self-hosted update URLs, and unsafe CSP.
Why are rules written as YAML packs?
Detection coverage has to grow faster than the engine. Extuno's rules live in versioned YAML packs with a small set of matcher kinds (regex, manifest path, permission set algebra, entropy, taint, and correlate). Adding a rule means editing a pack and shipping golden fixtures, never changing the scoring engine. Each pack carries shared defaults so a large family of rules stays concise, and a ruleset version hash is recorded on every scan so a result is reproducible. This is the same design behind the methodology: detection scales by data, and weights stay outside the engine so scoring stays explainable.
How are rules kept from producing false positives?
Every rule ships with a positive fixture that must match and a negative fixture that must not. A regression gate asserts corpus precision and recall stay at 1.0, so a new rule that flags benign code fails the build. Standalone high-severity rules use near-zero-false-positive signatures; dual-use signals stay low or info and only escalate when they correlate with a second signal in the same file. Vendor-library noise is suppressed unless the file also carries a strong finding, which defeats the trick of pasting a library banner onto malware. Read risk scoring for how findings roll into a verdict.
{
"rule_id": "det.taint.auth_storage_to_network",
"category": "taint",
"severity": "high",
"file": "background.js",
"line": 142,
"evidence": "chrome.storage.local.get('authToken') -> fetch(url, {body})",
"why": "Auth token read then sent to a dynamic network endpoint",
"action": "Confirm the destination and rotate the token if exfiltrated"
}Frequently asked questions
How many detection rules does Extuno have?
The static engine carries 1100+ rules. Over 1000 of those are secret and API-key detectors; the remainder cover malicious code, taint dataflow, capability and MV3 abuse, credential theft, remote code, manifest surface, evasion, surveillance, covert C2, obfuscation, and permissions.
Can I add my own detection rules?
Rules are data-driven YAML packs, so coverage grows by adding packs rather than changing the engine. Each rule declares a matcher, a category, a severity, and the evidence to report, and ships with positive and negative fixtures that gate the build.
Do detection rules run on packages too?
Yes. The same static rules run across all 12 supported ecosystems: Chrome, Firefox, VS Code, JetBrains, Eclipse, Discord client mods, npm, PyPI, WordPress, Composer, and Maven. Package-specific signals like install-script execution are covered by their own rules on top of the shared catalog.
What does a detection rule report when it fires?
Every finding carries evidence: the file, the line, why the pattern is dangerous, and the recommended action. Secret findings show the full matched value so an analyst can locate and rotate the leak. A bare risk score with no evidence is never produced.
How do rules avoid flagging legitimate extensions?
Patterns are anchored to provider formats or precise signatures, dual-use signals stay low severity unless they correlate, and a regression gate keeps corpus precision and recall at 1.0. A rule that flags benign fixtures fails the test suite before it ships.