Your Plugins and Extensions Are (Probably) Fine. Hunt Them Anyway.

Five hunt ideas (and one deep dive) for abuse hiding in plain sight.

Plugins and extensions are part of nearly every modern workflow. Developers use them to write and debug code. Analysts use them to scrape data, format JSON, and sync tabs. But that convenience comes with risk, often hidden until something breaks. As Eunomia’s recent research shows, these tools are turning up more frequently in real-world security incidents. We’re using that as inspiration for the hunts in this post.

This post explores hunt ideas focused on both browser extensions and IDE plugins. While the terms are often used interchangeably, they target different environments. Extensions typically run in browsers. Plugins extend developer tools like VS Code or PyCharm. Both deserve scrutiny.

Malicious or vulnerable plugins/extensions have enabled everything from remote code execution to credential theft and stealthy data exfiltration. The tricky part? These attacks often hide in plain sight. They masquerade as clipboard helpers, theme switchers, or tools that just make life easier.

Below are several hypothesis-driven hunt ideas based on real techniques adversaries use to exploit plugins and extensions. But don’t jump in just yet. If you haven’t already explored what’s normal in your environment, start with a baseline hunt:

1. Who installs plugins or extensions?

2. What permissions are commonly requested?

3. Are plugins or extensions synced between machines?

4. Do you have visibility into installation and execution behavior?

Need help figuring out how to baseline?
Check out these THOR Collective Dispatch posts for practical methods you can use right away:

• A DEATHCon Thrunting Workshop Overview (Pt. 4)

• Stop Chasing Ghosts: How Five Numbers Can Strengthen Your Baseline

• Z-Scoring Your Way to Better Threat Detection

Once you’ve got that foundation, these hunts can help uncover where the risk becomes real.

Hunt Ideas by TTP

Deep Dive: H-EXT2 — IDE Plugin Launch Behavior

Let’s use PEAK (an open-source, vendor-agnostic threat hunting framework) to do a deep dive into one of the TTPs above.

Suspicious Plugin Launch Behavior

Technique: T1059 - Command and Scripting Interpreter, T1546.016 - Event Triggered Execution: IDE Plugins

H-EXT2: IDE Plugin Launching Shells or Scripts

Prepare

Hypothesis:

A plugin within a developer’s IDE (such as VS Code or JetBrains) was used to launch an unauthorized or suspicious script. The activity may support persistence, beaconing, or lateral movement.

Scope:

• Data Source: Sysmon, EDR, or audit logs capturing child process activity

• Targets: Developer endpoints

• Timeframe: Last 30 days

Background:

Plugins like “Remote Code Runner” or “REST Client” can execute code or connect to networks. In some cases, plugins are outright malicious or get updated to be. When compromised, they can spawn shells, download payloads, or execute scripts using trusted parent processes. EEK.

ABLE Table

Execute

Search Goal:

Find IDE processes spawning shells or scripting engines.

Example SPL (Sysmon or EDR logs):

index=sysmon OR index=edr sourcetype=process_creation 
process_name IN ("cmd.exe", "powershell.exe", "bash", "python", "sh")
| eval parent_lc=lower(parent_process_name)
| search parent_lc IN ("code.exe", "pycharm64.exe", "webstorm64.exe", "eclipse.exe")
| stats count, values(command_line) as CommandLine, values(process_name) as ChildProcess by parent_process_name, parent_command_line, user, host
| where count > 1

Act with Knowledge

This surfaces IDEs launching unexpected child processes, which may indicate a plugin executing scripts or commands outside normal dev activity. Review results in context:

• Is this behavior consistent with how the user normally works (let’s check that baseline!)?

• Was the process triggered manually (e.g., via a debugger or terminal)?

• Does the plugin inventory explain the command being executed (you do have a plugin inventory, right?!?)?

Actions:

• Trace process ancestry to confirm which plugin or IDE action triggered the child process

• Audit the list of installed plugins, paying close attention to sideloaded or recently updated ones

• Compare behavior against known plugin capabilities or release notes

• Remove or restrict risky plugins through IDE configuration or developer policy

• If applicable, disable automatic plugin sync across devices to limit propagation

Final Word

Browser extensions and developer plugins blend into everyday workflows. That’s what makes them dangerous. They don’t need to exploit a vulnerability…they just need permission.

Start with visibility. Establish a baseline. Then ask the right questions:

• What’s installed?

• What does it do?

• Who gave it access?

The only thing better than a good hunt is a better version of it. Try one out, tweak it for your stack, and tell us what you learned.