Suspicious Files

The Suspicious Files page surfaces files flagged by malicious-file detection rules across your enrolled developer machines.

Some supply chain attacks plant files that trigger code execution outside the package lifecycle scripts most security tools monitor, for example a binding.gyp that runs during npm install, or an editor configuration file that runs when a project is opened. Suspicious Files detects these artifacts on developer machines.

The feature works out of the box: the underlying detection rules are authored and maintained by StepSecurity, so there is nothing to configure. As new attack techniques are identified, StepSecurity adds and updates rules centrally, and your fleet is evaluated against them automatically.

What it detects

Detection rules cover files associated with known supply chain attacks, including:

• A malicious binding.gyp that triggers code execution during npm install
• Editor and AI-tool configuration files that auto-execute on project open or session start

The following files are examples of editor and AI-tool integration points that can be abused to achieve code execution when a developer opens a project or starts a session:

File	Tool	Trigger
.claude/setup.mjs	Anthropic Claude Code	SessionStart hook: runs on every new Claude Code session
.claude/settings.json	Anthropic Claude Code	Settings injection
.cursor/rules/setup.mdc	Cursor	Custom rules file: loaded on project open
.gemini/settings.json	Google Gemini	Settings injection
.vscode/tasks.json	Visual Studio Code	runOn: folderOpen auto-execute
.vscode/setup.mjs	Visual Studio Code	Task-triggered setup script
.github/setup.js	GitHub Actions	Workflow injection

StepSecurity maintains and expands this rule set continuously, so the campaigns and file patterns covered grow over time without any action on your part.

Filters

The page supports the following filters:

• All statuses: filter by the current status of each flagged file ( Active or Resolved )
• All confidence: filter by detection confidence (High or Low)
• All campaigns: filter by the attack campaign a detection rule is associated with (for example, shai-hulud, evil-payload, known-bad-marker)

You can also search across devices and extensions using the global search box at the top of the console.

Detection table

The Suspicious Files table lists every flagged file across your enrolled devices, with the following columns:

Column	Description
File	The path of the flagged file on the device (for example, setup.js, binding.gyp, or a full path under a user's home directory).
Device	The device where the file was detected, shown by device identifier.
Campaigns	The attack campaign the matching detection rule is associated with (for example, shai-hulud, evil-payload, known-bad-marker).
Confidence	How confident the detection rule is that the file is malicious (High or Low). Open the detection to see the full condition breakdown behind the confidence level.
Status	The current status of the detection (for example, Active).

The New Threats indicator in the top navigation bar reflects newly detected items across the console, including newly flagged suspicious files.

Detection details

Selecting a flagged file opens a side panel with the full detection record for that file.

The panel header shows the file path and the rule that flagged it, followed by chips summarizing the detection: confidence (for example, High), status (for example, Active), and the associated campaign.

The details block includes:

• Path: the full path of the flagged file on the device
• SHA-256: the SHA-256 hash of the file, for correlation and threat-intel lookups
• Rule: the identifier of the detection rule that matched
• Matched glob: the file-path pattern the rule used to select candidate files
• First seen / Last seen: when the file was first detected on the device and when it was most recently observed

Condition breakdown

Below the details block, the Condition breakdown shows why the file was flagged. For each campaign the rule evaluates, it displays:

• The campaign name and an overall match indicator (for example, Full match)
• A description of what the rule is checking for
• The individual conditions that make up the rule, each showing whether it is Required and how it was evaluated (for example, regex · matched)

A rule can require multiple conditions to match before a file is flagged. This breakdown lets you confirm exactly which indicators were present, which is useful both for validating a detection and for triaging a Low-confidence match.

Why it matters

The files attackers plant for code execution often live outside the surfaces that traditional endpoint and SCA tools inspect. A binding.gyp that executes during install, or a .vscode/tasks.json that runs on folder open, will not appear in a package manifest and may not trip a conventional malware scanner. Because these files execute with the developer's own access to source code, credentials, and CI/CD tokens, a single compromised machine can become the entry point for a wider breach.

Use this page to:

• Respond to incidents: when a new attack is disclosed, identify in seconds which devices carry the flagged file
• Confirm coverage: see that StepSecurity's centrally managed rules are evaluating your fleet without any local configuration
• Prioritize remediation: use the confidence and campaign columns to focus first on high-confidence detections tied to active campaigns

Remediation

When a file is flagged, identify the affected device from the Device column and investigate the file in place. Confirmed-malicious files should be removed from the device, and any credentials accessible from that machine should be treated as potentially exposed and rotated. After remediation, rescan the device and confirm the file no longer appears in Suspicious Files.