This Wednesday reports about USB-drives with malicious code being found in the area Lindholmen in Gothenburg, spread in Swedish media. It was reported by, among others, IDG, Expressen, SVT and even far-right sites such as Nordfront. This quickly spread in social media and all kinds of wild theories started to appear including industrial espionage and Russian hackers using "military-grade encryption". All of this, of course, without any kind of evidence to back it up. Being a strong opponent to the FUD that is very commonly spread in security related events I sought to dig deeper into this.

## The USB-drive

Through contacts in the Swedish security community, I managed to get a copy of the contents of the drive and could analyze it. What follows is my analysis of the USB-drive and the malware contained in it.

The USB-drive contained three copies of the same Windows PE executable.

SHA256 hash Filename
dcd7b8681e9ebcb657cb8f2f3d85c8920f6321c3f90885c31f3a3ab72c4a11cb aPassTtxt.exe
dcd7b8681e9ebcb657cb8f2f3d85c8920f6321c3f90885c31f3a3ab72c4a11cb PassTtxt.exe
dcd7b8681e9ebcb657cb8f2f3d85c8920f6321c3f90885c31f3a3ab72c4a11cb Grattis.exe

The first two files actually have some special characters in their names which are not shown above. The hex encoded filenames are shown in the table below:

Hex-encoded filename Filename
615061737354 e280ae 7478742e657865 aPassT‮txt.exe
5061737354 e280ae 7478742e657865 PassT‮txt.exe

Note the three bytes in the middle "e280ae" which corresponds to Unicode codepoint U+202E, RIGHT-TO-LEFT OVERRIDE which, in for example Windows Explorer, make it look like the files are called "aPassT.txt" and "PassT.txt" respectively thus tricking the user to click them thinking that they are only regular text files. All three of the files contain a Ransomware called "Philadelphia Ransomware".

The Philadelphia ransomware is a rather simple ransomware. It is a crimekit selling for about $400 and can be configured by the user before being unleashed on victims. The configuration parameters include things like which file types it targets, whether it will try to infect USB-drives or network shares and which command & control servers it should contact. It's a successor to another ransomware called "Stampado" by the same author, "The Rainmaker". This version was released after "Stampado" was broken by Fabian Wosar at Emisoft. It has been seen in the wild since around October 2016. More background can be found in this article from Bleeping Computer. The ransomware is written with AutoIt 3, a system used by system administrators to automate various tasks in a computer. AutoIt programs are written in a language similar BASIC and can be compiled to a self-hosted executable. This AutoIt code is also heavily obfuscated to prevent analysis. My analysis started out with looking at the "Grattis.exe" executable and after looking at embedded strings I was lead to believe that this indeed was an AutoIt script. To make sure that the program wasn't trying to mislead me and cloak itself as a simple ransomware, I also did a quick analysis of the program in IDA but found no signs of any foul play. Using a tool called Exe2Aut I was able to decompile the AutoIt script which resulted in 5 files belonging to the Malware. The names of the files and their purpose, which I didn't know at the time, are listed in the table below. Filename role Grattis_.au3 The main script file stub.au3.509 Constants for the main script, encoded pd4ta.dat Configuration for the malware, encrypted ph1la.bin Secondary script file, encrypted, delphi.au3.509 Constants for the secondary script, encoded The Grattis_.au3 script file was obfuscated with two main techniques, very commonly found in script-based malware, such as Office macros and Javascript. First, all variables and functions have been renamed to garbage. Secondly, all constants have been removed from the script and put into a separate file. To get the constants back into the script, it uses a clever trick which I later found out is to twart the efforts from the deobfuscator in a tool called myAut2Exe. The method worked by setting a start-up function directive in the beginning of the file and loading all constants from an array called$cw which doesn't seem to exist. The array is of course created as a global variable inside the init function "A2100001B1E_" so that when the execution reaches line 6, the constants are loaded into various global variables.

The init function "A2100001B1E_" works by repeatedly hex-decoding a string and passing it to "Execute", the eval-function in AutoIt.

