We previously posted a blog about the Ursnif family of malware using language checks to determine the end user’s location as a means of bypassing sandbox-based endpoint protection during regionally targeted attacks.
Since then, we have seen a couple more examples of malware using clever methods to indirectly determine the language of the running machine’s operating system before downloading their second-stage payload.
Take for example this Word-based downloader we recently received from a customer:
The macro-enabled document launches a PowerShell script which, once deobfuscated, translates to the following:
At first, the ping call to 126.96.36.199 with the -n argument set to 0 appears nonsensical, as it will invariably fail with the error after the following error message:
“Bad value for option -n, valid range is from 1 to 4294967295.”
However, upon closer inspection, it turns out this is actually a clever language check to ensure that the payload will not be downloaded outside of France.
Under normal circumstances, the error code returned doesn’t contain the string “l'” meaning the “if” statement will evaluate to False, preventing the contained block of code from executing.
However, on French systems, the returned error code translates to the following:
“Valeur incorrecte pour l’option -n, plage valide comprise entre 1 et 4294967295.”
Since this version of the error code contains the string “l'”, the if statement on French versions of Windows will evaluate to True, allowing the payload to be downloaded.
Another example of a region-specific attack can be seen below, this time targeting Italian systems using a more conventional locale check via the .NET method “System.Globalization.CultureInfo.CurrentCulture”:
There are obvious similarities between these two attacks: both perform a regional check before pulling a second stage payload delivering the Ursnif Trojan which is hidden in a PNG image via steganography.
We have also seen evidence that regional checks are being adopted by other families of malware. For example, last week, Bromium protected against an attack delivering the Yakes Trojan and targeting Japanese endpoints. The deobfuscated PowerShell looks as follows:
In this instance, the malware evades detection by checking if the value set as the OS architecture contains the character 12499 in the UTF-8 character set. The character translates to “ビ”, which is Japanese for “bit”. Only if this value is present will the attack continue and the Trojan is downloaded.
These language detection techniques are successful at bypassing a number of sandbox-based network protections since, by default, the locale of the sandbox’s operating system is often configured to English and, without the payload itself being downloaded, it is harder to automatically detect any signs of malicious activity. This is one of the many methods that malware authors use to evade sandbox-based detection – by preventing their code from executing correctly when it is not launched on the machine of the intended target.
Bromium protects against all these attacks by running all received documents inside their own micro-VM, protecting the end-user even while malicious code is running on their own machine.