Millions of readers who visited popular news websites have been targeted by a series of malicious ads redirecting to an exploit kit exploiting several Flash vulnerabilities. Since at least the beginning of October, users might have encountered ads promoting applications calling themselves “Browser Defence” and “Broxu” using banners similar to the ones below:

These advertisement banners were stored on a remote domain with the URL hxxps://browser-defence.com and hxxps://broxu.com.

Without requiring any user interaction, the initial script reports information about the victim’s machine to the attacker’s remote server. Based on server-side logic, the target is then served either a clean image or its almost imperceptibly modified malicious evil twin.

The malicious version of the graphic has a script encoded in its alpha channel, which defines the transparency of each pixel. Since the modification is minor, the final picture’s color tone is only slightly different to that of the clean version:

Using the known Internet Explorer vulnerability CVE-2016-0162, the encoded script attempts to verify that it is not being run in a monitored environment such as a malware analyst’s machine.

”If the script does not detect any signs of monitoring, it redirects to the Stegano exploit kit’s landing page, via the TinyURL service. The landing page loads a Flash file that is able to exploit three different vulnerabilities (CVE-2015-8651, CVE-2016-1019, CVE-2016-4117), depending on the version of Flash found on the victim’s system.

Upon successful exploitation, the executed shell code collects information on installed security products and performs – as paranoid as the cybercriminals behind this attack – yet another check to verify that it is not being monitored. If results are favorable, it will attempt to download the encrypted payload from the same server again, disguised as a gif image.

The payload is then decrypted and launched via regsvr32.exe or rundll32.exe. Payloads detected so far include backdoors, banking trojans, spyware, file stealers and various trojan downloaders.

Technical analysis of the Stegano exploit kit

An earlier variant of this stealthy exploit pack has been hiding in plain sight since at least late 2014, when we spotted it targeting Dutch customers. In spring 2015 the attackers focused on the Czech Republic and now they have shifted their focus onto Canada, Britain, Australia, Spain and Italy.

In the earlier campaigns, in an effort to masquerade as an advertisement, the exploit kit was using domain names starting with “ads*.” and URI names containing watch.flv, media.flv, delivery.flv, player.flv, or mediaplayer.flv.

In the current campaign, they have improved their tactics significantly. It appears that the exploit pack’s targeting of specific countries is a result of the advertising networks the attackers were able to abuse.

We can say that even some of the other major exploit kits, like Angler and Neutrino, are outclassed by the Stegano kit in terms of referrals – ‘the websites onto which they managed to get the malicious banners installed. We have observed major domains, including news websites visited by millions of people every day, acting as “referrers” hosting these advertisements.

Upon hitting the advertising slot, the browser will display an ordinary-looking banner to the observer. There is, however, a lot more to it than advertising.

The steganography advertisement

In the vast majority of the cases, the advertisement was promoting a product called “Browser Defence” and it has been only recently when we started to detect banners promoting the software “Broxu”. However, for the sake of simplicity, and since the campaigns are practically identical (apart from the banner and its hosting domain, of course), only the “Browser Defence” campaign is analyzed below.

The advertisement was located at the browser-defence.com domain with a URI structure similar to the following (note the https):

hxxps://browser-defence.com/ads/s/index.html?w=160&h=600

The index.html loads countly.min.js and feeds the initial parameters to the script. This countly, however, is not the stock library of the open source mobile & web analytics platform you would download from github. It is a heavily modified and obfuscated version, with some parts deleted and interlaced with custom code. This custom code is responsible for an initial environment check. Information about the environment is reported back to the server as XOR-encrypted parameters of the 1x1gif file, as captured in the image above.

The following information about the environment is sent:

systemLocale^screenResolution^GMT offset^Date^userAgent^pixelRatio

After that, the script will request the advertising banner. The server will reply with either a clean or a malicious version, most likely also depending on the previous environment check.

The script will then attempt to load the banner and read the RGBA structure. If a malicious version of the image was received, it will decode some Javascript and variables from the alpha channel

The steganography is implemented in the following way: Two consecutive alpha values represent the tens and ones of a character code, encoded as a difference from 255 (the full alpha). Moreover, in order to make the change more difficult to spot by naked eye, the difference is minimized using an offset of 32.

For instance, if the first few alpha bytes contained the values 239, 253, 237, 243, 239, 237, 241, 239, 237, 245, 239, 247, 239, 235, 239 and 237, they would decode to the word “function”. In this example, the first two alpha values 239, 253 would give us an ‘f’:

A closer look at one of the clean banners and one with the Stegano code shows only a subtle difference.

The alpha channel of the unused pixels is filled with some pseudorandom values, in order to make the “alpha noise” evenly distributed and thus more difficult to spot.

After successful extraction, the JS code integrity is checked against a hash encoded at the end of the picture, then executed.

