CVE-2022-4149

Executive Summary

CVE-2022-4149 is a local privilege escalation vulnerability in the Netskope client service (versions prior to R96) running on Windows with NT AUTHORITY\SYSTEM privileges. The vulnerability stems from an insecure file-handling pattern: the service writes log files to a world-writable directory (C:\Users\Public\netSkope) and, on restart, deletes and recreates a placeholder file (logplaceholder) in a way that introduces a race condition. A malicious local standard user can exploit this race to pre-create the placeholder file with attacker-controlled ACL permissions, thereby gaining write access to all files in the log directory. By leveraging Windows pseudo-symlinks, the attacker can redirect file writes to arbitrary system locations, ultimately achieving full system-level privilege escalation. The vulnerability is patched starting in Netskope client v100; the NVD rates it at CVSS 7.0 (High), and it does not appear in CISA's Known Exploited Vulnerabilities catalog.

Technical Analysis

The vulnerability class is an insecure file-permission race condition combined with privileged file-write to an attacker-writable directory. The core failure is a mismatch between the security context performing the file operation (SYSTEM) and the directory permissions, which allow unprivileged users to create files in the same namespace.

The attack mechanism, as described in the NVD entry, works as follows:

1. Service Deployment Context: The Netskope client service runs as NT AUTHORITY\SYSTEM (the highest-privilege account on Windows). It is responsible for writing operational log files to a fixed directory: C:\Users\Public\netSkope. This directory is located under C:\Users\Public, which is, by default, writable by all local users — the service does not enforce a restrictive ACL on the directory itself.

2. File-Specific ACL Mismatch: Most files in this directory are created and written exclusively by the SYSTEM account. However, a placeholder file, logplaceholder, inherits the directory's default permissions, granting full access (F) to all users via the inherited "Everyone" or "Authenticated Users" allow entry. The Netskope client attempts to mitigate this by later modifying the ACL on this file to only allow read permissions for standard users — but this ACL adjustment happens after the file is created, and only after the file exists.

3. Race Condition on Service Restart: When the Netskope client service restarts, it performs two sequential operations: (a) delete the existing logplaceholder and (b) recreate it. Between these two operations, there is a time window during which the file does not exist. A malicious local user can monitor the file system via a directory-change notification (e.g., ReadDirectoryChangesW or a polling loop) and, when the file disappears, pre-create the logplaceholder file with attacker-chosen ACLs (granting full control to the current user).

4. ACL Implantation: When the service (running as SYSTEM) subsequently attempts to create the file, it fails because the file already exists (unless it passes FILE_OPEN_IF semantics, in which case it succeeds but does not overwrite the ACL). The service then proceeds to write log content to the file with the existing attacker-controlled ACL, or it attempts to lock the file and proceeds. Either way, the attacker now owns the file path's effective ACL.

5. Privilege Escalation via Pseudo-Symlinks: The attacker now has modify/delete rights over all files in C:\Users\Public\netSkope because the directory itself is under their control (or because the ACL change on logplaceholder propagates in a way that grants broader access). The attacker can then delete existing log files and replace them with Windows pseudo-symlinks pointing to arbitrary system paths (e.g., C:\Windows\System32\config\SAM, a DLL in a trusted system directory, or a file executed during system boot). The next time the Netskope service (running as SYSTEM) writes log data, it follows the symlink and overwrites the target file with attacker-controlled content. If the target is a system binary, the attacker can plant a malicious payload; when that binary/script executes (e.g., at boot or via a scheduled task), the attacker's code runs with SYSTEM privileges.

The root cause is a Time-of-Check-Time-of-Use (TOCTOU) flaw: the service validates/restricts the file's ACL only after creation, not atomically at creation time, and it fails to protect the directory with a restrictive SACL/DACL that would prevent standard users from creating any file in it.

Exploitation Scenarios

Step 1 — Reconnaissance/Target Identification: The attacker must be a local user on a Windows machine with the vulnerable Netskope client (version < R96) installed. Local access is required; the attack cannot be performed remotely. The attacker needs to verify (a) that the Netskope client service is installed and running, and (b) that the directory C:\Users\Public\netSkope exists and is writable. This can be done with simple directory listing commands or by checking running services.

Step 2 — Triggering the Flaw Class: The attacker sets up a file-system watcher (e.g., a PowerShell loop or a compiled helper) that polls for the deletion of C:\Users\Public\netSkope\logplaceholder. The race condition is triggered when the Netskope service is restarted — either by the system (e.g., reboot, service crash, administrator action) or by the attacker (if they have permission to restart the service, though that is not a prerequisite). When the watcher observes the file deletion, the attacker immediately creates a new file at the same path with an ACL granting full control to their user account (e.g., using icacls or Set-Acl in PowerShell).

Step 3 — Payload/Execution Method: Once the attacker has write access to the directory contents, they delete an existing log file (e.g., netskope.log) and replace it with a Windows pseudo-symlink (created with mklink / New-Item -ItemType SymbolicLink) pointing to a critical system location — for example, a privileged executable in C:\Windows\System32 or a protected configuration file. When the Netskope service (running as SYSTEM) resumes writing logs, it opens the symlink and writes its content to the target path. The attacker can craft the log content (e.g., by controlling log message fields) to inject a malicious payload that gets written into the SYSTEM-owned file.

Step 4 — Post-Exploitation Impact: Instantly after the file write succeeds, the attacker can either (a) execute the overwritten binary directly if it is scheduled for execution, or (b) wait for the next reboot/logon for SYSTEM to load the tampered binary/script. The attacker achieves full NT AUTHORITY\SYSTEM privileges and can then perform any action on the host: enable RDP, install a rootkit, dump credentials, disable security tools, or move laterally across the domain. No public PoC is confirmed at this time; the above chain is inferred from the vulnerability description and the standard approach to Windows local privilege escalation via symlink/hardlink planting. The NVD description does not provide enough detail to identify any additional restrictions on which files can be targeted; the pseudo-symlink technique is explicitly mentioned therein.

Impact Assessment

Base CVSS Score: 7.0 (High) — While the vector string is not provided in the NVD entry, the attack is purely local (AV:L), requires low privileges (PR:L — a standard Windows user), low attack complexity (the file race is reproducible), and no user interaction. The Confidentiality, Integrity, and Availability impacts are all rated High, because after exploitation the attacker can read and overwrite arbitrary system files, modify system behavior, and force system reboots, leading to full system compromise.

Business Impact: This vulnerability allows a low-privilege local user to escalate to SYSTEM on any Windows endpoint running the affected Netskope client. In a corporate environment, this effectively negates endpoint security controls since the attacker can disable the very Netskope client (which is the security enforcement point). Combined with the fact that Netskope is a security product (cloud access security broker / secure web gateway), an attacker who compromises the endpoint can bypass web filtering, data loss prevention, and remote access protections put in place by the organization.

Blast Radius: Every Windows workstation and server running Netskope client < R96 is affected. In an enterprise with thousands of endpoints, this is a significant attack surface. However, exploitation requires local access, so the primary exposure is from (a) a malicious insider, (b) a low-privilege attacker who previously exploited a web browser or application flaw, or (c) malware that has already executed in a low-privileged context. The EPSS score of 0.00161 (5.7th percentile) indicates that exploitation is currently not widespread; no CISA-KEV entries and no known public PoCs exist, suggesting the vulnerability is not yet actively targeted in the wild.

Availability: Not only does the attack grant SYSTEM privileges, but a non-malicious but careless attempt to exploit the race could leave a corrupt logplaceholder, potentially causing the Netskope service to fail to start — resulting in denial of service of the security client on that endpoint.

Detection Guidance

Detection of this vulnerability is best achieved by monitoring file-system activity, process behavior, and service restarts around the C:\Users\Public\netSkope path, since the vulnerability class is file-based and does not inherently produce network traffic.

