SIEM is not a product, its a process...
This famous Bruce’s quote is so true that we can re-use it to focus on specific topics like SIEM (“Security Information and Event Management”). Many organizations already deployed solutions to process their logs and to generate (useful - I hope) alerts. The market is full of solutions that can perform more or less a good job. But the ROI of your tool will be directly related to the processes that you implement next to the hardware and software components. I’ll give you two examples.
The first one is the implementation of a mandatory strong change management procedure. Recently, I faced this story at a customer. I call this the “green status” effect: If the security monitoring tool does not report alerts and and you assume that everything seems running fine, you'll fail! Because your SIEM quality is directly depending on the quality of the data send to it. Within the customer infrastructure, some critical devices were moved to a new VLAN (new IP addresses assigned to them) but the configuration of the collector was not changed to reflect this important change. Events being sent to a rsyslog instance and split based on the source IP address, the new events were not properly collected. They lost many alerts!
The second example focus on assets management. Many SIEM vendors propose compliancy packages (PCI, HIPAAS, SOX - name your favorite one). The marketing message behind those packages is “be compliant out of the box”. Really? Have a look at the following correlation rule extracted from a PCI compliancy package from a well-known SIEM solution (translated in human readable format):
if the target is not :
known as a regular destination from the DMZ
OR known as a trusted target
OR known as a “cardholder” target
AND IF the destination port is not known as allowed (via an Active List)
AND IF the traffic is not coming from a VPN device
AND IF the traffic is not coming from a SIEM device
AND IF the source is flagged as an attacker from the DMZ
Based on this rule, we must:
- Define trusted hosts
- Define “cardholder” hosts
- Define the list of allowed ports
- Categorize the VPN, SIEM devices
This means that to make this rule effective, there is a huge classification job to perform to fill the SIEM with relevant data (again!). Deploying a SIEM is not just a one shot process. You’ve to carefully implement procedures!
- New devices must be provisioned in the SIEM configuration
- Changes must be reflected in the SIEM configuration.
- Implement controls to detect unusual behavior (waiting for alerts is not enough)
Happy logging!
Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key
When Hunting BeEF, Yara rules.
This is a Guest Diary submitted by Pasquale Stirparo.
Phishing emails represent a big security issue, especially in corporate environments where an extra double click by an inattentive user may be fatal, opening the doors to compromise the entire company’s network. This has also been confirmed in a study conducted by SANS stating that “95% of enterprise data breaches start with a spear phishing attack”. I decided to take a deeper look at phishing from the point of view of incident response, particularly at any forensic artifacts left behind by an attack that uses BeEF.
BeEF, The Browser Exploitation Framework, is a penetration-testing tool focusing on web browsers. You can think of it as the Metasploit for web browsers security testing. In fact, it offers several modules that may allow the attacker to, for example, steal web login credentials, switch on microphone and camera, etc. Very briefly, what BeEF does is hooking the browser via a javascript placed inside a normal HTML page, which then exposes RESTful API that allows BeEF to be scripted through HTTP/JSON requests. The interesting aspect is that all of this is running inside the browser, hence leaving the chances of finding file system artifacts very low.
Attack Scenario
To go ahead with the tests, I built up a standard attack scenario like the following:
1. The user receives an email with a link to a “legit” but infected website.
2. Once clicked, the browser is hooked (it will appear in the console panel) and BeEF extract a complete fingerprint of it
3. A fake Facebook logout alert is prompted to steal credentials via the “Pretty Theft” module
4. An invisible iframe is created, overlapping the current page, which opens a connection to a server where Metasploit is listening
5. Once connected, Metasploit delivers a meterpreter by exploiting a recent Flash vulnerability
Analysis Methodology and Initial Results
The idea is trying to understand what traces are left by BeEF at each different stage of the attack. To do this, I thought about four different states to be checked:
- Clean state with Firefox Browser ON
- After browser has been successfully hooked
- After BeEF modules in action: credentials stolen
- After exploitation with BeEF+Metasploit
For all of them, memory and disk dumps have been taken, plus registry and file system changes monitored (regshot + PowerShell script).
The initial analysis (the project is still in the early phase) on the disk dump found artifacts only on the browser cache (as we would expect):
C:\Users\p4c0\AppData\Local\Mozilla\Firefox\Profiles \w3nf5opu.default\cache2\entries\
and BeEF appears to be quite stealthy:
- No files dropped
- No new processes spawned (only Metasploit Flash exploit did it)
However, BeEF code is retrievable from the memory within the browser process
$ python vol.py -f beefed.dmp --profile=Win7SP0x86 pslist
$ python vol.py –f beefed.dmp --profile=Win7SP0x86 memdump –p 4040 –D
dest_dir
$ strings dest_dir/4040.dmp > strings_ff_beefed.txt
So I decided to try hunting it with Yara. I created one Yara rule “manually” and generated two other rules with yarGen starting from the main BeEF module, and all of them worked correctly. At this point, I got curious and tried to generate a rule for the specific “Pretty Theft” module used to steal user’s Facebook credentials and guess what, it worked too. This means that an analyst can identify that BeEF was used, and even which specific module.
As next steps for this project, I am working on full Windows coverage (including Hiberfil.sys, pagefile, registry, and timeline) Mac OS X and Mobile, and I am looking into further expanding the Yara signatures and coverage.
In my next diary, I'm going to show how the rules work in practice.
This work has been presented at the last SANS DFIR EU Summit 2015 in Prague. You can find the slides online if interested.
Happy Hunting.
Pasquale
Comments