Next, the new script attempts to check the browser and computer environment further using a known Internet Explorer vulnerability, CVE-2016-0162. In particular, it is it is focused on checking for the presence of packet capture, sandboxing, and virtualization software, as well as various security products. Also, it checks for various graphics and security drivers to verify whether it is running on a real machine. More details can be found Appendix 1.

If no indication of monitoring is detected, it creates an iframe (just one pixel in size) at coordinates off the screen, sets its window.name property (this name will be used later) and redirects to TinyURL via https. TinyURL then redirects to an exploit landing page via http. The referrer to the original site is lost during this process.

The exploit

After successful redirection, the landing page checks the userAgent looking for Internet Explorer, loads a Flash file, and sets the FlashVars parameters via an encrypted JSON file. The landing page also serves as a middleman for the Flash and the server via ExternalInterface and provides basic encryption and decryption functions.

The Flash file has another Flash file embedded inside and, similarly to the Neutrino exploit kit, it comes with three different exploits based on the Flash version.

The second stage Flash file decrypts the FlashVars. It contains a JSON file with URI for error reporting, JS function names for ExternalInterface, the callback function name and some unused data:

{“a”:”\/e.gif?ts=1743526585&r=10&data=”,”b”:”dUt”,”c”:”hML”,”d”:true,”x”:”\/x.gif?ts=1743526585&r=70&data=”}

Subsequently, it invokes a JS via ExtelnalInterface.call() that checks for the Flash version and communicates this to the server via the landing page. This is done through an encrypted URI parameter of a request for a GIF file. The encryption’s algorithm is simple, and uses the window.name from the advertisement:

The response is a GIF image of which the first bytes are discarded and the rest is decrypted using the same algorithm and then passed back to Flash.

The response is a JSON containing a letter denoting which exploit to use (CVE-2015-8651, CVE-2016-1019 or CVE-2016-4117), a password for the corresponding exploit and a shell code ready with the URI for the payload.

The shell code

The shell code is decrypted into its final stage during the exploitation phase. It will attempt to download an encrypted payload, again disguised as a GIF image. First, however, it performs yet another check for signs that could suggest it is being analyzed.

It is particularly interested in presence software containing the following strings in their filenames:

• vmtoolsd.exe

• VBoxService.exe

• prl_tools_service.exe

• VBoxHook.dll

• SBIEDLL.DLL

• fiddler.exe

• charles.exe

• wireshark.exe

• proxifier.exe

• procexp.exe

• ollydbg.exe

• windbg.exe

• eset*, kasper*, avast*, alwil*, panda*, nano a*, bitdef*, bullgu*, arcabi*, f-secu*, g data*, escan*, trustp*, avg*, sophos*, trend m*, mcafee*, lavaso*, immune*, clamav*, emsiso*, superanti*, avira*, vba32*, sunbel*, gfi so*, vipre*, microsoft sec*, microsoft ant*, norman*, ikarus*, fortin*, filsec*, k7 com*, ahnlab*, malwareby*, comodo*, symant*, norton*, agnitu*, drweb*, 360*, quick h

If it detects anything suspicious, it will not attempt to download the payload.

The payload

If the payload is received, the first 42 bytes of the GIF are discarded; the rest is decrypted and saved to a file using one of the following methods:

1. CreateFile, WriteFile
2. CreateUrlCacheEntryA(*” https://google.com/”,,,,), CreateFileA, CreateFileMappingA, MapViewOfFile, {loop of moving bytes}, FlushViewOfFile, UnmapViewOfFile

The payload is then launched via regsvr32.exe or rundll32.exe.

During our research, we have seen the following payloads being downloaded by the Stegano exploit kit:

Win32/TrojanDownloader.Agent.CFH

Win32/TrojanDownloader.Dagozill.B

Win32/GenKryptik.KUM

Win32/Kryptik.DLIF

After a detailed analysis of the Downloaders and Kryptiks (the latter are ESET’s detections of extensively obfuscated variants), we found out that they either contained or were downloading Ursnifand Ramnit malware.

Ursnif has a multitude of modules for stealing email credentials, has a backdoor, keylogger, screenshot maker, and video maker, is injecting into IE/FF/Chrome and modifying http traffic, and can steal any file from the victim computer. According to the configuration files found in the analyzed samples, they seem to be targeting the corporate sector, focusing on payment services and institutions.

Ramnit is a file infector that has been targeting the banking sector as well, utilizing its many capabilities, such as information exfiltration, screenshot capture, file execution, etc.

Conclusion

The Stegano exploit kit has been trying to fly under the radar since at least 2014. Its authors have put quite some effort into implementing several techniques to achieve self-concealment. In one of the most recent campaigns we detected, which we traced back at least to the beginning of October 2016, they had been distributing the kit through advertisement banners using steganography and performing several checks to confirm that they were not being monitored.

Source:https://www.welivesecurity.com/