I would like to cover today two different malware samples I spotted two days ago. They have one interesting behaviour in common: they compile their next stage on the fly directly on the victim's computer. At a first point, it seems weird but, after all, it’s an interesting approach to bypass low-level detection mechanisms that look for PE files.

By reading this, many people will argue: “That's fine, but I don’t have development tools to compile some source code on my Windows system”. Indeed but Microsoft is providing tons of useful tools that can be used outside their original context. Think about tools like certutil.exe[1] or bitsadmin.exe[2]. I already wrote diaries about them. The new tools that I found “misused” in malware samples are: "jsc.exe" and "msbuild.exe". They are chances that you’ve them installed on your computer because they are part of the Microsoft .Net runtime environment[3]. This package is installed on 99.99% of the Windows systems, otherwise, many applications will simply not run. By curiosity, I checked on different corporate environments running hardened endpoints and both tools were always available.

jsc.exe is a JScript Compiler:

msbuild.exe is a tool to automatically build applications. Since the version 2013, it is bundled with Visual Studio but a version remains available in the .Net framework:

Both are located in C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx\ (check the version installed on your computer).

Let's have a look how they are (ab)used. The first sample is a JScript script (SHA256:e5d58197b5d4465fe778bae8a63c5ab721a8c15b0f3c5e2aa6d20cbad3473b3e) with a VT score of 13/58[4]. It is not obfuscated at all (if it was the detection score could be much lower) and does the following actions:

It moves and resizes the current window to make it invisible then it decodes a chunk of Base64 encoded data. It searches for an existing .Net runtime environment and builds the absolute path to jsc.exe:

The extracted file (LZJaMa.js) is another JScript that contains another Base64-encoded chunk of data. It is decoded and injected in the current process via VirtualAlloc() & CreateThreat() then executed:

The injected malicious payload is a Meterpreter (SHA256:6f5bdd852ded30e9ac5a4d3d2c82a341d4ebd0fac5b50bb63feb1a7b31d7be27)[5].

The second sample uses msbuild.exe. It's an Excel sheet (SHA256:452722bf48499e772731e20d255ba2e634bba88347abcfb70a3b4ca4acaaa53d)[6] with a VBA macro. Classic behaviour: the victim is asked to authorize the macro execution. In this case, the payload is again Base64-encoded but it is stored directly in some cells that are read and their content concatenated:

Note that in this case, the macro does not try to find a valid .Net runtime, the version is hardcoded. Targeted attack?

Tools like 'jsc.exe' and 'msbuild.exe' are good IoC's because they aren't used by regular users. Execution of such processes is easy to spot with tools like Sysmon or, better, prevent their execution with AppLocker. Especially if they are executed from Excel, Word, Powershell, etc.

[This is a guest diary submitted by Jan Kopriva. Jan is working for Alef Nula (http://www.alef.com) and you can follow him on Twitter at @jk0pr]

Open (or unvalidated) redirects[1] are a family of web application vulnerabilities caused by missing or insufficient validation of input used to specify URL to which a browser is to be redirected. Although, from a technical standpoint, their principles are quite simple and they are usually nowhere near as dangerous as XSS or SQLi vulnerabilities, under specific circumstances they can pose severe risks. This is well illustrated by the fact that “Unvalidated Redirects and Forwards” were part of the OWASP Top 10 List in its 2013 iteration.

Pages, which redirect visiting browsers to different URLs based on an input passed to them, have a legitimate use in web applications. Historically, they have often been used for marketing purposes (monitoring clickthroughs in e-mail campaigns and on websites) or for returning a browser to the same page, it was on before user logged into an application. LinkedIn, for example, makes use of this technique if you try to log in while viewing someone’s profile. In such a case, the page, to which your browser will be redirected after you log in, is specified by the value of session_redirect parameter.

As you may see, redirection mechanisms can be quite useful. A problem arises, however, when these mechanisms lack any limits on the URLs to which they may redirect a browser (i.e. the redirect is “open”). For marketing loggers, redirection to any domain passed to them might be an intentional feature. On the other hand, if an open redirect is present on the website of a bank or a similar trusted business it can be quite dangerous.

Imagine if a website of a bank used the URL https://www.bank.tld/redirect?to=https://ebanking.bank.tld to redirect users to its e-banking portal. If the redirect was “open”, a threat actor could craft a link which would point to the legitimate site of the bank, but – when accessed – would redirect the browser to a fraudulent website. (e.g. https://www.bank.tld/redirect?to=https://ebanking.fakebank.tld). A phishing campaign utilizing such a link could be quite successful. That is the main reason why a redirect mechanism should – at least in most cases – include a whitelist of permissible target domains (or another relevant filtering mechanism) and redirect only to those sites, which are considered safe.

Unfortunately, as we found out during recent research into open redirect vulnerabilities, even though they are usually easy to find and fix (and it isn’t difficult to avoid introducing them into an application in the first place), they are quite prevalent on the web. We managed to find them on more than a hundred sites in the CZ top-level domain alone – including on websites of a couple of banks and other “trusted” organizations – just by using a few well-chosen Google dorks. Breakdown of affected sites may be seen in the following chart.

It should be mentioned that although we didn’t spend much time looking outside the .cz TLD, the situation seems to be the same in other TLDs as well – open redirects are pretty common, even on high-profile sites.

A more in-depth discussion of the results of our research was part of my talk at SANS Pen Test Hackfest Summit in Berlin in July. If you didn’t have a chance to join us there but would like to learn more, you may take a look at the slides in the SANS Summit Archives at https://www.sans.org/cyber-security-summit/archives/pen-testing. The slides cover a “half-open” redirect vulnerability in Youtube (see https://untrustednetwork.net/en/2019/07/22/half-open-redirect-vulnerability-in-youtube/) and a couple of other topics as well.
If you’re not interested in the results but would like to check whether your own web applications have any obvious open redirect vulnerabilities, I can at least share with you couple of the simple Google dorks, which might be able to help you. As the targets for a redirect are usually determined by an HTTP GET parameter and as the purpose of most such parameters is identical, their names tend to be similar as well. Good Google dorks to assist you in finding open redirects in your domains might therefore be: