Monday, 31 March 2014

Custom McAfee HIPS Rules That Actually Work

In this post I'm going to talk about McAfee HIPS expert rules and provide some real world examples of ways to actually catch the bad guys.

For more info on McAfee HIPS check the manual (page 101 onwards) here: https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/22000/PD22894/en_US/Host%20Intrusion%20Prevention%20800%20Product%20Guide%20for%20ePO%20450.pdf

Disclaimer - I'm not a malware guru and this post will likely be me trying to reinvent the wheel. If you have any tips or know any good HIPS resources please drop me a comment below!


Catching Bad Guys With HIPS

For an attacker to gain a foothold in your organisation they will need to run code on your systems, drop files and also setup persistence. Without these items they have no foothold. AV usually approaches this problem with a signature blacklist but as we all know this can be easy to evade.

Host intrusion detection/prevention on the other hand, can be more effective because instead of just blocking the known bad you can monitor everything and then remove the good, to find the bad. By whitelisting known good combinations of filenames, locations, processes, registry keys etc. you'll effectively be left with just the bad activity (plus a small number of false positives).


Hey I use McAfee too!

McAfee produce a HIPS product that uses a kernel-level driver to monitor system calls, if specific criteria are met you can either create an alert or block the activity. Like most security products the default signatures are out-dated and prone to false positives. What's more, as they are proprietary the actual signature content is neither visible or modifiable, making tuning and investigation tough.


Luckily McAfee allow you to create your own custom rules using a limited subset of system calls related to files, the registry, processes and a few other things. Sadly McAfee don't let you monitor arbitrary system calls like Ambush IPS.

Implementation sidenote - Avoid filtering HIPS alerts using "Exception Rules" they're just messy, use custom rules instead and avoid "Access Protection" rules they don't offer enough granularity.


The Expert Template

To create a new HIPS rule in McAfee EPO go to Policy Catalog -> Product: Host Intrusion Prevention -> Category: IPS Rules, select your IPS rules policy then click "New" to add a custom rule. Under the subrules tab select "New Expert Rule". Expert rules are more customisable and easier to manage so I would definitely recommend using them over basic rules. (Although it can be useful creating basic rules and clicking the preview button, as this will give you the basic code needed for the expert rule.)

The template that most rules follow is something like the following:

Rule {
 tag <tagname>
 Class <either File/Registry/Service/Process>
 Id <ID assigned by EPO>
 level 3
 attributes -no_trusted_apps
 <class value> { Include "<something>" }
 <class value> { Exclude "<something>" }
 Executable { Include "*" }
 Executable { Exclude { -path "<something>"} } 
 user_name { Include "*" }
 directives <class:action1> <class:action2>
}

All parameters in angle brackets < > should be replaced with values. Starting from the top, name and ID are self explanatory, you need to save the rule and an ID will be assigned that you can add to the rule later. The level is the severity from 0 to 4 (informational to high) The "Class" depends on what type of rule you want to create, I'll cover some examples below. There will be specific inclusions and exclusions for the class. You can also define specific executables you either want to include or exclude from monitoring. Finally the "directives" part defines the specific actions (API calls) we want to watch, for example, file creation will be "files:create".

Wildcards: & = everything except slashes (so no path traversing), * = everything including slashes.
Both are useful for different situations and balancing extra visibility with false positive reduction.


File Activity

99% of the bad guys in the world today will write files to disk for functionality and persistence reasons. For a defender that's awesome as we now have a way to detect when a machine is compromised.

Attacker Tip: Don't write files to disk, do everything in memory!

McAfee HIPS supports monitoring of file create, read, write, execute, delete, renaming, attribute modification and hardlink creation. We just need to define which file path/type we want or don't want to alert on and any executables we want to include (known bad sources) or exclude (known creators of false positives).

Below is a basic file monitoring template that looks for all exe's and dll's created in system32:

Rule {
 tag file_create_write
 Class Files
 Id 4001
 level 3
 attributes -no_trusted_apps
 files { Include "C:\\Windows\\System32\\&.dll" "C:\\Windows\\System32\\&.exe" }
 files { Exclude "C:\\example\\exclude" }
 Executable { Include "*" }
 Executable { Exclude { -path "c:\\Windows\\System32\\MRTSTUB.exe" } { -path "C:\\Windows\\System32\\SPOOLSV.EXE"} } 
 user_name { Include "*" }
 directives files:create files:write
}

