> For the complete documentation index, see [llms.txt](https://docs.stepsecurity.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stepsecurity.io/developer-machines/suspicious-files.md).
# 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.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.stepsecurity.io/developer-machines/suspicious-files.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.