Kit signature: matching a page against known phishing kits

What a kit signature is

A phishing kit is a packaged set of files an attacker drops onto a compromised site: the cloned login page, the credential exfiltration script and a loader. Because the same kit is deployed on thousands of sites, it carries a recognisable structural fingerprint, a combination of brand strings, script tells and markup shapes that appear together.

A signature encodes that combination. It is stricter than a heuristic, because it names the exact strings a specific kit ships, so it can catch an injected page that the softer integrity heuristics miss: a token-gated standalone document that shares nothing with the rest of the site.

What squirrel checks

The rule is part of the opt-in threat-intel feature. When the feature is on, squirrelscan loads the bundled kit signatures before the audit rules run, then matches each crawled page. The match input is the page URL, its title, its HTML, its extracted text and the bodies of the external scripts attached to that page. Inline scripts are covered through the HTML.

• Fail, once per matching signature. Message: Matched kit signature "Calendly phishing kit" (calendly_brand, google_auth_overlay), naming the signature and the identifiers of the patterns that matched, not the text found on the page. The reported value is the signature id, and the details carry the signature’s own severity and description. Severity error, weight 9.

Signatures require several corroborating strings on the same page, so a match reports a failure directly rather than going through the two-signal correlation gate that the heuristic integrity rules use. When the threat-intel feature is off, the rule emits nothing at all: it never reports a page as clean for signatures it never ran.

The signatures ship with squirrelscan and need no API key or network access, so the rule works on any opted-in audit from the CLI as well as in the cloud.

Enable the feature

Threat-intel is off by default. Turn it on to activate this rule:

[intel]
enabled = true            # off by default

How to fix it

Remove the matched page and every file that came with it. Treat the site as compromised: look for a web shell or an injected loader, audit recently modified files, rotate credentials and read the access logs. A signature match is not a casual false positive, because it needed several corroborating strings to fire.

Read the matched pattern identifiers in the report before acting. They name which parts of the signature fired, such as a brand string in the title or an overlay id in the HTML, which narrows down where to look.

Enable / disable

Disable this rule

[rules]
disable = ["integrity/kit-signature"]

Disable all Site Integrity rules

[rules]
disable = ["integrity/*"]

Related rules

• integrity/known-malicious-url: the other half of the threat-intel feature, checking URLs against reputation feeds.
• integrity/brand-impersonation: the heuristic that catches kits with no signature yet.
• integrity/cloaking: pages that hide the payload from your crawler entirely.
• integrity/orphan-page: how a standalone injected page usually shows up in a crawl.

Site Integrity findings ship in every audit next to the SEO, performance and agent experience rules. See Website security scan with AI for how an agent works through a report.

References

• Social engineering (phishing and deceptive sites), Google Search Central
• Hacked content, Google spam policies

Check your site

Run squirrel audit https://example.com and open the Site Integrity section of the report. Each match is listed by page with the signature name and the strings that matched. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.