In the "files" section you can see how you just "Include" the path you're interested in surrounded by quotes. The ampersand acts as a wildcard and remember to use double slashes in paths! I ignore ("Exclude") any file created by mrtstub.exe or spoolsv.exe as these guys generated more false positives than true positives.

Creating any rule is a balancing act between greater visibility and false positive reduction. To improve the effectiveness and accuracy of signatures it helps to focus on known bad locations, extensions and processes. I've included some suggestions below (Microsoft has a location list here):

Potentially bad extensions:
exe, dll, bat, pif, scr, com, ps1, vbs, vbe, js, lnk, tmp, jar, class, jnlp, doc(x), xls(x), pdf

Potentially bad locations:
C:\Windows
C:\Windows\System32\*
C:\Windows\System32\drivers
C:\Program Files

Win7 specific:
C:\Program Files(x86)
C:\Windows\SysWOW64
%Temp% = C:\Users\<user>\AppData\Local\Temp
%Appdata% = C:\Users\<user>\AppData\Roaming
%ProgramData% = C:\ProgramData
C:\Users\<user>\AppData\LocalLow\Sun\Java\Deployment\cache
C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

WinXP specific:
%Temp% = C:\Documents and Settings\<user>\Local Settings\Temp
%Appdata% = C:\Documents and Settings\<user>\Application Data
C:\Documents and Settings\<user>\Application Data\Sun\Java\Deployment\cache
C:\Documents and Settings\<user>\Start Menu\Programs\Startup

Potentially exploitable executables:
Java = C:\Program Files (x86)\Java\jre7\bin\java.exe
Javaw = C:\Program Files (x86)\Java\jre7\bin\javaw.exe
Internet Explorer = C:\Program Files (x86)\Internet Explorer\iexplore.exe
Microsoft Office = C:\Program Files (x86)\Microsoft Office\Office*\<product>.exe
Adobe Reader = C:\Program Files (x86)\Adobe\Reader *\Reader\AcroRd32.exe

Executables malware might inject into:
svchost.exe, explorer.exe, rundll32.exe, winlogon.exe, notepad.exe

Putting this all together we get some interesting use cases:
  • Java applet loaded, java.exe creates .idx or .class file in Java cache
  • Malware running from svchost.exe drops exe/dll in %Temp% 
  • New files added to startup folder or scheduled tasks created for persistence
  • Rootkit (*.sys) dropped in drivers folder
  • Unusual files (bat, pif, scr, com, vbs, vbe) created in, or executed from %Temp% and %Appdata%
Bare in mind that if the attacker migrates processes the exploited programs themselves may not drop malware, so if possible don't restrict the rule to a specific source executable. As a real life example a Java exploit I analysed this week used svchost.exe to drop a payload triggering a rule similar to this:

Rule {
 tag svchost_create_exe
 Class Files
 Id 4002
 level 3
 attributes -no_trusted_apps
 files { Include "C:\\Users\\&\\AppData\\*.exe" }
 files { Exclude "C:\\example\\exclude" }
 Executable { Include { -path "C:\\WINDOWS\\SYSWOW64\\SVCHOST.EXE" } }
 Executable { Exclude { -path "c:\\example\\exclude" } } 
 user_name { Include "*" }
 directives files:create files:write
}


Registry Activity

The registry is another favourite area for attackers to target because of persistence and access to system settings. There are loads of persistence locations, I've included some below but a lot of the time malware will go for the really obvious CurrentVersion\Run. It can also be useful to look for changes to things like windows update, firewall or security centre.

Using HIPS we can monitor registry activity to detect the creation/access of keys at known sensitive locations. McAfee supports monitoring of create, read, delete, modify, permissions, enumerate, monitor, restore, replace, load, and rename system calls.

A basic registry monitoring template is below:

Rule {
tag "HKLM/HKCU Wscript Run Value"
Class Registry
Id 4003
level 3
Executable { Include { -path "c:\\windows\\system32\\wscript.exe" } }
values { Include "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\&" "\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\&" "\\REGISTRY\\CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\&" "\\REGISTRY\\CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\&" }
values { Exclude "\\REGISTRY\\MACHINE\\SOFTWARE\\MICROSOFT\\WINDOWS\\CURRENTVERSION\\RUN\\SYNCHRONIZATION MANAGER" "\\REGISTRY\\CURRENT_USER\\SOFTWARE\\MICROSOFT\\WINDOWS\\CURRENTVERSION\\RUN\\CTFMON.EXE" }
directives registry:create 
}

