Kaseya Community

New Intel ME Vulnerability detection

  • Does anyone have a script to detect the new Intel ME vulnerability announced yesterday?


    Looks like there is a command-line detection tool available from Intel.


  • I put something together this afternoon. It was a pain to troubleshoot and I can't post the specific script right now but here's what I did.

    1. Unzip Intel's discovery tool and copy just the 'DiscoveryTool' folder to VSASharedFiles on your VSA server. Optionally delete any languages you don't need from the 'DiscoveryTool' folder.

    2. Create in that folder a batch file called Run.bat with the following contents. This will ensure the executable runs from the 'correct' start folder.

    cd /D %~dp0

    Intel-SA-00086-console.exe -c

    3. Create a Kaseya script to:

    a. Write Directory the DiscoveryTool folder from your VSA server to #vAgentConfiguration.AgentTempDir#\DiscoveryTool

    b. Execute file as system #vAgentConfiguration.AgentTempDir#\DiscoveryTool\Run.bat

    c. Check the result under HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\System Status\System Risk  - note you'll need to do separate checks for 32-bit and 64-bit systems using the getRegistryValue or get64BitRegistryValue as appropriate. That registry key will contain: This system is vulnerable. (note the trailing dot) if it's vulnerable.

    Sorry if this is unclear, I'm in a rush today but can try to explain further later if required.

  • Procedure Intel ME FW Vulnerability (Intel-SA-00086).xml

    Building on instructions - procedure attached.  Note: I have a section for differentiating 32/64 bit but when I ran it on a 64 bit Win10 system it wrote to the 32 bit location.  

  • Hi ,

    Apparently the tool doesn't write to WOW6432Node (assuming you are talking about the registry).  I found the same behavior.



    Rephrased my response
    [edited by: bud.manz at 4:59 AM (GMT -8) on Nov 30, 2017]
  • WOW6432Node is where 32-bit app read/writes are redirected when running on a 64-bit system.

    Intel's discovery app correctly writes to the 'native' location so that it will always be HKEY_LOCAL_MACHINE\SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\System Status\System Risk

    From what I understand the Kaseya agent (being a 32-bit app) would be redirected to the WOW6432Node unless specifically told (by using the get64BitRegistryValue step) to read from the 'native' location on a 64-bit system.

  • I created an Agent Procedure to scan endpoints for the Vulnerability and update a custom field with the result.

    You can find it at:


    Let me know if anyone has any questions/feedback. 

  • Hi Douglas,

    Thanks for writing the script.  I have deployed it to about 30 machines and am not getting the results I expected.  I was hoping you can help.  All of the machines attempted so far are 64 bit machines.

    One machine came back with a success message, and I checked the custom field and the machine is not vulnerable.  All of the rest of the machines (thus far) are coming back with “Script Summary: Failed THEN in step 8 (line 15)”.  

    One of the machines I ran it on was my own.  So, I went into the working directory, found the unzipped powershell script.  I tried running it in powershell and it produces an error.  The error is below copied out of powershell:


    The term 'Get-ItemPropertyValue' is not recognized as the name of a cmdlet, function, script file, or operable program.

    Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

    At C:\kworking\Inteltest.ps1:4 char:23

    + {Get-ItemPropertyValue <<<<  "HKLM:\SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\Sys

    tem Status" "System Risk" | Out-File c:\kworking\Intel.txt}

       + CategoryInfo          : ObjectNotFound: (Get-ItemPropertyValue:String) [], CommandNotFoundException

       + FullyQualifiedErrorId : CommandNotFoundException


    I am not good at scripting whether within Kaseya or powershell, so if you have thoughts, I would appreciate hearing them.


  • That particular cmdlet was actually added in powershell version 5.   My guess is that the machines where this is completely failing need an update to powershell for it to work correctly.

  • Well, That seems to make sense as the rest of results came in.  The machines that have success are all Win10.  The problem now is all of the rest are Win7 which do not support PSv5, according to MS anyway.  I will keep looking for ideas but if anyone else has an idea, that would be fantastic.

  • You should be able to rewrite that one line of the script to be more backwards compatible..

    Change the ExecuteShellCommand line that starts as "echo {Get-ItemPropertyValue....".

    Replace the portion Get-ItemPropertyValue"HKLM:\SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\System Status" "System Risk"

    With the following

    (Get-ItemProperty "HKLM:\SOFTWARE\Intel\Setup and Configuration Software\INTEL-SA-00086 Discovery Tool\System Status" -Name "System Risk")."System Risk"

    it *should* function the same but be compatible with powershell down to version 1.0.  

    I haven't tested it myself, but that *should* work. 

  • That did the trick.  I still have one lingering failure that I have not investigated, but I am hopeful that since everything else went so smooth, this is pretty well done.  Thanks!

  • It is actually possible to update Powershell on Windows 7. I had released a procedure on the exchange to update Powershell to 5.0


  • - Yes it's possible, but sometimes where possible it's best to write these type of scripts to be as backwards compatible as possible so that you don't have to follow through multiple steps just to execute the one procedure. By simply modifying that one line, you no longer *require* updating powershell on windows 7 and the procedure will "just work".  

    Otherwise you end up having to first run a procedure to update windows powershell on everything before you can run the procedure to check for the Intel ME vulnerability procedure.  While *yes* long term it is probably not a bad thing to have the updated powershell on there, in the short term you made just checking for the ME vulnerability more difficult than it needs to be.

    As an MSP with over 1500 endpoint under management in a variety of environments, we get run into a lot more scenarios where we can't necessarily control a lot of things, and we learn to write our scripts and procedures to the lowest common denominator.  For example I have at least a couple of machines currently under management where I know for a fact that updating to the newest available version of powershell actually *breaks* some of their line of business apps, (yes poorly written software, but again not something I can control).  That's just a prospective that you might want to keep in mind when writing procedures for Kaseya for the automation exchange.  It's understandable that sometimes it is more difficult or downright impossible to accomplish some tasks with some of the older operating systems without running some other third party update, but when it *is* possible you should take the time to try and make it work on as many systems as possible.

  • ClobMSP have a free script now: clubmsp.com/.../intel-sa-00075-detection-and-mitigation-tool-script

  • Since I posted my initial solution I see Intel has released an updated version of their detection tool that looks for additional CVEs. I'd advise re-scanning everything that reported not vulnerable with the latest version of their tool. Thanks Intel, this management engine issue is truly the gift that keeps on giving!!

    fyi new version of the detection tool is

    UPDATE: ..and it looks they've repackaged everything, so be aware your existing procedures may need to be tested / adjusted accordingly.

    added further info
    [edited by: Combo at 6:50 PM (GMT -8) on Dec 12, 2017]