Cisco Blogs

Bad Browser Plug-ins Gone Wild: Malvertising, Data Exfiltration, and Malware, Oh my!

- February 12, 2015 - 9 Comments

This post was authored by Fred ConcklinWilliam Largent,  Martin Rehak,  Michal Svoboda, and Veronica Valeros.

During an average day of surfing the web via computer, smartphones, and tablets, we are constantly deluged by advertising. Total annual Internet advertising revenue will approach $200bn by the year 2018, making it an extremely lucrative business and in turn an attractive attack vector known as malvertising.

Malvertising and More via Browser Add-ons

Last year, Cisco’s Cognitive Threat Analytics CTA by means of automated behavioral analysis of web telemetry, uncovered a new threat, which our researchers have found to be a family of malicious browser add-ons. Once installed, they inject unwanted advertisements on certain pages that the user visits. This provides revenue to the miscreants and at the same time opens a channel to deliver further malware, track and exfiltrate end user data.




This particular threat chooses a very unobtrusive way of injecting ads, it installs itself as a browser add-on. This family of add-ons have some common behaviors that were tracked across various installs and had multiple trajectories. Cisco researchers uncovered over 4000 different names for these bundled add-ons. Once installed, the plugin monitors a user’s browsing session, exfiltrates visited URLs using a distinct communication mechanism and injects advertisements into visited pages. To the user, it appears as if that advertisement is a natural part of the page.


Excerpt of add-on names extracted from decoded URL strings:




Identified HTTP Behavior and IOCs

Cisco researchers analyzed one year of network traffic related to this family of add-ons and identified that the HTTP traffic from these families share some unique characteristics. These common formats in the HTTP traffic can be seen in the patterns below:



In all the cases, the information sent through the URL is obfuscated by hiding a base64 string between additional characters, or by using a custom encoding function. Once decoded, the strings show all type of information being sent over the network on each request,  illustrated on the graphic below. There are a few interesting fields that are of particular interest: ‘addonname’, ‘reto’, and ‘href’. The first field, ‘addonname’, is self-explanatory; it makes reference to the name of the add-on generating the request. The second,’ reto’, contains a URL to which the end user will be redirected. The third, ‘href’, contains the page visited previously by the user, which may include also include internal resources of the company (intranet domains, internal paths, and even corporate user identities such as usernames or email addresses).




Domains using DGA based on words

Cisco researchers compiled a list of 570 unique domains used from January through November 2014. These domains appear to be created using a domain generation algorithm (DGA) based on common dictionary words. These domains are likely registered using a domain service via application programming interface (API) tools so that they can be scripted and automatically registered. Malicious actors will often load their domain registration scripts with random words from a custom made dictionary. The resulting domains registered as a result of this scripted process often emerge as a nonsensical combination of words.



Breaking down the obfuscated request and redirection chain

Once installed, the add-on injects a frame on the pages visited by the user with a URL. The URL injected, which follows one of the patterns already mentioned, will load the advertising that the user will finally see. The add-on will fingerprint the operating system of the user and display different advertisements depending on the operating system, be it Windows, Linux or OSX. The malicious actors can generally assess the vulnerability of the affected user and their operating system and may attempt to deliver malware specific to the given environment.

Cisco security researchers have seen that the behavior triggered by the initial request is changing: it can be followed by one or more redirections or lead to additional JavaScript code.

Below is an example of a series of requests seen in a compromised user. The initial request is Immediately after the HTTP request performed by the add-on is generated. The sequence continues for the user, as it normally would, loading the requested page, in this case, and all it’s resources. Additionally the user will be seeing an advertisement that wouldn’t usually see on this page, due the presence of the browser add-on.



Browser plugin analysis

To verify the suspected behavior we analyzed the plugin, MediaBuzz, which was packaged in a NullSoft installer (9a03872db0331a29732a243e1451ec2acb1915f00ba92f067aca05fbfaa7aef8).




The plugin invokes a DLL (aminsis.dll). This library appears to check for virtualization and emulation as you can see in the image below.




In cases where all the checks performed are successful, the NullSoft installer script installs the browser extensions silently and in the case of Chrome manually whitelists them. This manual whitelisting is used to overcome Chrome’s inherent trust relationship with third-party extensions. Chrome extension installations are only allowed from the official Chrome repository and not from third-party websites. Which makes it more difficult for attackers to distribute malicious extensions. Add-ons in Firefox, by comparison, are trusted by design and can be installed from third-party sources. Chrome extension APIs are very constrained, because the Chrome browser does not fully trust extensions, these extensions can typically not access any resources outside Chrome’s sandbox without the user’s approval.




The plugin code, when run from an initial page, will inject multiple browser ads into specific portions of the DOM. From the user perspective, the displayed page will slightly change as shown below:




The injected ads will change and vary according to the browser and operating system the user is browsing from. In many cases they lead to pages to download malicious software. You can see that the injected ad for a Windows user contains a link to the malicious “PC Repair” while the Linux user receives and ad for internet gaming.






Identifying and blocking adware, malware, and exfiltration of data requires a multi-tiered security approach. The exponential growth of advertising, and hence adware, only makes these tiered security practices all the more important. With the global Internet ad revenue rapidly approaching an estimated $200B, attackers are following the money and adapting their techniques.  Defenses have to be just as agile as the attackers.  By investing in new detection methodologies, such as Cisco’s Cognitive Threat Analytics (CTA), users will be able to identify new actors and new techniques, reducing time to detection in their environments.

Protecting Users Against These Threats

coverage_chart-amp-cws-wsaAdvanced Malware Protection (AMP) is well suited to detect and block this type of attack.

CWS or WSA web scanning will prevent access to malicious websites and detect the malware used in this attack.







In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


    Did you see malvertising campaigns using TLS encryption (HTTPS)?

      Unlikely as this would add one more layer of security to break. The browser would then have to trust the certificate offered by the malware host; this would not be cost-effective for the bad guys. Fewer security measures would trigger by keeping the exfiltration via HTTP.

      Hello Daniel, yes, https has been observed at least in two cases: 1) Small portion of the total communication with the word-based DGA domains is over https. 2) In some cases, scripts that are part of the "redirection chain" are served by CDNs, and that can happen over https as well.

  1. It seems conspicuous that no mention of username+password theft (and/or credit-cards) appears: surely anyone with access to inject code into web pages would almost always steal that stuff? Is it doing so? If not - that's really bizarre - any idea *why* not ?

      A question worth asking but I don't think it lines up with this threat. If my goal were to obtain credit card information, for example, I would hide my presence as much as possible and will avoid injecting malvertising. Considering Daniel's point, we would also have to decrypt the secure connection for this type of information.

    • Why Not? Seriously? These extensions aren't ILLEGAL. That would instantly make them ILLEGAL. This isn't even really malware. Alot of these programs have a legitimate use and are just funded with advertising.

    Critical resources: Mozilla Plug-in checker Google software removal tool

  2. Plus credit card fraud would instantly call down the feds. Right now they just have bored security researchers writing about them.

  3. That's another Flash security issue.