In this rule I'm looking for suspicious registry entries created by wscript, which is useful for detecting the vbs malware mentioned in my previous posts. I've included multiple registry run locations where malware will often create entries and excluded some false positives. Note that McAfee uses a slightly different syntax for registry paths, HKEY_LOCAL_MACHINE = MACHINE and HKEY_CURRENT_USER = CURRENT_USER.

Below are some common registry locations in ready to use McAfee format, a more comprehensive list can be found here and for comparison there is a real life ZeroAccess example here.

Common persistence locations:

\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\&
\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\&
\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\RunOnceEx\\&
\\REGISTRY\\MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\AppInit_DLLs\\&
\\REGISTRY\\MACHINE\\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\\&
\\REGISTRY\\MACHINE\\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer\Run\\&
\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet\\Services\\&
\\REGISTRY\\MACHINE\\SYSTEM\\ControlSet\\Services\\&\\Parameters\\ServiceDLL\\&

Windows Firewall 
\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy
Windows Security Centre
\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\wscsvc
Windows Update
\\REGISTRY\\MACHINE\\SYSTEM\\CurrentControlSet\\Services\\wuauserv

Above are the HKLM entries, you can specify equivalents for HKCU (or use the & to cover both) e.g.
\\REGISTRY\\CURRENT_USER\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\&


What about Programs?

The McAfee programs class covers new process creation (program:run or CreateProcess) and opening of existing processes with specific permissions (program:open_with_x or OpenProcess). Program:run can let you to track potential malware executing from the %temp% or %appdata% folders (Target_Executable { Include { -path "C:\\Users\\&\\AppData\\Roaming\\*.exe"}}) or even track the use of built-in utilities such as Powershell or Remote Desktop.

For example to track Powershell usage but exclude a known admin user:

Rule {
tag "Powershell execution"
Class Program
Id 4004
level 3
Target_Executable { Include { -path "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" } \
{ -path "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\powershell.exe" }
}
user_name { Exclude "domain\\john" }
directives program:run 
}

OpenProcess is often used when performing code injection, the catch is that it's also used by legitimate programs. You can try detecting code injection of explorer.exe for example by using the open_with_ directive, this Intel post has a good explanation but be wary of the false positives.

Taken from the link above the directive permissions you'll want are:

PROCESS_VM_OPERATION      // For VirtualAllocEx/VirtualFreeEx
PROCESS_VM_WRITE                // For WriteProcessMemory
PROCESS_CREATE_THREAD     // For CreateRemoteThread


Hooking (SetWindowsHookEx)

SetWindowsHookEx can be used nefariously for both DLL injection and hooking (interception of function calls, events or messages within a process). There's a great explanation on the Volatility blog here.

McAfee HIPS supports monitoring of SetWindowsHookEx usage and can alert you to potential dll injection/hooking attempts. To detect browser keylogging we can use a rule like the following:

Rule {
 tag browser_hook
 Class Hook
 Id 4005
 level 3
 attributes -no_trusted_apps
 Executable { Include { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\INTERNET EXPLORER\\IEXPLORE.EXE" } { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES (X86)\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE" } { -path "C:\\PROGRAM FILES\\MOZILLA FIREFOX\\FIREFOX.EXE" } { -path "C:\\PROGRAM FILES (X86)\\MOZILLA FIREFOX\\FIREFOX.EXE" }}
 Executable { Exclude { -path "C:\\example\\exclude" } } 
 Handler_Module { Exclude { -path "C:\\WINDOWS\\SYSTEM32\\MSHTML.DLL" } { -path "C:\\WINDOWS\\SYSTEM32\\IEFRAME.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\MSCTF.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\EXPLORERFRAME.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEDVTOOL.DLL"} { -path "C:\\WINDOWS\\SYSWOW64\\SHELL32.DLL"} { -path "C:\\WINDOWS\\SYSTEM32\\SHELL32.DLL"} { -path "C:\\PROGRAM FILES (X86)\\INTERNET EXPLORER\\IEXPLORE.EXE"} { -path "C:\\PROGRAM FILES\\MICROSOFT\\INTERNET EXPLORER DEVELOPER TOOLBAR\\IEDEVTOOLBAR.DLL"} { -path "C:\\PROGRAM FILES\\GOOGLE\\CHROME\\APPLICATION\\CHROME.EXE"} }
 user_name { Include "*" }
 directives hook:set_windows_hook
}

