Handling security incidents related to Sysinternals tools - ToddMaxey/Technical-Documentation GitHub Wiki

Handling security incidents related to Sysinternals tools


This article aims to references security issues related to Sysinternal tools and provides additional resources so that support engineers may be able to help customers who are desperately trying to raise/clarify a Sysinternal tools issue.

There is no support channel in CSS to support Sysinternal tools. Officially, support of Sysinternal tools is only provided through the Sysinternals Q&A site.

That's being said, Microsoft engineers have access to internal resources that customer doesn't have access to:

  • internal discussion alias for Sysinternals tools: [email protected] (this is the preferred alias to start with any Sysinternal tools question)

  • Sysinternals Core Team : [email protected] (this is the Sysinternals dev team alias which includes Mark Russinovich - only use this alias as you "silver bullet" !)

#CVE-2022-4470


CVE-2022-4470 (Sysmon CVE) can be resolved by either updating the version of the tool to >14.13 (see Yammer - sysmon update?) or removing the tool entirely so it will not trigger a vulnerability scan alert.

#Security solutions raising alerts related to Sysinternals tools

A few security solutions (Cortex XDR, Sentinel One...) are flagging ProcessXP driver as vulnerable. This has been raised in the following post: Process Explorer - ProcExp152.sys Driver Flagged As Vulnerable. At the time of this writing, there is no know CVE affecting the latest version of ProcessXP driver. However, it has been observed that ProcessXP may not automatically update its driver. The version of the driver installed can be checked using sigcheck:


sigcheck C:\WINDOWS\system32\Drivers\PROCEXP152.SYS 

  

Sigcheck v2.82 - File version and signature viewer 

Copyright (C) 2004-2021 Mark Russinovich 

Sysinternals - www.sysinternals.com 

  

c:\windows\system32\drivers\PROCEXP152.SYS: 

        Verified:       Signed 

        Signing date:   20:13 10/11/2022 

        Publisher:      Microsoft Windows Hardware Compatibility Publisher 

        Company:        Sysinternals - www.sysinternals.com 

        Description:    Process Explorer 

        Product:        Process Explorer 

        Prod version:   17.02 

        File version:   17.02 

        MachineType:    64-bit

To force the use of the latest driver, one possibility is to mark the driver for deletion on reboot. This could also be a mitigation to reduce the attack surface (delete ProcessXP driver when not needed) and this can also ensure that the latest driver is uncompressed when you run the latest version of Process Explorer.

To mark the driver for deletion on reboot , you can use the PowerShell script from Using PowerShell to add an entry to "PendingFileRenameOperations" without disrupting previous entries and update the script like this :


Add-Type @" 

using System; 

using System.Text; 

using System.Runtime.InteropServices; 

  

public class PFRO 

{ 

    public enum MoveFileFlags 

    { 

        MOVEFILE_REPLACE_EXISTING           = 0x00000001, 

        MOVEFILE_COPY_ALLOWED               = 0x00000002, 

        MOVEFILE_DELAY_UNTIL_REBOOT         = 0x00000004, 

        MOVEFILE_WRITE_THROUGH              = 0x00000008, 

        MOVEFILE_CREATE_HARDLINK            = 0x00000010, 

        MOVEFILE_FAIL_IF_NOT_TRACKABLE      = 0x00000020 

    } 

    [DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)] 

    static extern bool MoveFileEx(string lpExistingFileName, string lpNewFileName, MoveFileFlags dwFlags); 

  

    public static bool MarkFileForDelete (string srcfile) 

    { 

        bool brc = false; 

        brc = MoveFileEx(srcfile, null, MoveFileFlags.MOVEFILE_DELAY_UNTIL_REBOOT); 

        return brc; 

    } 

} 

"@ 

  

$FullName = "c:\Windows\System32\drivers\PROCEXP152.SYS" 

if([PFRO]::MarkFileForDelete($FullName)) 

{ 

    write-host $FullName "will be deleted on next boot" 

} 

else 

{ 

    write-host $FullName "will not be deleted on next boot" 

}

Of course, above script should be provided with the usual "warnings" (not supported, use at your own risk...etc).


#References


⚠️ **GitHub.com Fallback** ⚠️