Latest Diaries

I detected the following suspicious traffic on a corporate network. It was based on multiples infection stages and looked interesting enough to publish a diary about it. This is also a good reminder that, just by surfing the web, you can spot malicious scripts that will try to infect your computer (Exploit Kits).

It started with a succession of HTTP redirects across multiple domains, all using the .xyz TLD.

You can see that the servers are hosted behind Cloudflare. All domains are registered via the same registrar (NameCheap). If you visit manually the first URL, it redirects you to Google. I did not find what triggers the redirect: the language (es-ES), the user-agent? GeoIP? When I analyzed the websites visited by the victim, I'm not 100% confident about the website infected with the malicious URL (there was also a lack of HTTP Referer) but it looks to be openload[.]co, a file-sharing platform.

The script delivered by the last visited URL is written in VBScript. That’s why a first test is performed to ensure that it has been delivered to a proper target:

<script>
if (window.ActiveXObject || "ActiveXObject" in window){
...

The code is not complex to deobfuscate. It is just escaped:

Multiple infection stages are present. You can see a link to a malicious Flash file ("1.swf") (SHA256:498496827afc0aa5960d1cb1d60f7ae7699e0906e3a8c657b6864cff10772df0) with a VT score of 7/55[1]. This is a classic infection method for many exploit kits.

This script creates a MUTEX ('Global\ifqGpTzdTzhMJSOz’) and checks if it is being run with administrator privileges. If yes, it downloads and executes another payload (hxxp://jeitacave[.]org/4U22nOJHFdDmYcgCS.jpg). It’s a MSI file (SHA256:33d3568638a62c695823ef00bb0e4d5a717e86870457f6d7ab044eea4a455314) unknown on VT.

Once executed, the MSI package is installed via msiexec.exe and performs interesting actions: It disables WindowsDefender and alters the local firewall by allowing many incoming connections to well-known ports:

For a few days, huge debates have started on forums and mailing lists regarding the announce of Mozilla to enable DoH (DNS over HTTPS[1]) by default in its Firefox browser. Since this announcement, Google also scheduled a move to this technology with the upcoming Chrome releases (this has been covered in today’s podcast episode). My goal is not here to start a new debate. DoH has definitively good points regarding privacy but the problem is always the way it is implemented. In corporate environments, security teams will for sure try to avoid the use of DoH for logging reasons (DNS logs are a gold mine in incident management and forensics).

Amongst the classic reconfiguration of the browser, Firefox implemented a technique to detect if DoH can or can't be used: by querying a specific domain: “use-application-dns.net”. Firefox will generate ‘A’ and ‘AAAA’ requests to this domain (using the DNS servers provided by the OS) and if ’NXDOMAIN’ is returned, it won’t use DoH.

This morning, a DNS request to resolve this domain returned the following data on my network:

Now, let’s see how to configure a Bind resolver (which is a well-know DNS server) to return ’NXDOMAIN’ when this domain is attempted to be resolved. The idea is to use RPZ (Response Policy Zones)[2]. I already covered this technique in a previous diary[3]. Here is a simple config for Bind:

Step 1, create a small zone file that will contain the domain we don’t want to resolve: