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:

1. Clean state with Firefox Browser ON
2. After browser has been successfully hooked
3. After BeEF modules in action: credentials stolen
4. 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