Cyber Journal

The Notepad++ Supply Chain Hijacking: A Detection Engineer’s Deep Dive

Executive Summary

In June 2025, Notepad++ became the target of a sophisticated infrastructure-level supply chain attack attributed to Chinese state-sponsored actors. Rather than exploiting vulnerabilities in Notepad++ itself, attackers compromised the shared hosting server at the application provider level, selectively redirecting update traffic from targeted users to malicious update manifests. This incident represents a critical lesson in defense-in-depth and the importance of application-level signature verification—detection mechanisms that most organizations are not equipped to identify at scale.

This post analyzes the incident from detection and response perspectives, providing actionable Sigma rules, network detection strategies, and defensive recommendations for both enterprise and personal users.

Incident Overview

Attack Mechanism

The attack was not a code-level vulnerability exploitation but rather an infrastructure-layer compromise targeting application update delivery:

  1. Shared Hosting Server Compromise: Threat actors gained root or administrative access to a shared hosting server operated by Notepad++’s hosting provider.
  2. Selective Traffic Interception: Rather than compromising all hosted applications, attackers specifically searched for the notepad-plus-plus.org domain. This selective targeting is consistent with nation-state precision—they exploited weak update verification mechanisms specific to older Notepad++ versions.
  3. Credential Persistence: After losing direct server access on September 2, 2025, threat actors retained credentials to the hosting provider’s internal services (likely database replication, configuration management, or traffic routing systems). This allowed continued manipulation of traffic to the update endpoint (https://notepad-plus-plus.org/update/getDownloadUrl.php).
  4. Manifest Hijacking: The attack redirected legitimate update requests to attacker-controlled servers that served malicious XML manifests containing references to compromised installer binaries.
  5. Update Verification Bypass: The success of this attack relied on insufficient verification controls in WinGup (the Notepad++ updater) in versions before v8.8.9—the updater did not verify the digital signature of downloaded installers or validate the update manifest’s integrity.

Threat Actor Profile

Multiple independent security researchers assessed the threat actor as a Chinese state-sponsored group, evidenced by:

  • Highly selective, targeted approach (not mass distribution)
  • Deep understanding of Notepad++ update mechanisms
  • Infrastructure-level sophistication and persistence
  • Ability to maintain access across multiple authentication boundaries

Detection Engineering: The Challenge

This incident presents a detection nightmare for several reasons:

1. Selective Targeting Defeats Volume-Based Anomalies

Traditional detection approaches rely on identifying unusual patterns in aggregate traffic. A state-sponsored actor selectively compromising a subset of users leaves minimal statistical traces. This attack would not trigger:

  • DDoS alerts (normal traffic patterns)
  • Bandwidth anomalies (minimal deviation from baseline)
  • Mass file distribution detection (highly targeted)

2. Update Traffic Is Trusted and Encrypted

Application updates flow through HTTPS, which encrypts payload inspection. Without explicit certificate pinning or manifest signing:

  • Network-based IDS cannot inspect content
  • Signature-based detection sees legitimate-appearing HTTP requests
  • Behavioral detection requires knowing what “normal” update traffic looks like per-application

3. Successful Exploitation Leaves Minimal Forensic Evidence

If a user installed a compromised update, endpoint detection would flag the malware—but only after initial execution. The hijacking itself (traffic redirection) occurs at the hosting provider level, invisible to the endpoint.

4. XML Manifest Attacks Are Protocol-Agnostic

The attack modified XML responses to point to malicious binaries. Detecting this requires:

  • Protocol-aware inspection (application-layer understanding)
  • Known-good manifest baselines
  • Signature verification enforcement

Detection Strategy: A Layered Approach

Layer 1: Network Detection (NSM/NDR)

1.1 TLS Certificate Validation Monitoring

Objective: Detect unexpected SSL/TLS certificates presented for update domains.

Detection Logic:

  • Monitor all HTTPS traffic to known update servers (*.notepad-plus-plus.org, *-update.*.org patterns)
  • Extract and validate certificate issuer, subject, and serial number
  • Alert on mismatches with known-good certificates

Sigma Rule Example:

title: Unexpected TLS Certificate for Software Update Server
id: notepad-update-cert-anomaly
status: experimental
logsource:
  product: zeek
  service: ssl
detection:
  selection:
    server_name|contains:
      - notepad-plus-plus.org
      - update
    issuer|contains|all:
      - CN=
      - O=
      - NOT|equals: 'Sectigo Limited'  # Known legitimate issuer
  condition: selection
falsepositives:
  - Certificate renewal by legitimate operator
  - CDN re-signing (CloudFlare, Akamai)
level: high

Behavioral Baseline:

  • Establish baseline certificates for all update servers
  • Document issuer chain, certificate fingerprints (SHA256)
  • Version update notifications when certificates change
  • Correlate unexpected certs with change management logs

1.2 HTTP Redirect Chain Inspection

Objective: Detect 302/307 redirects that divert update traffic to unexpected hosts.

Detection Logic:

  • Monitor HTTP 302/307 responses from known update endpoints
  • Extract Location header and validate destination against whitelist
  • Alert on redirects to new, unexpected, or geographically anomalous hosts

Zeek Detection Script:

event http_reply(c: connection, version: string, code: count, reason: string) {
    if (code == 302 || code == 307) {
        if (/notepad-plus-plus|update/ in c$http$host) {
            local location = c$http$location;
            # Check against known-good whitelist
            if (location !in update_domain_whitelist) {
                NOTICE([$note=UpdateRedirectAnomaly,
                        $msg="Unexpected redirect for update server",
                        $conn=c,
                        $identifier=cat(c$id$orig_h, location)]);
            }
        }
    }
}

Data to Collect:

  • Source IP of update request
  • Destination IP before redirect
  • Location header value
  • HTTP User-Agent (identify client version)
  • Request path and query parameters

1.3 Domain Name System (DNS) Monitoring for Update Domains

Objective: Detect unauthorized DNS record changes or resolution anomalies.

Detection Points:

  • Monitor A/AAAA record changes for update domains (alert on any change)
  • Track DNS resolution source (expected: internal resolvers, legitimate CDN nameservers)
  • Alert on resolution from unexpected geographic regions or ISPs

Sigma Rule Example:

title: Unauthorized DNS Record Change for Update Domain
id: dns-update-domain-change
status: experimental
logsource:
  product: windows
  service: dns
detection:
  selection:
    RecordName: notepad-plus-plus.org
    EventID: 257  # DNS Query
    QueryStatus: '0'  # Success
    ClientIP|notinlist:
      - 10.0.0.0/8
      - 172.16.0.0/12
      - 192.168.0.0/16
      - CloudFlare_IPs  # CIDR block
    RecordType:
      - A
      - AAAA
  condition: selection
falsepositives:
  - Legitimate DNS provider failover
  - Planned CDN migration
level: medium

Layer 2: Endpoint Detection (EDR/AV)

2.1 Installer Signature Validation

Objective: Detect execution of installers lacking valid digital signatures or with invalid chains.

Detection Logic:

  • Monitor process creation for known update mechanisms (WinGup, NSIS, MSI installers)
  • Verify Authenticode signature validity using Windows APIs
  • Alert on:
  • Unsigned executables
  • Signatures with invalid chains
  • Signatures from unexpected issuers
  • Expired or revoked certificates

Pseudo-Code for EDR Agent:

def check_installer_signature(file_path):
    sig = extract_authenticode_signature(file_path)
    if not sig.is_valid():
        alert("Invalid or Missing Signature", file_path)
        return False
    issuer = sig.issuer_cn
    expected_issuer = "Notepad++ Contributors"  # Known legitimate
    if issuer != expected_issuer:
        alert("Signature Issuer Mismatch", {
            "file": file_path,
            "expected": expected_issuer,
            "actual": issuer
        })
        return False
    if is_certificate_revoked(sig.certificate):
        alert("Revoked Certificate", file_path)
        return False
    return True

Data to Collect:

  • File path and hash (SHA256)
  • Signature issuer, subject, and serial number
  • Certificate validity period
  • Signature algorithm and timestamp
  • Parent process information

2.2 Manifest File Integrity Verification

Objective: Detect tampering with application update manifests (XML, JSON, YAML).

Detection Logic:

  • Intercept update manifest files (XML responses from update servers)
  • Verify digital signatures (XMLDSig) against known public keys
  • Compare manifest contents with historical baselines
  • Alert on:
  • Missing signatures
  • Invalid signatures
  • Unexpected binary references
  • Out-of-band version numbers

Manifest Validation Rule:

def validate_update_manifest(manifest_path, public_key):
    """Verify XMLDSig signature on update manifest."""
    doc = parse_xml(manifest_path)
    signature_elem = doc.find(".//Signature", namespaces=XMLDSIG_NS)
    if signature_elem is None:
        alert("Missing Manifest Signature", manifest_path)
        return False
    # Extract signature and signed content
    sig_value = signature_elem.find("SignatureValue").text
    signed_info = signature_elem.find("SignedInfo")
    # Verify signature cryptographically
    if not verify_rsa_signature(signed_info, sig_value, public_key):
        alert("Manifest Signature Invalid", manifest_path)
        return False
    # Extract and validate referenced binary hashes
    for reference in signed_info.findall("Reference"):
        uri = reference.get("URI")
        digest = reference.find("DigestValue").text
        # Compare against known-good hashes
        if digest not in known_good_hashes:
            alert("Unknown Binary in Manifest", {
                "uri": uri,
                "digest": digest
            })
            return False
    return True

Layer 3: Network Traffic Inspection (DPI)

3.1 Application-Layer Protocol Analysis

Objective: Inspect HTTP response bodies for suspicious update manifests.

Detection Technique:

  • Deploy network-based DPI for update protocols
  • Inspect XML/JSON payloads returned from /update/getDownloadUrl.php
  • Compare payload signatures against baseline
  • Alert on:
  • Unsigned manifests
  • Manifests referencing unknown hosts
  • Manifests referencing domains attributed to adversaries

Suricata Rule Example:

alert http any any -> any any (
    msg:"Suspicious Update Manifest - Unknown Binary Reference";
    flow:to_server,established;
    http.uri;
    content:"/update/getDownloadUrl.php";
    http.response_body;
    content:"<location>";
    http.response_body;
    pcre:"/location>[^<]*(?<!notepad-plus-plus\.org[^<]*)<\/location/";
    classtype:command-and-control;
    sid:1000001;
    rev:1;
)
alert http any any -> any any (
    msg:"Update Manifest Missing Digital Signature";
    flow:to_server,established;
    http.uri;
    content:"/update";
    http.response_body;
    content:"<Signature";
    distance:0;
    within:10000;
    isdataat:!1,relative;
    classtype:suspicious-behavior;
    sid:1000002;
    rev:1;
)

Data to Collect:

  • Full HTTP request/response (including body)
  • Response time and size
  • Manifest version numbers and binary references
  • Geographic origin of response (for MITM detection)

Layer 4: Behavioral Anomaly Detection

4.1 Outbound Connection Profiling

Objective: Establish and monitor baseline outbound connections for applications.

Detection Logic:

  • Profile normal outbound connections per application (destination IPs/domains, ports, protocols, timing)
  • Alert on deviations:
  • First-time connections to new IPs/domains
  • Connections to geographically anomalous regions
  • Unexpected protocols (e.g., raw TCP instead of HTTPS)
  • Off-hours update activity

Sigma Rules for Enterprise Deployment

Rule 1: WinGup Execution Without Signature Verification (Pre-v8.8.9)

title: Notepad++ WinGup Execution - Signature Verification Bypass Risk
id: notepad-wingup-bypass
status: experimental
date: 2026/02/02
author: Detection Engineering Team
logsource:
  product: windows
  service: sysmon
detection:
  selection_process:
    Image|endswith:
      - 'WinGup.exe'
      - 'gup.exe'
    CommandLine|contains:
      - '-update'
      - '-winGupAutomatic'
  selection_version:
    Product|contains: 'Notepad++'
    FileVersion|lt: '8.8.9'
  filter_legitimate:
    CommandLine|contains:
      - 'C:\Program Files\Notepad++'
      - '%ProgramFiles%\Notepad++'
  condition: (selection_process or selection_version) and not filter_legitimate
falsepositives:
  - Legitimate Notepad++ updates from official sources
level: medium
tags:
  - supply_chain
  - notepad_cve

Rule 2: Suspicious Certificate Issuer for Update Traffic

title: Non-Standard Certificate Issuer for Notepad++ Update
id: notepad-update-cert-issuer-anomaly
status: experimental
logsource:
  product: zeek
  service: ssl
detection:
  selection:
    server_name|contains:
      - notepad-plus-plus.org
      - update.notepad
    issuer|notinlist:
      - 'CN=Sectigo Limited,O=Sectigo Limited,C=GB'
      - 'CN=Let\'s Encrypt Authority'
      - 'CN=DigiCert'
  condition: selection
falsepositives:
  - Certificate rotation events
  - CDN re-signing (CloudFlare, Akamai)
level: high
tags:
  - supply_chain
  - tls_hijacking

Rule 3: Unsigned or Invalid Installer Execution

title: Notepad++ Installer Execution - Missing Digital Signature
id: notepad-installer-signature-missing
status: experimental
logsource:
  product: windows
  service: sysmon
  event_id: 11
detection:
  selection:
    TargetFilename|endswith:
      - 'notepad++.exe'
      - 'npp.installer.exe'
    Signed: 'false'
  filter_trusted_paths:
    TargetFilename|contains:
      - 'C:\Program Files\Notepad++'
      - 'C:\Program Files (x86)\Notepad++'
  condition: selection and not filter_trusted_paths
falsepositives:
  - Beta or development builds
  - Locally compiled versions
level: high
tags:
  - supply_chain
  - code_signature_bypass

Rule 4: HTTP Redirect to Unexpected Host – Update Server

title: Update Server HTTP Redirect to Unexpected Destination
id: update-server-redirect-anomaly
status: experimental
logsource:
  product: zeek
  service: http
detection:
  selection_request:
    uri|contains:
      - 'update/getDownloadUrl'
      - 'checkupdate'
      - 'getversion'
    host|contains:
      - notepad-plus-plus
      - updates
  selection_response:
    status_code:
      - 302
      - 307
    location|notcontains:
      - notepad-plus-plus.org
      - cdn.notepad
  condition: selection_request and selection_response
falsepositives:
  - CDN redirect for load balancing
  - Geographic failover
level: high
tags:
  - supply_chain
  - mitm_detection

Personal User Recommendations

For Individual Notepad++ Users

Immediate Actions

  1. Update to v8.8.9 or Later
  • Download directly from the official repository: https://github.com/notepad-plus-plus/notepad-plus-plus/releases
  • Verify the installer hash (SHA256 checksum provided on GitHub)
  • Do not rely on the built-in updater for the initial upgrade
  1. Verify Installer Authenticity
  • Command-line verification (PowerShell):
    powershell $hash = (Get-FileHash -Algorithm SHA256 'npp.8.8.9.Installer.exe').Hash # Compare against: https://github.com/notepad-plus-plus/notepad-plus-plus/releases/tag/v8.8.9
  1. Disable Auto-Update Temporarily
  • Settings → Preferences → Auto-update
  • Uncheck “Enable auto-update” until you’re confident in your current version
  • Re-enable once you’ve manually updated to v8.8.9+

Long-Term Best Practices

  1. Enable Update Verification
  • Once on v8.8.9+, ensure certificate and signature verification is enabled (default in v8.8.9)
  • v8.9.2+ will enforce this by default
  1. Monitor Network Traffic (Advanced Users)
  • Use tools like Wireshark or Fiddler to inspect update requests
  • Watch for unexpected redirects or certificate mismatches
  • Document baseline behavior for reference
  1. Verify Update Manifests Manually
  • Access https://notepad-plus-plus.org/update/getDownloadUrl.php in your browser
  • Inspect the XML response for suspicious fields
  • Compare binary URLs against GitHub releases
  1. Use Hash-Based Verification
  • Always verify installed binaries against known-good hashes from official sources
  • Windows: certUtil -hashfile "C:\Program Files\Notepad++\notepad++.exe" SHA256
  • Compare against official release notes

Enterprise Implementation Playbook

Phase 1: Immediate Detection Deployment (Week 1–2)

Actions:

  1. Deploy Sigma Rules: Implement the four Sigma rules above in your SIEM (Splunk, ELK, ArcSight)
  2. Network Monitoring: Activate network-based detection for update server traffic
  • Monitor for TLS certificate changes on *.notepad-plus-plus.org
  • Alert on HTTP 302/307 redirects from update endpoints
  1. Inventory: Identify all Notepad++ installations in your environment
  • Query endpoints for Notepad++ version via EDR
  • Flag versions < 8.8.9

Sigma/SIEM Query Example (Splunk):

index=zeek_ssl server_name="*notepad-plus-plus*" 
| stats values(issuer) by server_name, src_ip 
| where issuer NOT IN ("Sectigo Limited", "Let's Encrypt Authority", "DigiCert")

Phase 2: Endpoint Hardening (Week 3–4)

Actions:

  1. Automated Update Deployment: Push Notepad++ v8.8.9+ to all endpoints via WSUS or configuration management
  2. Update Policy Enforcement:
  • Enable signature verification in all instances
  • Disable auto-updates pending full deployment
  • Implement Group Policy restrictions on unsigned executables
  1. Endpoint Detection Rule:
  • Deploy EDR rules to alert on WinGup execution without valid signatures
  • Collect and analyze all update-related process executions

Phase 3: Network Segmentation & Monitoring (Week 5–6)

Actions:

  1. Application-Layer Inspection: Deploy DPI rules in proxies/firewalls for update traffic
  2. DNS Monitoring: Establish real-time alerting for DNS record changes on update domains
  3. Outbound Connection Profiling:
  • Establish baseline for Notepad++ outbound connections
  • Alert on new, unexpected, or geographically anomalous destinations
  1. Threat Intelligence Integration:
  • Monitor for indicators from Notepad++ advisory (IP addresses, domains used by threat actors)
  • Feed these into EDR/SIEM rules

Phase 4: Incident Response & Threat Hunting (Ongoing)

Actions:

  1. Threat Hunt: Search for evidence of compromise:
  • Compromised update manifests in web server logs
  • Unexpected DNS changes
  • Installations of malicious binaries via update vector
  1. Forensic Preparation:
  • Preserve web server logs for update endpoints
  • Capture network traffic (PCAP) for suspicious sessions
  • Document chain of custody for potential malware samples
  1. Incident Response Testing: Conduct tabletop exercises simulating supply chain compromise

Network Detection Rules Summary

Detection VectorToolRule TypeSeverity
TLS Certificate MismatchZeek/SplunkSignatureHigh
HTTP 302 Redirect AnomalyZeek/Suricata/NIDSSignatureHigh
DNS Record ChangeDNS MonitoringSignatureMedium
Unsigned Installer ExecutionSysmon/EDRSignatureHigh
Invalid Manifest SignatureDPI/ProxyBehavioralHigh
Off-Hours Update ActivityEDR/Network FlowAnomalyMedium
New Outbound Connections (Update App)EDR/NetFlowAnomalyMedium

Key Takeaways for Detection Engineers

1. Trust Boundaries Are Critical

The Notepad++ attack exploited the trust relationship between the application and its update infrastructure. Verification mechanisms (signatures, certificates, manifests) are the last line of defense.

2. Selective Targeting Defeats Aggregate Detection

Nation-state actors often avoid creating statistical anomalies. Detection must focus on protocol correctness and integrity verification, not just volume.

3. Infrastructure Compromise May Not Leave Endpoint Traces

The hijacking occurred at the hosting provider level, potentially leaving no forensic evidence on compromised endpoints until malware execution.

4. Application-Specific Baselines Are Essential

Generic anomaly detection is insufficient. Each application has unique update patterns that must be profiled and monitored.

5. Defense-in-Depth Across Layers Is Required

No single detection mechanism would have caught this attack:

  • Network-only: Encrypted HTTPS traffic
  • Endpoint-only: May miss initial compromise
  • DNS-only: Doesn’t detect manifest tampering
  • Behavioral-only: Selective targeting defeats statistics

A combination of network, endpoint, application, and infrastructure monitoring is necessary.

Resources & References

Official Advisories & Updates

Detection Frameworks

  • MITRE ATT&CK – Supply Chain Compromise: T1195
  • MITRE ATT&CK – Compromise Software Repositories & Update Mechanisms: T1195.003
  • MITRE ATT&CK – Man-in-the-Middle: Proxy: T1557.002

Detection Tools & Standards

Network Monitoring Tools

INCIDENT RESPONSE PROCEDURES

If You Believe Your System Is Compromised

Immediate Actions (First 30 Minutes)

1. PRESERVE EVIDENCE
   - Enable audit logging in Windows
   - Do NOT restart the computer
   - Do NOT disconnect from network yet

2. ISOLATE THE SYSTEM
   - Disconnect from Wi-Fi or network cable
   - Enable offline storage of forensic data

3. COLLECT ARTIFACTS
   ```powershell
   # Run as Administrator
   $outputDir = "C:\Forensics"
   mkdir $outputDir -Force
   
   # Capture memory dump
   Get-Process | Out-GridView
   # Use WinDBG or Volatility to analyze (advanced)
   
   # Export relevant registry
   reg export "HKLM\SOFTWARE\Notepad++" "$outputDir\notepad-reg.hive"
   
   # Collect update logs
   Get-ChildItem "$env:ProgramFiles\Notepad++\update*" -Force -Recurse | 
     Copy-Item -Destination $outputDir -Recurse
   
   # Export Windows Event Logs
   wevtutil epl System "$outputDir\System.evtx"
   wevtutil epl Security "$outputDir\Security.evtx"
   wevtutil epl Application "$outputDir\Application.evtx"
  1. UNINSTALL & REINSTALL NOTEPAD++powershell# Uninstall current version Get-Item 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*' | Where-Object {$_.GetValue('DisplayName') -match 'Notepad++'} | ForEach-Object { # Run uninstaller & $_.GetValue('UninstallString') } # Download fresh copy from GitHub # Verify signature (steps in Section 2) # Reinstall
  2. NOTIFY AUTHORITIES (If Enterprise)
    • Contact security team
    • Notify CISO
    • Prepare incident report
    • Coordinate with law enforcement (optional)

Conclusion

The Notepad++ supply chain hijacking demonstrates that state-sponsored threats now routinely target the update infrastructure itself. For detection engineers, this represents a paradigm shift: defending against these attacks requires moving beyond traditional endpoint and network monitoring to include application-aware, cryptographic verification-based detection.

By implementing the detection strategies, Sigma rules, and enterprise playbook outlined above, organizations can significantly improve their resilience against similar supply chain attacks while maintaining visibility into critical software update channels.

The cost of detection is far lower than the cost of compromise.

By:

xalpha6

Posted in:

, , ,

Leave a comment