2 Replies Latest reply on Dec 2, 2014 9:20 AM by dmease729

    Operational (tuning) fun with signature 6010 (Generic Application Hooking Protection)

    dmease729

      Following post contains questions, and a fair bit of background.  There are some pain points with the Host IPS product and any feedback or comments on the below would be very much welcome!

       

      Hi,

       

      I have deployed Host IPS 8.0.0.2933 (8.0 Patch 4 Hotfix 927324) to a Win 7 Pro SP1 lab virtual machine running in VMWare Workstation.  It is managed by an ePO4.6.6 server running on 2008R2 Standard SP1, with a local instance of SQL Server 2008 R2 (x64 full version).

       

      I have enabled signature 6010 in the Host IPS policies, and a sample of some of the alerts I have been seeing are documented here, here, and here.  As I 'own' all of the servers and applications in this lab environment, I have a great deal of visibility.  However, in a large enterprise environment, we will tend to start with the ePO server itself, and look to work through the events that are coming through in order to determine suitable exceptions with a view to getting to a steady state, and tuned, or 'baselined' policies.

       

      STEP 1: Looking at the Host IPS events via the ePO console

       

      As an ePO admin, I browse to Menu | Reporting | Host IPS 8.0, select the Events tab, and apply an appropriate group filter (in the case of my lab, I have simply selected 'This group and all subgroups' under My Organization, giving me 256 items in 24 pages.  Looking to sort the 'noisiest' signatures first, I aggregate on Signature name (Host IPS), and see the following:

      01 - aggregate sig name.JPG

      Drilling down into the signatures, and having a quick look around, I find the following:

       

      - For the Generic Application Hooking Protection signature, there appear to be two types of event category, 'hook' and 'program'.

      - For those events of event category 'hook':

           - The event description is "A untrusted process attempted to hook process <Threat Source Process Name> running with the privileges of user <Threat Source User Name> on the system with Agent <Detecting Product Host Name>"

           - The threat type in each of these events looks to be 'set_windows_hook' (confirmed with aggregate on sig name, event category, and threat type)

          - In the Threat Event Log Information, we have a Threat Source Process Name

           - In the Host IPS 8.0 Event Information, we have a Handler Path, which is sometimes the same as the Threat Source Process Name (an example from my lab being C:\Windows\System32\MMC.EXE for both entries) and is sometimes different

      - For those events of event category 'program':

           - The event description is "This event indicates an untrusted process attempted to hook another process."

           - The threat type in each of these events looks to be 'open_with_create_thread'

           - In the Threat Event Log Information, we have a Threat Source Process Name

           - In the Host IPS 8.0 Event Information, we have a Target File Name and Target Path

       

      STEP 2: Create exceptions from events

       

      Assuming that nothing 'out of the ordinary' is seen, and an exception is required.  There is further discussion around this assumption below.

       

      When I look to create an exception based on these rules, I note the following

           - For events with event category 'program', the following parameters were included in the automatically created exception rule:

                - Executable (Seems to map to threat source process name in source HIPS event, threat event log information)

                - Target Executable (Seems to map to target path in source HIPS event, Host IPS 8.0 Event information)

                - User Name (will remove as current focus is on general exceptions that are not bound to user)

                - Workstation Name (will remove as current focus is on general exceptions that are not bound to workstation name)

           - For events with event category 'hook'

                - Executable (Seems to map to threat source process name in source HIPS event, threat event log information)

                - Handler Module (Seems to map to handler path in source HIPS event, Host IPS 8.0 Event information)

                - User Name (will remove as current focus is on general exceptions that are not bound to user)

                - Workstation Name (will remove as current focus is on general exceptions that are not bound to workstation name)

       

      Due to the fields above (with the exception of user name and workstation name) being the 'interesting' fields, I want to get an idea of what events are happening the most, so look to aggregate further, however the columns available for aggregation do not seem to include any of: Target executable, Target Path, Target Filename, Handler Module or Handler Path, although I note there is Threat Target File Path and Threat Target Process Name, however both of these return blanks when used in event aggregation.


      STEP 3: Use the optional adaptive mode - see what happens!


      Enable adaptive mode to see what client rules come in - let the product do the work for me!  After a short period of time (in which I quickly ran a netstat, as I noted in an earler post that this triggered the signature) we had 3 entries showing in the Windows 7 host HIPS console.  Interesting that MCAFEEFIRE is in there now, as I have not seen this in the logs before!  (I repeated the tests, and this client rule appeared straight away again):

      02 - adaptive 1.JPG

      In ePO, we see the followin client rules, which look a little different:

      03 - client rules.JPG

      I created exceptions for them all (automatic - using the client rules), and note the following (only the most important elements for the purposes of this discussion noted):

       

      Exception 1:

      - Executable: C:\Windows\System32\CMD.EXE

      - Target Executable: C:\Windows\System32\NETSTAT.EXE

      - User Name was listed

      - Workstation name was not listed

       

      Exception 2:

      - Executable: C:\Windows\System32\SVCHOST.EXE

      - Target Executable: C:\Program Files\McAfee\Host Intrusion Prevention\MCAFEEFIRE.EXE

      - User Name was listed

      - Workstation name was not listed

       

      Exception 3:

      - Executable: C:\Windows\System32\CONHOST.EXE

      - Target Executable: C:\Windows\System32\NETSTAT.EXE

      - User Name was listed

      - Workstation name was not listed

       

      Now to be completely honest, I have had issues with adaptive mode before (I will need to search for my previous post) as I dont think it works well with some signatures (and these sigs have 'allow creation of client rules' selected by default), but adaptive mode appears to be doing the trick in this case, which is nice!

       

      So... now I have (eventually) set the scene, I have the following questions/concerns (Note that some of the notes below make reference to KB71794, dated 19 June 2014:

       

      Q1) In an ePO administrators position, for this particular signature I appear to be able to aggregate on one of the key fields, but not the other.  I can aggregate on Threat Source Process Name, which looks to map to Executable in the IPS exceptions, but I cannot aggregate on Target Executable, to see what is actually being hooked (ie a.exe is hooked 20 times, and b.exe is hooked only once - is the latter more suspicious?).  Is whitelisting (KB71794) the only sensible option (ie forget about the target executable), or are there security caveats around this approach (ie can a whitelisted executable be 'hijacked' somehow?  Is it more secure to configure exceptions based on both the executable *and* the target executable?

       

      Q2) In an enterprise environment, it is likely that an event will need to be investigated to determine if what is happening is actually expected or potentially part of an attack.  In order to create an exception, it is likely that sign off will be required by an entity that does not have access to the ePO console.  While in business as usual, the events will (should) be sparse, and allow the ePO admin time to clarify what the event means, during the tuning process, it appears that a lot of manual work will be involved - It looks like I can get a lot of data from queries and reports, however no information that will be useful to a security authority that needs to sign off on exceptions (in this case we can only provide 'executable X has hooked *something*' (without further digging from an ePO admin).  Further to this, if we did provide a raw report, there is no available context behind the data presented in that report (the below would be something that is presented to a non-ePO admin).  If we do not make it absolutely clear what is happening to whoever may be signing off possible exceptions, it is entirely possible that exceptions can be misconfigured, or in worst-case, due to misunderstandings, that an attack is missed.  The data is there.  The reporting needs to be a lot better.

       

      Following output based on default query 'Host IPS: Desktop Medium Triggered Signatures':

      04 - query 1.JPG

      "Ah yes!  Something has tried to hook something... I think... ... ... ... ..."


      After duplication and modification to include the relevant fields (the 'threat target file path' has been included as it is the only available column related to threat target file or process):

      05 - query 2 (modified).JPG

      So - we have what we believe to be the hooking processes (at least we assume - although a relatively safe assumption, this is essentially data and not information - which I think can only be obtained by going into each event on ePO separately so you get a friendly phrase describing what is going on).

       

      And what if we look to send that as a report (perhaps a CSV file?), we get something similar to the following.  In the tuning phase, when there will be a large number of events to run through, this would be problematic, as a)we dont have the full data required (I am not sure how other signature types fare with this), and b)even

      with all the data, it is not something that can be presented to a decision maker.

      06 - CSV.JPG

       

      Community post 358069 mentioned an enhanced reporting extension, so hopefully something will come of this.  The community post also refers to a PER I have raised.

       

       

      Cheers!

        • 1. Re: Operational (tuning) fun with signature 6010 (Generic Application Hooking Protection)
          greatscott

          The quick answer is, that 6010 will probably afford you *some* protection, but can't be completely relied upon for protection. You can use it as a whitelist approach, but I maintain that HIPS is not the best whitelisting option. In a large environment, this signature triggers a lot. I agree to some extent about what is being hooked, versus what process is doing the "hooking". The easiest way to do this, is create digital signer exceptions for the Target Executable. Unfortunately, the way you aggregate these signers is with the use of the IPS Param Name, and Param Values. As you had mentioned, this functionality is not available to all. Again, in a large environment, the sheer total of 6010/6011 events is insurmountable when viewed one by one.

           

          That said, 6010/6011 tuning is an arduous process. I'd probably set these signatures to informational for a month or two, and start writing exceptions. When you feel you are to a point where events have slowed, or are non existent, start blocking the signatures. Just know that as the environment expands and changes, you will need to alter your exceptions. 6010/11 tuning is never complete.

          • 2. Re: Operational (tuning) fun with signature 6010 (Generic Application Hooking Protection)
            dmease729

            Cheers for the feedback - main approach we are looking to take is to not block, just log (still keep tuning, however).  There is SIEM integration here, so although anything suspicious would be allowed to happen, there would still be visibility within the standard monitoring system.  We are looking to ramp up deployments early next year, so I will keep you updated with what happens :-)