Sigma Rule

title: Netskope Client logplaceholder File Race Exploitation
id: 9f8e2a8b-5c41-4c2e-9e7f-43ca2a7f9d10
status: experimental
description: Detects the creation of logplaceholder or other files in the Netskope log directory by a non-SYSTEM account, or the deletion/re-creation sequence indicative of a TOCTOU race.
author: ValtersIT Threat Intel
date: 2025/03/10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2022-4149
logsource:
    product: windows
    category: file_event
detection:
    selection_netSkope_path:
        TargetFilename|contains:
            - 'C:\Users\Public\netSkope\'
    selection_non_system_creator:
        User|startswith:
            - 'NT AUTHORITY\SYSTEM'
            - 'SYSTEM'
        User|null: false
    selection_non_system_user:
        User|not startswith:
            - 'NT AUTHORITY\SYSTEM'
            - 'SYSTEM'
    selection_logplaceholder:
        TargetFilename|endswith: '\logplaceholder'
    condition_for_race:
        selection_netSkope_path and selection_non_system_user and selection_logplaceholder
    condition_for_expected:
        selection_netSkope_path and selection_non_system_creator and selection_logplaceholder
    falsepositive:
        - Legitimate service creates logplaceholder on first install
    level: high
    tags:
        - attack.privilege_escalation
        - attack.t1068
        - cve.2022.4149

YARA Rule

rule Netskope_Client_Logplaceholder_Tamper
{
    meta:
        author = "ValtersIT Threat Intelligence"
        description = "Detect log files in the Netskope writable directory that are symlinks or have unusual ACLs"
        cve = "2022-4149"
        date = "2025-03-10"
        severity = "high"
    strings:
        $path = "C:\\Users\\Public\\netSkope" nocase
        $symlink_target_pattern = "\\??\\" ascii
        $placeholder = "logplaceholder" nocase
    condition:
        (uint32(0) == 0x4D5A /* MZ header */) or
        (filesize < 10KB and $path and ($placeholder or $symlink_target_pattern))
}

Suricata IDS Rule

This vulnerability is purely local and does not generate meaningful network traffic. A network-based rule cannot directly detect this attack. Below is a best-effort rule that looks for suspicious SMB/DFS writes to the public share path in environments where the public folder is shared — but in most configurations, this path is not shared, and the rule will not fire. The rule is provided for completeness and may be tuned to the organization's environment.

alert smb $HOME_NET any -> $HOME_NET any (msg:"Potential Netskope logplaceholder ACL tampering via SMB write"; content:"netSkope"; nocase; content:"logplaceholder"; nocase; sid:5000501; rev:1; metadata:cve CVE-2022-4149; classtype:attempted-admin;)

Detection Note: For local-only attacks, network IDS is ineffective. Focus detection on the host-level rules (filesystem and EDR telemetry) instead.

Elastic Detection

// Elastic EQL — detect process creating files under netSkope path by non-SYSTEM security principal
sequence by host.name, user.name with maxspan=1m
  [ file where event.action == "delete" and file.path : "C:\\Users\\Public\\netSkope\\logplaceholder" ]
  [ file where event.action in ("create", "modify") and file.path : "C:\\Users\\Public\\netSkope\\*" and user.name != "SYSTEM" ]

Splunk SPL Query

index=windows EventCode=4663 OR EventCode=4656 earliest=-24h
| rename Object_Name as file_path
| where file_path LIKE "C:\\Users\\Public\\netSkope\\%"
| where Account_Name NOT IN ("NT AUTHORITY\\SYSTEM", "System")
| stats count min(_time) as first_seen max(_time) as last_seen
      by Account_Name, file_path, Process_Name
| eval timeline = last_seen - first_seen
| where timeline < 600
| table _time Account_Name Process_Name file_path first_seen last_seen

Wazuh OSSEC Rule

