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 autonomous tooling misuse. Rather than replying on signatures or package names, Hunt Mode focuses on the behaviors that remain consistent even as frameworks change. This is guidance on how to baseline, hunt, and validate activity in your environment. To hunt these behaviors in this post, you need visibility into process execution and parent-child relationships. EDR process logs and standard endpoint telemetry are sufficient to operationalize every behavior in this breakdown.
Over the last year, software supply-chain attacks have shifted from occasional, high-profile incidents into a repeatable and increasingly preferred intrusion technique.
Attackers have learned that compromising how software is delivered is often easier and more effective than exploiting vulnerabilities in the software itself. Update mechanisms, build pipelines, package repositories, and hosting providers have all recently become targets because they are often overlooked and treated with implicit trust.
When software deviates from its usual behavior that provides us as hunters an opportunity to identify those shifts. Below we will dive into some of the ways the Notepad++ updater exhibited unexpected behavior and how we can look for it.
Several excellent technical breakdowns of this incident have already been published by the Notepad++ team, Rapid7, and Censys. Rather than repeating that work, we’ll treat those findings as ground truth and focus on what a hunter should have noticed while the activity was unfolding.
Supply Chain Compromise
In the Notepad++ incident, attackers did not exploit a vulnerability in the editor. Instead, they compromised portions of the update delivery infrastructure and used that access to selectively serve malicious installers to a small set of users.
Only a targeted subset of systems received the trojanized updates. There was no mass campaign, no noisy distribution, and no obvious indicators that something was wrong at scale.
From a defensive standpoint, this is the kind of activity that can slip past reputation-based controls, hash allowlists, and trusted application controls.
Why Notepad++ is a Good Hunt Case
This supply chain update hijack is a great case for looking at deviations from behavioral baselines.
There is nothing inherently suspicious about:
- Notepad++ running
- An updater checking for new versions
- An installer executing
The suspicious behavior becomes apparent when you understand the expected patterns and observe the deviations.
Behavioral Chain Overview
This is the high-level summary of the compromised update flow:
- Notepad++ is launched
- The built-in updater (
gup.exe) checks for updates - Update traffic is redirected to attacker-controlled infrastructure
- A malicious installer is downloaded and executed
- The installer drops and launches a backdoor
- Post-compromise behaviors begin
Let’s examine opportunities that present themselves throughout this chain.
Network Behavior from Trusted Updaters
The updater was doing what it always does: checking for updates. The difference was where it was checking.
By examining the domains the updater typically reaches out to for updates, you can identify changes or newly seen domains.
Baseline Expectations
A legitimate updater should:
- Contact a small, stable set of vendor-controlled domains
- Resolve to predictable infrastructure
- Rarely introduce new destinations without a clear reason
What to Hunt
- Update processes connecting to unfamiliar domains or raw IP addresses
- DNS requests that don’t align with known vendor infrastructure
- TLS certificates that don’t match expected publisher identity
- Update traffic bypassing normal egress or proxy paths
This could potentially be a blindspot. Many environments allowlist update traffic and never revisit it or it’s often removed from investigative or detection queries due to it being labeled as noise.
Update Mechanism Behavior
In this instance, the legitimate gup.exe used by Notepad++ to download updates was redirected to a malicious update package.
Baseline Expectations
Before you hunt, you should know:
- Where
gup.exe normally resides on disk - What processes it typically spawns
- What domains it typically reaches out to for updates
- How update execution usually looks in your environment
Knowing these details can help you understand and build a baseline for update behavior within your environment.
What to Hunt
gup.exe (and other updaters) spawning unexpected child processes- Installer execution chains that don’t match prior update behavior
- Update binaries executing from temporary or non-standard locations
- Unusual command-line arguments passed during update execution
These updaters should typically follow a very standard pattern so by looking at the child processes, files written, and other related activity, the unusual behavior becomes clear.
Installer Integrity and Execution Context
Even when a malicious installer arrives through a trusted path, it still has to execute and this action leaves behind evidence.
Baseline Expectations
Installers should:
- Be signed by expected publishers
- Match vendor-published hashes
- Execute from predictable locations
- Behave consistently across installs
What to Hunt
- Installers with unexpected or invalid signatures
- Signed binaries that don’t match known release hashes
- Installers spawning unexpected processes or exhibiting behaviors unrelated to updates
Just because something is signed does not necessarily mean it is safe.
Post-Execution Behavior
Once the installer finishes, the attacker no longer needs to pretend.
This is where behavior shifts from software maintenance to post-compromise activity.
What to Hunt
- New processes executing from update or install directories
- DLL side-loading behavior
- In-memory unpacking or reflective loading
- Reconnaissance commands shortly after install
- Outbound beaconing patterns inconsistent with update traffic
If you only monitor installers during execution and stop watching afterward, you’ll miss this phase entirely.
Operationalize this Hunt
To hunt for these behaviors, you need the ability to query processes execution and DNS request events from your endpoints. These events likely captured in your EDR environment will provide the visibility to understand parent-child relationships and the domains being queried by those processes.
1. Inventory Your Updaters
Make a list of:
- Common desktop software with built-in update mechanisms
- Where their updater binaries live
- What parent/child relationships they normally produce
2. Build a Simple Baseline Query
Start with something basic:
- Show me all outbound connections where:
- process_name =
gup.exe - Grouped by destination domain
- Over the last 30-90 days
Now ask:
- Are there rare domains?
- New domains?
- Direct-to-IP connections?
- Infrastructure outside expected geographies?
Do this for every commonly installed updater not just Notepad++.
3. Hunt for Rare Updater Behaviors
Look for:
- Updaters spawning shells
- Updaters spawning scripting engines
- Installers writing executables outside expected directories
- Updaters creating scheduled tasks or services
If an updater is trying to establish persistence then it's likely not maintenance.
Threats Hidden in Routine
The Notepad++ incident looked routine at first as a a trusted updater simply checked for an update. The only real signal was that it reached somewhere it shouldn’t have. Supply chain attacks live in those small shifts, and hunters who baseline normal behavior are the ones who are better positioned to catch these obscured attacks.
Happy Hunting!
