malware-detection

From single pull requests to full software packages: Detecting malicious code at scale (opens in new tab)

BewAIre evolved from a pull-request malware detector into a system for scanning dependency packages and upstream registries. Its core improvement is a two-stage pipeline: a cheap LLM filter handles routine changes, while a more capable agent investigates suspicious cases using external tools and repository context. This approach raised accuracy from 97.4% to 99.86%, eliminated false positives in a 690-diff sample, and reduced latency and cost through early exits. ## Expanding Beyond Pull Requests - Software supply-chain attacks increasingly compromise trusted dependencies such as axios, LiteLLM, and Mistral. - BewAIre initially focused on detecting malicious pull requests, identifying security testing, bug-bounty activity, and real attacks such as the Hackerbot campaign. - The team aimed to apply the same LLM-based detection to complete packages and package registries without sacrificing accuracy, latency, or predictable cost. ## Limits of Single-Pass LLM Evaluation - BewAIre began as a basic “LLM-as-judge” system that analyzed diffs through an inference API. - More capable reasoning models improved detection but increased costs. - Large diffs, especially dependency upgrades, challenged context-window limits. - Two changes addressed these limitations: - A filter-then-review escalation path. - Tool-enabled investigation allowing models to gather additional evidence. ## Two-Stage Filtering and Investigation - The filter phase: - Runs on every change using a fast, inexpensive model. - Uses straightforward prompts and diff chunking for large changes. - Produces a binary suspicious/benign decision. - Ends processing immediately when a change appears benign. - The investigation phase: - Runs only when the filter raises a concern. - Uses a stronger reasoning model in an agentic loop. - Can inspect commits, files, contributor histories, dependency metadata, and commit ranges through GitHub APIs. - Checks for reverted commits, typosquatting, suspicious contributor behavior, and dependency risks using sources such as osv.dev and Datadog SCA. ## Detecting Obfuscated Attacks - In the Hackerbot Claw example, the system identified a malicious filename containing shell command substitution. - A base64-encoded payload decoded to a `curl ... | bash` command that downloaded and executed remote code. - The investigation agent added useful context: - The contributor account was newly created, had no profile information, and had no followers. - The pull request had no reviews or approvals. - `${IFS}` obfuscation was used to evade security filters. - Combining code analysis with repository and author context made the final assessment more precise. ## Combining LLMs with Static Checks - The filter model could mistakenly treat Datadog-like typosquatting domains as legitimate without access to investigative tools. - BewAIre added preprocessing that extracts domains and compares them against a static list of known typosquatting variants. - This hybrid design improves reliability while avoiding the cost and nondeterminism of performing every check through a powerful LLM. ## Measured Results - Accuracy improved from 97.4% to 99.86% across 690 representative test diffs. - False positives fell from 17 to zero. - Most benign changes exit during the inexpensive filter stage. - Suspicious changes still receive deeper analysis, preserving broad coverage while controlling latency and cost. The practical recommendation is to combine inexpensive broad screening with selective, tool-driven investigation. Static security checks should complement LLM reasoning, especially for predictable threats such as domain typosquatting.

How to detect and prevent Contagious Interview IDE attacks (opens in new tab)

Contagious Interview attacks abuse VS Code’s automated tasks to execute malware when victims open a malicious repository and trust its workspace. GitLab developed low-level EDR detections around `node-pty`’s `spawn-helper`, allowing it to identify hidden background process execution while avoiding normal interactive developer activity. The article recommends combining runtime detection with IDE configuration hardening. ## The Contagious Interview Attack Path - North Korean threat actors use fake job interviews to persuade targets to download and review malicious code repositories. - Repositories can include a `.vscode/tasks.json` file configured to run automatically when the folder opens. - After the victim grants workspace trust, the task executes without obvious interaction. - Example payloads: - Detect the operating system. - Download a platform-specific second-stage payload. - Pipe it directly into `bash`, `sh`, or `cmd` using patterns such as `curl | bash`. - Resulting malware may steal passwords and cryptocurrency, deploy infostealers, and establish persistence for abuse of corporate access. ## Low-Level Detection with `spawn-helper` - GitLab looked below the VS Code layer because similar attacks can affect VS Code forks and other Node- or Electron-based IDEs. - VS Code uses the popular `node-pty` library to launch subprocesses. - `node-pty.spawn()` invokes a `spawn-helper` binary, which becomes a child process of the Node application. - This makes `spawn-helper` a useful operating-system-level signal for background task execution. ## Reducing False Positives - GitLab used Purple Team exercises to reproduce the attack and reviewed EDR telemetry. - Background VS Code tasks use `spawn-helper`, while foreground interactive processes such as the integrated terminal use a Code Helper binary. - Detections can therefore focus on processes launched invisibly, without user interaction. - GitLab further tuned alerts to identify suspicious commands such as background `curl | <shell>` execution rather than flagging every automated task. - The resulting detection produced no false positives despite widespread VS Code usage internally. ## Additional Prevention Measures - Runtime EDR monitoring is only one layer of defense. - Organizations can proactively harden their fleets by deploying global VS Code configuration that disables automatic task execution. - Combining IDE restrictions with process telemetry and behavioral detection provides broader protection against malicious repository-based attacks. Organizations should disable automatic task runs where practical and monitor low-level subprocess behavior, especially invisible `spawn-helper` executions that download or pipe remote content into a shell.