Evilginx, meet BITB
Obligatory disclaimer that I did not come up with any of these techniques – I’m just combining two awesome ideas by other people.
If you’re not familiar with Evilginx or BITB, here’s a quick recap.
Evilginx, created by Kuba Gretzky, is a man-in-the-middle framework designed to facilitate the capture of credentials and session cookies. It does this by acting as a reverse proxy between a legitimate service and a client, intercepting the authentication traffic in transit. This behaviour is controlled by YAML files, known as “phishlets“.
This is an example of what the GitHub phishlet looks like.
The idea being that I would social engineer someone (somehow) into visiting this page and entering their credentials, at which time, Evilginx will capture them.
Understand that Evilginx is not just cloning the GitHub login page, it’s actually relaying the traffic between the victim’s browser and GitHub itself. Upon successful authentication, Evilginx will also capture the relevant session cookies that we can plug into our attacking browser in order to impersonate the active session. It’s very cool stuff and it works very well.
One “issue” (for lack of a better word), is that most people are going to notice that this GitHub login page is not on the github.com domain. Sure – there are ways to fool the user here, but I think we’re mostly past the days of leveraging lookalike domains etc… Let’s keep this in the back of our mind for now.
Browser In The Browser (BITB) is a phishing technique developed by mrd0x that attempts to challenge the assumption that the URL is a trustworthy entity. This is achieved by crafting an entire “pop-up window” in HTML, CSS and JavaScript.
The animation below is from the BITB repository.
The entire window, title bar, URL bar and SSL icon are fake, and the content is an iframe which can point to any source (that doesn’t protect itself from being placed in an iframe).
So, the idea I came up with was to use the BITB technique to present an Evilginx phishlet.
Evilginx already has the concept of “HTML templates”, which act as a sort of stepping stone to the actual phishlet itself. There is one example template included in the repo which serves up a fake download page. A template is set of a per-lure basis.
: lures create github
[19:35:41] [inf] created lure with ID: 0
: lures edit 0 template download_example.html
[19:36:29] [inf] template = 'download_example.html'Templates are also quite clever, as they can dynamically insert variables at runtime.
: lures get-url 0 from_name=rasta filename=cheese.png
[19:40:54] [inf] adding parameter: from_name='rasta'
[19:40:54] [inf] adding parameter: filename='cheese.png'
https://acmecorp.uk/login?Rp=4Ac8qdd3kKVLhTjXtK4I9-3EybBjK2G1enIunsGK6-RPAFNA-7Cmj7Tz
In this case, the user is sent to the phishlet URL when the download button is clicked. The phishlet URL can be utilised inside a template via two possible variable names: {lure_url_html} and {lure_url_js}.
lure_url_html provides a vanilla unquoted URL:
https://acmecorp.uk/qzJkEXhS?O=8UzPIrQWhereas lure_url_js provides an obfuscated and quoted URL:
'ht' + 't' + 'ps:' + '//' + 'ac' + 'me' + 'c' + 'o' + 'rp.' + 'u' + 'k/q' + 'z' + 'JkE' + 'X' + 'hS?' + 'O' + '=8' + 'U' + 'z' + 'PIr' + 'Q'All we have to do (famous last words) is create a template that looks like some sort of legitimate page, with a button that when pressed brings up the fake BITB window; and have the iframe source pointing to the phishlet URL.
Some things to note… Evilginx ignores any request that doesn’t match a lure. This means we can’t drop additional files such as .css, .js, or images into the templates directory and reference them in the template code. HTML is really quite flexible, so this isn’t a huge issue – we can use <style> & <script> tags, and embedded base64 encoded images instead.
You can also call external resources such as Bootstrap, directly from their CDN, if you’re comfortable doing so.
With my 1337 web dev skillz, I’ve knocked up a basic layout with a “Sign in with GitHub” button. This works well, because GitHub is a genuine OAuth provider, and you see these all over the Internet.
As mentioned, the source of the iframe is set to my lure URL.
<iframe id="content" src="{lure_url_html}" frameBorder="0"></iframe>When the button is clicked, the GitHub login phishlet appears.
As expected, when valid credentials are entered, Evilginx captures them along with the session cookies.
One flaw with this approach is when Evilginx redirects the user after successful authentication has taken place. This redirection is configured on the lure, and serves to send the user away from our phishing page once we’ve finished rinsing them. For example, if I wanted to send the user to Google, I would do:
: lures edit 0 redirect_url https://www.google.com/
[20:27:22] [inf] redirect_url = 'https://www.google.com/'The first problem is that Google doesn’t allow itself to be loaded into an iframe – it ends up looking like this:
Second – the title and URL of the fake window doesn’t reflect the new content.
Third – the actual behaviour we want would be more like the fake window closing itself, or at least a message to say something like “auth successful, you can now close this window.”.
This last option is relatively straight forward, as we can just host some HTML elsewhere and redirect there instead.
It’s my understanding that navigating the whole page away (not just inside the iframe) would require changes to Evilginx itself. If anybody fancied investigating that possibility, it would be a welcome contribution.
Hopefully this post was somewhat helpful. Huge shout-out to @mrgretzky and @mrd0x for their work on Evilginx and BITB. The full template code from this post will be available to my beloved Patrons.