Exploiting Chrome Attacks to Educate Staff

Social engineering attacks can normally be quite deceptive and hard to understand, the attack should be a little like magic in the way a victim should be left questioning how you did it after it’s all over. Although as an industry we try our best to relay usable advice to the vulnerable, to prevent the worst kind of magic from happening! – we can sometimes struggle to do this effectively. It’s all nice and simple when it comes to “don’t click the link” and “check the sender matches your contacts” but when was the last time you heard an IT manager address the workforce with:

We need to be on the lookout today for .CRX files being distributed via social media.

Every week we hear of some new avenue of attack, whether it’s the kettle sharing your Wi-Fi password, your Bluetooth enabled tyre monitoring system being used to track you or accidentally giving a Google script access to your Google account. We try to incorporate some of these relevant scenarios into our phishing assessments in the hope we can educate the end users within a company, but every now and again we see an attack that is so sneaky, so devious, that it must become part of a realistic phishing assessment – for those of you that don’t know, that is what we call our realistic phishing simulations.


One such attack worthy of the inclusion is one that relies on a user installing a malicious Chrome Extension that takes every POST request the Chrome browser makes after the extension’s installation and sends all that data to a receiver in our control. After a mark has installed the extension it sits silently, forwarding login details from banks, online accounts and most websites. If you were tricked into installing such a thing and your organisation’s security implementations of Chrome wasn’t up to scratch, you would have a really bad day. Let’s dig a little deeper and explain the attack!



How The Attack is Formed

We first saw this specific example (many variations proceeded it) on GitHub. The simple code was a PoC to a larger issue reported to Google. Some issues were fixed, but it largely remains exploitable. In true social engineering fashion, it’s a case of exploiting this little gap in security for maximum effect. We take the code:

The malicious chrome extension's code.

and we change a few details, the above code basically says hey listen out for all forms and when somebody submits a form send it to a publically accessible post request site. So in essence, if you installed this plugin ‘as is’ it would send your banking details off to the world… We can’t have that kind of stuff happening mid social engineering exercise so we begin to fork this and customise it to work with a third party service that will treat the marks confidential data securely.

Next, you have to register a developer account with Google Chrome Store and get the manifest files and the rest of the extension from their current state on GitHub to a fully legit working Chrome Extension in the store.

This just leaves delivery… luckily for us this is where we would excel, the most likely scenario would be ‘an important security update’ phishing email from a senior employee, or an ‘Important security update from Google’ the only defence a Chrome user has to this kind of scenario is a small, pretty nondescript pop up after clicking our link that warns the user and then for the rest of the journey they only see, well lets see if you can spot the malicious extension:

In case you were wondering, it’s the Google Drive icon…

The end result of all this trickery is we get the marks browser’s POST data, In this example, I was logging into next.co.uk and it passed on my fake email & password.

Example post request


Defence and Education

Commercially, this problem can be mitigated easily using the Chrome Security features in the Google Apps package. If your organisation is enrolled in Google Apps, you can limit what Chrome can do when a user is logged in – to read more about this view the help page. This is a total technical protection measure if you are running Chrome OS for your staff and yet another reason why doing so isn’t a bad choice! When you don’t have organisational control of Chrome you are going to mainly be relying on users to do the right thing.

With Chrome being the most common web browser at a whopping 76%, the chances are employees have already installed a few extensions. We have seen the impact that can cause before with issues again with providing privilege.  But this can be a horrendously bad security choice. The problem is this attack vector is missing from most staff educational programs and the end users remain uneducated to the risks. We are all guilty of clicking accept without reading the full terms and conditions but many have no understanding this one check box will see their most private details being shipped off to a stranger. More has to be done to take staff education away from the basics of 1999 web browsing and introduce learning that covers realistic threats people are likely to face. We will be incorporating this attack in training and red-teaming, using a hosted app and we hope to demonstrate it’s effectiveness in a safe environment.


The most important points to note:

  • Never install a browser extension without checking the author and permissions of the extension.
  • Never install an ‘update’ or ‘plugin’ when requested too in an email.
  • Do not trust an email sender – they can be easily spoofed.
  • Try and gain control of a users Chrome browser so security profiles can be pushed to devices.
  • Do not trust what an icon looks like or the name of an extension, they copy legitimate names.
  • Test you organisations defence in scenarios like this.
  • Don’t always trust what an extension does based on the information provided – author credibility is everything.
  • If you see the picture below in a simulation, or you encounter one like it – be careful!