Hunt Mode with Nebulock
This series breaks down modern threats by focusing on the one thing attackers cannot hide: behavior. It centers on the actions, decisions, and required steps that expose malicious MCP server activity. Rather than relying on signatures or package names, Hunt Mode focuses on the behaviors that remain consistent even as frameworks, tooling, and infrastructure change. It provides guidance on how to baseline, hunt, and validate MCP activity in your environment. To hunt the behaviors in this post, you need process creation with full command line arguments, parent-child relationships, and network connections with process attribution. For local MCP servers, process telemetry is the primary signal. File activity, such as writes and deletes, can provide additional context, but the execution chain is what ties it together.
Introduction
Shadow AI is not a future risk. It is already inside your environment.
Developers are connecting MCP servers to AI clients without centralized approval, visibility, or governance. These servers inherit user-level access, persist across sessions, and execute locally with no additional authentication prompt. From a defender's perspective, the activity looks like the user did it — because the process tree says so.
That is the problem. And it is exactly where you hunt.
Baseline Normal Behavior
Baseline what normal MCP usage looks like across your fleet. It stabilizes fast: same clients, same packages, same command lines. Deviations from that baseline are your signal. When something stands out, follow the process tree. Look at what ran, what it touched, and what happened next.
MCP servers are subprocesses. When a developer configures one, the AI client spawns it. That process runs locally, holds context, and can issue tool calls on behalf of the session.
The user approves it once. The access persists.
That persistence is the attack surface.
Exploitation is active: supply chain attacks targeting MCP packages, command injection via malformed tool responses, and malicious remote servers using legitimate client trust to extract credentials from developer endpoints. The techniques vary. The behavior underneath does not.
Execution: MCP Process Spawn
Every MCP server produces the same execution pattern regardless of what it does.
parent: Claude / Cursor Helper / Windsurf
child: node / npx / uvx / python3
cmd: @modelcontextprotocol/ OR mcp-server- OR mcp-remote
What to Observe
- AI client spawning
node, npx, uvx, or python3 - Command lines containing
@modelcontextprotocol/, mcp-server-, or mcp-remote - Execution originating from unusual or user-writable directories
- First-seen packages across the fleet with no prior history
Why It Stands Out
Legitimate MCP usage stabilizes quickly. The same packages run for the same users from the same paths. Anything new, unattributed, or inconsistent breaks that pattern and warrants a closer look before it's trusted.
Command and Control: Remote MCP Connections
Remote MCP servers connect outbound through mcp-remote. The full destination URL appears in the command line, which means your telemetry already contains a complete inventory of external MCP infrastructure.
What to Observe
mcp-remote executions with external URLs in command arguments- Domains that cannot be attributed to known vendors
- Recently registered domains or domains with no usage history in your environment
- Structured URL paths suggesting multi-tenant or dynamically routed infrastructure
Why It Stands Out
Legitimate services are attributable. An unknown domain with no documentation or ownership are not. The command line gives you a full inventory of external MCP infrastructure in your environment. Anything you cannot explain is a finding.
Credential Exposure: Tokens in MCP Execution
Bearer tokens are frequently embedded directly in mcp-remote command lines as part of authentication configuration. Once that process runs, the token is visible in your EDR telemetry.
What to Observe
- Authorization headers or bearer tokens in process command lines
- Reuse of bearer tokens across multiple executions
- Token values visible in EDR telemetry
Why It Stands Out
Token should not appear in process logs. When they do, they are accessible to anything with visibility into that telemetry. What a developer treats as a configuration detail becomes a credential sitting in your SIEM, readable by any process or analyst with access to that data.
Credential Access: Tool Call Execution
Remote MCP servers can issue tool calls that execute locally. When those tool calls target credential stores, the activity shows up as standard system commands, but the parent process reveals what's actually driving them.
What to Observe
- Credential access commands executed on MCP-connected hosts
- Keychain access via
security utilities - Git credential helper usage
-
security find-generic-password -w security find-internet-password -wsecurity dump-keychaingit credential-osxkeychain get
Unexpected parent processes on those commands: node, python3, or other MCP subprocesses instead of the AI client itself.
Why It Stands Out
Legitimate credential access originates from the AI client directly. When the parent shifts to a subprocess, the action is no longer user-driven. Code running inside the MCP session is executing it. That distinction is the difference between normal developer behavior and active compromise.
Supply Chain: Untrusted MCP Packages
MCP packages installed without version pinning or publisher verification introduce ungoverned execution into your environment. The code may not be malicious by design. The access it receives does not care.
What to Observe
- Packages from unknown or single-use publishers
- Executions using
npx -y with no version pin - New packages with access to high-value systems (cloud credentials, internal APIs, file systems)
- Browser automation MCPs attaching to active authenticated sessions
Why It Stands Out
Browser-based MCP tools inherit the user's existing session state. Without visibility into what the tool is doing inside that session, access effectively extends to the MCP server. The package may pass a basic review. The access profile does not.
Composite Detection: The Chain That Confirms It
No single behavior in this post is sufficient on its own. node spawning from an AI client is normal. An outbound connection to an unknown domain is worth investigating. Credential access following both is a confirmed finding.
What to Observe
- MCP process spawn patterns
- Remote MCP domain connections
- Credential access activity on the same host
Why It Stands Out
Each step is explainable in isolation. The sequence is not. When all three appear on the same host in the same session window, the process tree has told you what happened. The sequence confirms malicious behavior.
Seek Out the Parent Process
MCP servers operate with persistent, user-level access from the moment they're configured. Everything they do appears in the process tree as user activity. The difference between legitimate use and active exploitation shows up in one place: the parent process.
When credential access originates from a subprocess instead of the AI client, something else is in control. That is shadow AI in practice: autonomous execution paths operating outside approved workflows, with access to credentials, sessions, and internal systems.
Happy hunting!
References
