Attack of the Zombie Eels

Recently our team discovered two very interesting tools published on GitHub by security researchers Michele Orrù and Giuseppe Trotta.

Muraena is an almost transparent reverse proxy capable of proxying the victim through to the legitimate target website while harvesting credentials and cookies, and in most cases allowing 2FA flows to complete.



Necrobrowser is an API-driven zombie browser running in a docker container used to persist authentication and to automate post-phishing actions, such as downloading data, taking screenshots or – as you will see later in this article – silently backdooring the account.(source)


Both tools work hand-in-hand to create a phishing chain that would make the most battle-hardened CISO shudder: live content cloning (due to the proxy), so no more updating outdated static phishing kits, combined with automated post-phishing exploitation capable of performing pretty much any action a user could do manually in the browser. However, it is worth mentioning that both tools are in their infancy, so configuration is difficult and requires knowledge of how the target site handles authentication, as well as the ability to code in GoLang in order to write custom Necrobrowser automation tasks. Due to the technical barrier of configuring these tools past the included sample configurations, we do not predict that we will see widespread malicious use just yet.

Basic Credential Harvesting

First, we are going to look at conducting basic phishing with Muraena in order to steal Google account credentials. In our lab we have a DNS server configured to send all requests to any .phish TLD to our attacker’s server in order to emulate a real attacker hosting Muraena on their own server, and to illustrate how the tool is dynamically re-writing asset URLs to build the page and maintain functionality. Our victim machine is configured to use this DNS server and has a fake root CA certificate installed to emulate the attacker using a legitimate SSL certificate; in the wild it is likely that LetsEncrypt would be used.

Muraena comes with a basic config for phishing Google accounts, which we will use here with very little modification. It is worth noting that the current flow does trigger some kind of account protection at Google, so even though we can successfully capture the username and password in plaintext, the session is not created so we cannot steal it and send it to Necrobrowser; however, we are sure that with a little more time and effort, this can be fixed.

Muraena is ready to go

Muraena is running on our attacker’s machine and waiting to proxy our victim.

A normal looking Google homepage

Our victim sees a normal looking Google homepage with a “valid” SSL certificate. Of course, https://google.phish does not really exist and this is in fact Muraena proxying the real Google homepage.

Normal Google account login page

Our victim clicks on the sign in button to log into their Google account; again this is the real Google sign in page being passed through the proxy so our attacker can see everything that is being input.

Captured credentials

Our victim enters their credentials and completes the login flow. Our attacker receives the captured credentials as soon as they are sent through the proxy – in plaintext.

Unleashing the Zombie

GitHub login page

Now we are going to look at a much more robust chain. In this example our attacker will successfully capture the victim’s GitHub credentials, allow 2FA to proceed and then send the session cookies to Necrobrowser. Using a headless Chrome browser, Necrobrowser will then automatically disable email notifications for the account to prevent an email being sent on account changes, and then upload our attacker’s SSH key to allow access to the victim’s private repositories.

Again, our victim is presented with a proxied version of the legitimate GitHub website, the only difference being the https://github.phish domain

This time we added SMS 2FA to the account as an extra layer of protection (Google authenticator et al would also work in the same way here). As the attacker is proxying to the legitimate GitHub website, the authentication flow works as usual and logs the victim in.

Muraena steals the cookies
Necrobrowser starts a zombie browser

The session cookies are captured and sent to Necrobrowser, which immediately fires up a headless Chrome browser using the passed cookies, and is instructed to do evil.

Notifications disabled
Backdoor SSH key

In the case of our victim, all account notifications have been disabled and a backdoor SSH key has been added to the account, allowing the attacker to clone all the private repositories or commit code to existing repositories.


The tools are still in their infancy and mainstream adoption will probably not be seen yet, though we have heard from the developers that updates will be coming by the end of this year.

In their current form, with the included configurations, the attacks described above are certainly possible with only a little effort to get everything working. With a little more time and technical skill, the tools can be configured to target almost any kind of website such as:

  • Online banking – automatically harvest personal details, download statements or maybe even make transactions
  • Email services – automatically add a forwarding address, download emails, send emails to all contacts
  • In-house web services – automatically perform self-service password resets for corporate web services
  • Social media – automatically add friends on social media, message friends or post content

Due to the automation being a headless browser driven by code rather than attempting to utilise per service APIs, the possibilities are almost endless, as you can automate pretty much anything a user can do in the browser with an authenticated session.

Another important point to note is that unlike common static phishing pages which always end with a dummy error message or a redirect, the user is actually logged in to the target website and can continue to go about their business, enabling the attacker to capture more information through the proxy as the victim uses the website.

As mentioned before, while we think that malicious use of these tools in their current form will be quite low right now, it is certainly worth keeping an eye on this development and ensuring your users are aware of potential problems.

Scroll to Top