<group name="netskope_privesc,">
    <rule id="100301" level="15">
        <if_sid>windows</if_sid>
        <field name="win.system.eventID">^4663$</field>
        <field name="win.eventdata.objectName">\.*\\Users\\Public\\netSkope\\logplaceholder</field>
        <description>Access to Netskope logplaceholder by a non-system account — possible CVE-2022-4149 exploitation</description>
        <group>attack.privilege_escalation,attack.t1068,cve.2022.4149</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED) — The CNA (Netskope) claims a fix exists in client versions v100 and later, but this has not been independently verified by a second source. Treat the patch as tentative until confirmed in a full-release changelog.

Immediate Mitigations (to be applied while awaiting/confirming the patch):

1. Restrict the log directory ACL — Set C:\Users\Public\netSkope to allow only NT AUTHORITY\SYSTEM and local Administrators full control; remove Everyone/Authenticated Users write permissions. This neutralizes the race condition because standard users can no longer pre-create the logplaceholder file.
2. Harden the service — Apply the Netskope Client Hardening guidelines referenced by the vendor (https://docs.netskope.com/en/netskope-client-hardening.html), which may include disabling local admin overrides, restricting service account privileges, and enabling tamper protection.
3. Monitor and alert — Deploy the detection rules above (especially the file-system watch on the netSkope path) and alert on any non-SYSTEM writes.
4. Restart-planning — Avoid unnecessary restarts of the Netskope service; each restart is a window for exploitation. Schedule restarts during maintenance windows when forensic monitoring is active.

Patch/Upgrade Steps:

1. Upgrade all Windows endpoints running Netskope client to v100 or later. The vendor explicitly states: "Customers are recommended to upgrade their Netskope clients to v100 or later."
2. Obtain the updated binaries from: Netskope Support — Download Netskope Client and Scripts
3. Test the upgraded client on a small pilot group first (ensure it does not conflict with endpoint security stacks or VPN configurations).
4. Roll out via the organization's standard software distribution tool (SCCM, Intune, or Netskope's own deployment mechanism).

Long-Term Hardening:

• Follow the vendor's hardening documentation: Netskope Client Hardening
• Ensure the service runs with the least privilege where operationally possible (while the vendor may require SYSTEM for full functionality, restrict it if a lower-privilege mode is configurable).
• Audit any privileged service that writes log files — apply the principle that no privileged service should write to a file located in an unprivileged directory. Log directories should be proprietary (e.g., under C:\ProgramData\<vendor> with proper DACLs) and never under C:\Users\Public.
• Enable Windows auditing on C:\Users\Public\netSkope (SACL: Everyone — Write/Delete) and forward those events to the SIEM.
• Verify that the patch is genuine: check the Netskope client version string is ≥ v100 and that the file permission logic has changed (the placeholder should no longer exist or should be created with SYSTEM-only ACLs atomically).

Exploit-in-the-Wild Evidence: None reported. This CVE is not in the CISA KEV catalog, has no public PoC, and the EPSS score (0.00161) suggests zero-to-negligible active exploitation at the time of writing. However, given that this is an easy-to-trigger local race and the target is a widely deployed security product, security teams should patch proactively rather than wait for public exploit code.

References

1. NVD Entry: CVE-2022-4149 — https://nvd.nist.gov/vuln/detail/CVE-2022-4149
2. Vendor Advisory (Netskope CNA): CNA title "Local privilege escalation using log file" (referenced in NVD).
3. Netskope Client Download Page: https://support.netskope.com/s/article/Download-Netskope-Client-and-Scripts
4. Netskope Client Hardening Guide: https://docs.netskope.com/en/netskope-client-hardening.html
5. CISA Known Exploited Vulnerabilities Catalog: N/A (not listed — checked and confirmed absent at publication time).

Threat Actor Campaigns: No known campaigns, exploit-in-the-wild evidence, or vendor security disclosures beyond the NVD/CNA entry are available as of the intelligence-report compilation date. The patch confidence remains 2/4, and the public information is limited to a single CNA claim of using a fixed binary in v100.