Jason Creech

QualysGuard Policy Compliance - Using Custom Controls to Identify Root Kit

Discussion created by Jason Creech on Jan 30, 2012

Hello,

 

 

As policy compliance SME at Qualys, I often find that customers subscribe to the Policy Compliance (PC) service initially to audit their IT system configurations against one or more configuration hardening policies, whether internally created and based on some authoritative source like CIS or NIST or mandated by some industry regulator.

 

 

Policy Compliance automates the gathering of configuration data and the reporting of adherence of IT assets to these configuration requirements. And, since existing VM customers have already installed the architecture needed to perform vulnerability scanning, that same infrastructure can be leveraged to perform compliance scanning if that VM customer has also subscribed to the PC service.

 

 

But, I have also seen that as organizations come to understand the capabilities made available by the PC service, they realize they can use policy compliance beyond just compliance reporting and find creative ways to use PC as a query tool for their infrastructure.

 

 

Recently, I was onsite with a current customer who was using both Policy Compliance and Vulnerability Manager Services to report on the compliance and security postures of their IT assets. In the course of our discussing how PC does support the creation of custom controls (configuration checks), they mentioned that they had gone through many hours of manual processes and working with multiple administrators to identify systems that had a root kit locally installed on them.

 

 

The customer had noted the presence of a root kit on one system and when they went through the manual process, found that the root kit was more prevalent in the Windows environment. Since they had already identified a signature that was present in each root kit implementation, I was able to show them how leveraging PC's User Defined Control for File Existence would help automate the detection of this particular root kit definition.

 

 

It is important to note that the same root kit files are often renamed to obfuscate their presence. This is why static checks often fail... in this case, the support for custom controls by Qualys PC is useful because we are able to create a check for a specific signature that has been discovered but may unique to this environment.

 

 

In this case, this signature was the presence of a file named zcmdsvc.exe in a particular folder, c:\Windows\System32\ (or %WinDir%\system32\zCmdSvc.exe).

 

 

Here is a link to a Microsoft Article with related information:

 

 

http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=HackTool%3AWin32%2FPipecmd.B

 

 

Also, since virtualization can cause partition labels to be different than C:\, the use of these environmental variables is supported:

 

 

  • %SystemRoot%
  • %windir%
  • %ProgramFiles%
  • %CommonProgramFiles%

     

    So, to create this User Defined Control (UDC), simply follow these steps:

     

     

    1.) Login to QG and navigate to the PC module

    2.) Select Policies, then the Controls tab, then New => Control

    3.) Select Getting Started on the Files/Directories Existence option

    4.) Enter in the Control Statement (Title), category and sub category

    5.) Select the "Add Parameters" button and enter the filename/path information and a description of why this parameter is needed

    6.) Then click the Add button

    7.) Now that the parameter is added, select the Windows Technologies the filename/file path are relevant

    8.) Enter a description in each rationale section about why this check is important

    9.) Set the default value to false, note you can change this value later if needed

    10.) Click the "Create" button

     

     

    You have now completed the creation of a new custom control that has been added to the controls library.

     

     

    At this point, since you have added a new datapoint, you will need to rescan the target IT assets with a compliance scan.

     

     

    Also, at this point, the User Defined Control that was created above behaves like any other control in the Qualys library. To generate report data, simply add the control to a policy, assign appropriate asset groups, and then (after the compliance scan is completed) run a compliance report for that policy. Any systems that have the zcmdsvc.exe file in %WinDir%\System32\ will fail the control which should be evident in the report.

     

     

    There may be several other methods to use Qualys Controls to detect such a root kit. Qualys had controls that check for prohibited software packages or processes running in memory as well as additional UDC options such as file integrity which leverages MD5, SHA-1, or SHA-256 to evaluate file hashes as well.

     

    Using these tools allows for many different methods in this type of evaluation.

     

     

    If anyone has additional use cases of how Qualys PC has been useful in detecting Advanced Persistent Threats such as the above root kit or with general infrastructure queries beyond compliance reporting, please share these use cases in the community.

     

     

    Around mid 2012, PC may support import/export of UDC’s which will make them very portable and this forum will be a great place to store such configuration audit controls as attachments.

     

    As always, best regards and have a nice day!

     

    Jason Creech | jcreech @qualys.com

    Director, Policy Compliance
    Qualys, Inc. | On Demand Security | http://www.qualys.com
    Direct: (281) 677 5226  |  Cell: (281) 702 2737
    Blog:
    http://news.qualys.com
    Twitter: http://twitter.com/qualys
    Join our community: http://community.qualys.com

    Outcomes