You'll likely see DLL's being loaded for all kinds of different browser extensions and toolbars. Apart from browser hooking I haven't really tested this rule with other use cases, would love to hear some suggestions.


And finally...services!

The final type of rule I'll cover is related to services. Services offer another persistence mechanism for malware to abuse and interestingly are also used during lateral movement with psexec (see Metasploit psexec here - you could also monitor file creation/execution in ADMIN$).

I found new service creation to be relatively infrequent so easy to monitor for suspicious activity. The following rule will catch new service creation - I've excluded some false positives:

Rule {
tag "New service created"
Class Services
Id 4006
level 3
display_names { Include "*" }
display_names { Exclude "GUPDATE" "GUPDATEM" "MOZILLAMAINTENANCE" "JAVAQUICKSTARTERSERVICE" "IPOD SERVICE"}
directives services:create 
} 


Monitoring your rules

With all your rules created, deployed and churning out events we obviously need some way to monitor the events. SIEM is the best choice but if EPO is your only option then you'll need to create a custom query.

I created a query with the following properties:
  • Result: Type set to Events -> Threat Events.
  • Chart: Use a Multi-group Summary Table. Labels -> Threat Name and Signature Name.
  • Columns: Make sure to include Threat Name and Signature Name.
  • Filter: Event ID 18000, 18001, 1092. Threat Name equal to your signature ID e.g. 4001
This query should give you a list of your signatures and how often they have triggered.


Final Thoughts

Creating custom HIPS rules isn't always easy, it takes time to develop use cases and you will get a lot of false positives that will need to be tuned out. Once perfected though custom rules can give you some great visibility of activity on your systems and also highlight areas for improvement (better email or web proxy filtering, tighter folder/registry access restrictions etc.).

Evil-minded readers may have already spotted the obvious that it is easy to evade HIPS rules by either using system calls not monitored by HIPS or by using files/locations/processes/services that have been excluded (whitelisted) in the rule. The answer really is to use a product that sees and logs everything (not Mcafee).

I'd love to hear feedback from you guys about HIPS rules that do/don't work and specific files, locations, activity you've found useful, drop me a comment below. And remember, if in doubt, log it all, you can always filter later :)

Pwndizzle out.


