Kaseya Community

Intel AMT vulnerability detection

  • Thanks for sharing! I checked it out.I really care about any security problem right now since the hot issue wanner cry occurredBig Smile. ]]

    Thanks for the link anyway.

  • I wanted to follow up on my earlier comment regarding intermittent XML file processing in this thread.  GreyDuck made some good suggestions and off I went to troubleshoot my end.  What I ultimately found is that the XML filename is built off of the %computername% Windows variable.  The script uses vMachine.MachName on the Kaseya side.  If you look in the database tables listing for this variable in Kaseya help it implies vMachine.MachName = %computername%.  However, this is not accurate and the cause of issues on my end - I was actually able to prove this by adding a handful of Kaseya system variables to the script and writing them to the procedure log.  Here's why:  

    In our VSA it is often the case that the endpoint name in Kaseya is not the same as the computer name (MachineID in Kaseya).  For example, the PC might be named PC1001 and after it shows up in Kaseya we might rename it to PC1001-joe.  We do this to make some reports a little easier to make heads or tails of.  So, in my case vMachine.MachName did not equal %computername% and thus the blank AMTvulnerability.txt file.  

    I couldn't find a system variable that reflected the MachineID (which looks to be the same as %computername%).  So I simply pulled the computer name from the system registry, put it in a variable called #compname# and used that in the XML processing line.  And it works.  So, if your computer name is not the same as the Agent name you might have to make a slight adjustment to the script to make this work for you.  

    Also, I took Karoded's advice and can confirm (at least for HP) we can install the bios updates using Application Deployment and the command line switches he provided (/S /v"/qn /norestart). It is pretty seamless and all that is required is a re-run of GreyDuck's script to update the custom variable and then produce a report showing the AMT vulnerability status.  

    Again, huge THANKS to GreyDuck for doing the heavy lifting on this.  And thanks to Karoded for bringing it full circle.  

    corrected some typos
    [edited by: LR at 5:33 PM (GMT -7) on Jun 13, 2017]
  • this is appreciable contribution, am certainly going to test it out.

    Do you have a procedure to enabe vPro settings without logging to endpoints?

  • D'oh! Sorry about that, LR (and others)... we've been using "force machine name to match computer name" for all clients for over a decade, so I didn't even notice the potential discrepancy. Nice catch, there!

    Rajeev, I haven't poked at vPro since we did a trial with Intel years and years ago, sorry.