By manually decoding these strings several times we get a function which looks like this:

The function called on line 2 is basically just hex-decoding the filename. As you can see, this function reads the constants file, splits on the five character delimiter and assigns this to the \$cw array. After this function has been run, which is the first thing that happens, the previous code at the top makes sense and creates a lot of variables containing all the constants used in the script. At this point I created a Python script which went through the code and replaced each occurence of the constant variables with the actual constant they contained. The code consists of a lot of function. Most of them is basically a wrapper around a Windows API call. For example, one function looks like this when deobfuscated.

I continued naming functions and variables with the deobfuscation script which made it quite readable. Skipping the function declarations and looking at the actual entry point of the program we find code that looks like this.

The configuration file is decrypted with RC4 and a fixed key. The secondary script is then decrypted with a key from the config file. By writing a small script it is possible to decrypt both these files. The config file is then further encrypted by encrypting every section, key and value of the INI file. This is all done with the same key and is also easily decrypted revealing a config file:

Here we see the addresses of the command & control servers, probably unknowing third-party sites which have been infected by the malware creator. The malware supports localization by translating the strings in the config. It also contains configuration paramters for the russian roulette feature which deletes files randomly. The folders and settings sections control what files it should encrypt, where it should encrypt and how it should spread.

With the key in the settings file, we can decrypt the "delph1.bin" file which is another AutoIt script. This script can then be decompiled with the tool myAut2Exe to reveal another script. During the decompilation of this script we can see three interesting log messages from the decompiler, indicating that the attacker compiled the malware on a computer with a user account called "JohannaData".

000000E8 -> CompiledPathName: C:\Users\JohannaData\AppData\Local\AutoIt v3\Aut2Exe\aut45E6.tmp
00017E82 -> CompiledPathName: C:\Users\JOHANN~1\AppData\Local\Temp\jfthvbj\delphi.au3.509


The inner script is obfuscated in the same way as the main script and is deobfuscated in a very similar process. In this part of the code we find the GUI parts and the communications with the C&C servers.

By trying one of these commands against the C&C servers we get a response with an infection ID, the BitCoin wallet to pay to and the amount to pay.

I tried all of the C&C servers but only the following three were still funcitonal.

http://elleranfitness.com.au/b1.php
http://smspillar.com/b1.php
http://elleranfitness.com.au/css/b/b1.php


There is also a fallback Bitcoin wallet hardcoded in the code, probably belonging to the malware author. checking both of these wallets, we see that, as of this writing, no money has been paid.

Comment Wallet Balance

We also find the key generation algorithm which uses the built-in random function of AutoIt to generate a 32-40 character long key. AutoIt uses Mersenne Twister internally for its random generator. Unfortunately for the author, it is always seeded with the current time which makes key recovery almost trivial. The files encrypted with this malware can thus be decrypted without paying for the key. Furthermore, as shown above, the key is passed as a GET prameter over plain HTTP to the C&C server which means that if you have any kind of logging proxy or similar the key gets recorded there.

There is also, again, a message to Fabian Wosar at Emisoft which can be found in the code. The hash of this message is actually used as the default encryption key for the inner script.

Another interesting thing about the code is that it still has all debug functionality left. All around the code there are calls to a function, which I named debug_print. This function checks if any of the command line arguments to the program is "debug" in which case it writes the debug message to a file called "philadelphia_debug.txt" on the desktop.

The malware also has the ability to whitelist machines from specific countries. This particular attack has not configured that list however and targets everything. The code is still there though and would base its decision on the "LocaleName" registry key.

Overall, there is nothing else that's interesting about the malware. Basically it does the following, very typical ransomware operations:

2. Generates a key
3. Sends it to the C&C servers
4. Locates files according to the config
5. Encrypts the files with the key using AES256 through the Windows Crypto API
6. Generates a message for the victim.
7. Installs itself to autorun on the computer

Furthermore, upon payment it:

1. Contacts the C&C servers to get the key
2. Decrypts all files
3. Uninstalls itself