5 comments:

  1. First of all thanks for the post. Glad to see someone else is using HIPS as much as it can be. You've given me some ideas as well as making clear how and why some of the more obscure rules are useful. You've also pointed out the incredible downside to products like this: You are confined to browsing logs of only certain API calls and bits of API calls the vendor thought was worthwhile. It may leave your mouth watering.


    A few things I'd like to add:

    1. You can see how McAfee made their Default rules by dumping the FireSvc process by right clicking it in task manager on an endpoint that has HIPS running. Open it with something that can handle big files like vim. You won't be impressed, but can use it to find new values to use.

    2. target_bytes, Caller_Module, and API_Name are all pieces you can use in Buffer Overflow class rules. If you have malware samples that you can run through HIPS, these fields will be incredibly useful for finding needles in your haystack. Of course, not every sample triggers BO rules. See the memory dump for usage.

    3. Data in Registry class rules. Not sure if you've seen this, but you can watch for the actual DATA in a registry value changing, not just key/value behavior:

    tag "Reg key"
    Rule {
    Class Registry
    Id -1
    level 3
    values { Include "*\\regkeytest" }
    new_data { Include "68006900*" "680065006c006c006f00*" }
    directives registry:modify
    }
    Convert your data value string to hex and add 00's after each character. The above looks for hi* and hello*. Sadly, the fired events return hex as well. Painful to dig through.

    4. Again, if you have samples, you can run ClientControl.exe /execinfo on a executable to get the "Description" and "Signer(certificate)" fields. Use this kind of custom rule to look for BITS and PIECES of known bad certificates in a program rule:

    Rule{
    tag "look for multiple signers/certs with stars in them because we only know pieces"
    Class Program
    Id 5809
    level 3
    Executable { Include { -sdn "*OU=MPR*" } \
    { -sdn "*OU=MOPR*" }
    }
    directives program:open_with_wait etc...
    }
    You CANNOT add stars in the front from the rule wizard GUI Executable/Target Executable Signer area. Without stars you are limited to full certs as such: CN=MICROSOFT CORPORATION, OU=MOPR, O=MICROSOFT CORPORATION, L=REDMOND, ST=WASHINGTON, C=US. If you want to pivot, use stars on bits and pieces of bad certs.



    Finally, two questions for you:

    1. Have you found that there is actually a difference between registry rules watching for entries in the services area, vs making a service rule? I haven't, but I suppose if you don't know what you are looking for, using a wide open service rule would do it justice.

    2. Have you found a good way to watch a known bad MD5 doing anything and everything to target executables, files, registry keys and services without making a new rule for each class? I am now understanding HIPS was made from the opposite view point in mind - not knowing what you are looking for.

    ReplyDelete
  2. Hey, thanks for such a great comment and suggestions. I'm glad you found the post useful :)

    1. Wow what a great little trick. As mentioned in the post I had pretty much given up on the McAfee built rules. But seeing their secret sauce is certainly interesting and useful.

    2. With so many exploit techniques out there I was always a little skeptical of the BO rules. Also with EMET covering exploitation the rules weren't a high priority for us. Will give them a second look though.

    3.The whole hex registry key thing is absurd, really not sure why they haven't updated that. I currently use the modify directive for watching CurrentControlSet registry key changes and a few others, it's pretty handy.

    4. Interesting will test it out.

    Q1 - Different directives will monitor different system calls and provide different visibility. I think there's definitely a bit of duplication and seeing the other side of the same coin but that's not always the case. Remember the old adage "defense in depth", what one rule might miss the other might detect. Better to log it all and have duplication than miss something.

    Q2 - Short answer no. I tend to avoid working with specific hashes because both good and bad hashes change so often. If you have the time and manpower though go for it :) Also because I have rules covering most activity when malware is installed, under threat events for that machine I'll be able to see the chain of activity e.g. java exploit -> files dropped -> files executed -> registry key/services created. I'd advise against trying to do malware analysis with HIPS as well, just use Cuckoo.

    ReplyDelete
    Replies
    1. 2. It's more of a one off thing. Though MD5's, file names and reg keys change a lot, the actual data before and after an API call doesn't seem to change often. Enter target_bytes. Grab a known bad target bytes and see if it is being reported in your environment anywhere from any of the BO class rules events. You can figure out which ones those are in the dump (ctrl+f "bo:"), but they tend to have "illegal" in their rule name. More of an easy way to 100% identify known bad stuff.

      3. Though annoying, it is nice to get the actual data back if you have nothing else that can grab it now. You can use wildcards such as ? and * in them which may help. (same for target bytes btw. "??" a few pieces that tend to change depending on memory/jumps).

      Q1. Good point. The difference in API calls makes much more sense.

      4/Q2. Again, I was coming from the "I have known bad intel, so let's find it with HIPS" side. But now I'm convinced this isn't the way to go with this product. Having known bad bits and pieces really belongs in an AV product, especially since HIPs doesn't have true regex.

      Finally, I'd like to hear some of the use cases you've been using that have helped the most if you're willing to share. Moving towards "behavior" rules that need to be whitelisted instead of laser focused rules that try to look for a blacklist makes much more sense now.

      Delete
    2. Also, wow Ambush IPS. What is happening with this thing? It's making my mouth water. It looks like a truer HIPS system with MUCH more flexibility for what you can do with it. No walls like McAfee HIPS and other vendor's HIPS has.

      Are there any other tools that even compare to Ambush IPS?

      Delete
  3. Don't let me put you off incident response with HIPS. I've actually used it in the past to verify the scope of attacks by looking for known bad files and it worked well. I have found Powershell to be a better alternative though, see my other blog posts :)

    I've found it useful to:
    - Watch Java and it's program/file/registry activity.
    - Monitor registry persistence locations and changes to firewall etc.
    - Watch files dropping, programs executing or registry keys being created from C:\Users\&\AppData\*

    Although I've not used them the two main companies to watch are FireEye/Mandiant and Bit9/CarbonBlack. Both mergers now offer some really interesting stuff, at a price :)

    On paper Ambush does look awesome, although I'm not sure how easy configuration/deployment/management/performance/monitoring would be on an enterprise scale.

    ReplyDelete