Debugging Malware collection (3 VBS scripts and 2 Autoit scripts) sent to victims through fake Galp (portuguese company) invoices

[Vsearcher]

A victim related to me got infected with a virus, and I decided to perform some reverse engineering on it.

The victim received an e-mail that claimed to be an invoice from a portuguese company called "Galp". This seems to be a virus specifically made for this scam since the code has function and variables names that make sense if interpreted as portuguese language.

I would like to mention that I'm trying to keep this guide as educational as possible so that newer people can also get something out of it and, therefore, there may be some statements and explanations that are not needed for experts. To all the experts out-there, I apologize. I would also like to receive constructive feedback so that we can learn and improve ourselves.

I'm supplying a zip file containing all the information necessary to replicate the virus execution flow, called "Malware Collection spread using fake Galp invoices.zip". Throughout the text, I'll refer to that as "collection" to indicate that a certain material is available there. Please keep in mind that I can NOT be responsible, under any circunstances, for any damage you cause to yourself or other parties by running any of the malicious scripts and executables included. You should NOT run any of the scripts nor executables if you don't know what you are doing. Even when using a virtual machine, there's a risk that, through exploiting vulnerabilities like Meltdown, the attacker could get code executed in the host environment. I made no magic to protect myself against it, I simply went through that risk. And that is the risk that you need to understand you are taking when you run any of the malicious software. Keep in mind that you are entirely responsible for the acts you perform when running any of the scripts I provide in the collection.

That being said, if you want to run the malicious program you're welcome to correct any mistakes I might have made on the explanation or to complete my explanation since, as explained below, there are still some tiny parts I didn't understand. Since I'm a human and this code is scrambled to make it difficult to read by humans, I was performing a task that was made difficult intentionally by the attackers. Therefore, it is definitely possible that I made some mistakes when interpreting the virus. I would be happy if you provide constructive suggestions on this explanation. I would like to make it clear that I don't have much experience with malware reverse engineering so experienced users may find out that "I went the hard way". Constructive suggestions on an "easier way" will be very much appreciated.

As it was impossible to upload the zip to this forum, due to size limits, I had to upload it to MEGA cloud. Here is the link to download it:

https://mega.nz/file/d0JGmJBT#sa68dMqGUINo8VwBA5bz0MdMPsZ-pqJ1gzHwePSJP0M

The password is: malware_reverse_engineered56

 

Now, lets begin the explanation of how the virus works.

I would say that, in general, the e-mail is credible, expect for the fact that it comes from a weird sender (those with random numbers in it) as well as the fact that the total electric energy consumption comes in kW instead of kWh. There is a link for downloading the supposed invoice. That link is: "https://lignesrecords.fr/wp-admin/css/--/https:/www.galp.com/pt/?cliente=<victim_email>". The link is customized for each victim, and <victim_email> is replaced with the victim's email. I tried replacing it with some garbage and the server returns code 403: Forbidden. This makes the scam more credible, by causing the impression that only the client can access to his invoice. That server is hosted in OVH. I've already reported an abuse to OVH today, but they still haven't taken down the server by the time I'm writting this.
 
That link downloads not an invoice, but a zip file, with two files inside it. The zip file is included in the material collection, it's a file named "initial virus.zip". The zip file contains two files inside, with names: "~" and "<random_chars>.vbs". The vbs file initially had a random name, but I changed it to "virus.vbs" to protect the identity of the victim, in case there is an association between the random filename and the email it is sent to.

I then proceeded to attempt to reverse engineer the virus, by running it on Visual Studio (VS), in debug mode. I used the approach suggested in: https://www.welivesecurity.com/2016/02/11/isolate-vbs-jscript-malware-visual-studio/. Keep in mind that the "isolate" word in that tutorial does not mean that it protects your computer agains the virus, you will still infect the machine you are running VS on. I used a VirtualBox virtual machine for the purpose. Keep in mind that the code has some verifications to check if it is running on a virtual machine and if so, it terminates and does not behave maliciously so that it can't be studied. I had to patch the verification, as explained below.

Let's now delve into the technical details of the virus. I have divided this into 3 main sections: "First script", "Second Script" and "Third Script".

#First Script

This "virus.vbs" is the start point of the infection. The victim is expected to click that file, which will execute if the machine supports Visual Basic Script (which all Windows versions do, by default). I think no other operating system supports vbs by default so I assume this virus was made only taking Windows machines into account, but it can still be run on other platforms if third party software is installed.
This file is all scrambled, with all variable names and hard-coded values being not human friendly.
From what I've understood, this file doesn't perform any OS calls, it simply computes information, generating random values until they meet certain conditions and then unscrambling them. The result of the computation is vbs code, which is then executed, in line 781, through an "eval" statement.

The code generated by the unscrambling process and then executed throught the eval statement is included in folder "intermediate scripts", with a filename of "second script.vbs". This leads us to the next section: Second Script.

#Second Script
That code is also scrambled a lot and difficult to understand. It contains an iterative loop that unscrambles garbage strings and generates information for the execution. If the code is run on a debugger, it's easier to understand the information generated, as it is progressively filled into a variable called "q4". A quick way to see all the generated strings is to place a breakpoint at the end of the loop, the "WEnd" statement. This way, you don't have to go through every step of the loop (that corresponds to less than one letter being written) but instead, if you jump to the next breakpoint, you will get the next string entirely built. The first generated string is the name of the vbs class that is created, which is a "Microsft.XMLHTTP". We can easily antecipate that an HTTP request will be made next, but it was obfuscated on purpose. The next string generated is "post", used for the request method. Next we have the most interesting one: the IP address of URL: "http://144.217.17.185/bd21.php". This server is also hosted at OVH and I also already requested for its shutdown but they still haven't shut it down as I'm writting this. Keep in mind that by the time you read this, you may not be able to access it anymore. You may not aswell be able to replicate all the steps of the virus if the server is already taken down, that's  If you try to enter this URL on a browser, you will quickly find out that it is also protected against reverse engineering as it returns an improper (NSFW) joke picture of the brazilian carnaval. I included the NSFW joke image which is returned if the endpoint is called with a GET request, on the same folder, file path is: "HTTP Requests/bd21.php/carnaval5.webp". Only if appropriate request params are set does it return what is used by the virus.

Since the script is not using HTTPS, the requests can easily be analyzed using a packet capturer like WireShark (there is no need to intercept the connection and create a fake certificate and all of that fancy stuff). The virus could have been made more difficult to debug if it was using HTTPS. By analysing the network traffic in WireShark, I think that all that is necessary for the server to return the information that is used by the virus is sending a param named "q1" with the value of "1". I haven't tested it by calling it with those parameters manually. It could be done using curl or Postman.
When calling the endpoint with expected parameters (the ones passed by the virus script), the server does not return the NSFW, but instead a string that apparently looks like garbage.

That string is included in the collection provided, in file "HTTP Requests/bd21.php/response.txt". I thought it was important to include this in order to be able to replicate the behavior of the virus after the server is taken down. That apparent garbage string is decrypted/unscrambled using the same function that was used to unscramble the string that builds the HTTP request object and server address, explained above. That string unscrambled results in more VBS code. It is possible to manually try this by using the Visual Studio's "Immediate Window" which allows to execute a code statement and get the result immediately, supporting the use of variables of the current execution. If you run the unscrambler function called q1 and pass the string that is included in the file mentioned above as argument, you will get the VBS code. This code is then executed, leading us to the "Third Script". 

#Third Script
This is a long one, so sitback, relax and enjoy the ride as much as possible. This is the last VBS script.
Luckly, if you step forward on the visual studio debugger, it places the code of the script on the file so that you can keep debugging the new code, facilitating debugging. The code of this script is included in file "intermediate scripts/third script.vbs".

This code is not as scrambled as previous ones. Firstly, in lines 365 to 440, the script performs a verification to check if the virus is being run under a virtual machine. I was running in a VM, but since I had the code, I bypassed the verification. The verification can be bypassed by removing the code or by using the debuggers features: manually setting the value of the boolean to false or by moving the instruction pointer to the code after the verification. Then, in lines 468 to 474, the virus performs a verification that apparently is regarding the system language. I'm not sure why they made this verification, but the script does not run if the system laguage does not correspond to one of those hard-coded in the If condition. I don't know if it is an additional layer verification for virtual machine (because on my run, it didn't meet the condition, which means the virus would not be executed, I also had to bypass this verification) or if the virus only works in systems with certain languages (but I found no evidence of such).

If the virus is not being run on a VM, then the script creates a new file, with only one char on its name. The char is retrieved from the computer name. It then creates more of these files. I didn't manage to understand what these files are for, honestly. If you can find out, I would be happy if to know. Lets call these file "misterious files". They are composed only by a single char, no extension and are all created under "C:\Users\Public\".
(It first checks if the file exists. If the file already exists, it terminates and executes nothing more. This is probably to make reverse engineering more difficult to detect running multiple times. So, to run the script multiple times, all these files must be deleted. As the script progresses, it creates more of these files.)

Then it makes a request to the URL "http://144.217.17.185/lp1a.php". This one is not protected against reverse engineering and, therefore, if openned on a web browser, it yields a string. The string changes on each request. An example is: "RFXDIDDCPFFDFDGFNDEFJCPFXDIDDCPDEDHDFCPBF".

That string returned by the server is decrypted and the result is assigned to a variable sLinkY (line 522). The result is some garbage which is then performed some replace operations on. Part of the content of that string is then used as a folder name that is created under "C:\". The initial string content appears to be random, causing the folder name created under "C:\" on each computer to be random, possibly to make debugging more difficult. Another part of the content of the string is used to build the name of the file it creates under the folder created before, which is also random. This folder created under "C:\" is the folder that will contain the final virus, so lets call it "final virus folder", for reference. Furthermore, another part of the content of the string is used to get a URL to make another HTTP request. This part should be deterministic, otherwise it wouldn't work, I think.

The URL is: "http://144.217.17.185/m/lp113.bd2". This URL is also not protected against reverse engineering and it can be accessed through a web browser. It returns a file (which can be downloaded in a web browser). It is in the file collection I prepared, in folder "HTTP Requests/lp113.bd2/lp113.bd2". The malware stores the downloaded file on "C:\Users\Public".

Then, it performs some more unscrambling and gets a garbage string turned into another garbage string and writes that to a file named "<random_char>_".
Then, it performs 4 unscramblings and gets 4 URLs.
The URLs are:
"http://144.217.17.185/m/lp1asq.bd2"
"http://144.217.17.185/m/lp1asl.bd2"
"http://144.217.17.185/m/lp1ass.bd2"
"http://144.217.17.185/m/lp1aai.bd2"
It gets a zip file from each and saves them all under "C:\Users\Public".
In total, it downloads 6 zip files from a server at 144.217.17.185 and stores them all at "C:\Users\Public".
The zip files are all included in folder "zip files saved under public folder". Remember that their names may be different on each run, because they are derived from random string contents.

Then, it writes some more garbage to the file named "<random_char>".

Then it unzips one of the zip files saved on C:\Users\Public. Then it copies the resulting file to the folder created under C:\ (with a random name). The resulting file name (under the C:\ folder) is also garbage, as well as the extension. It deletes the zip file.

Then, it unzips another zip file. This one has a special step. They call a function called "TrocaEntry" (that seems to be a scrambling function, receiving two keys, but that function is only used once in the code: here). The function itself writes a files to the folder created under C:\. Then, it deletes both the zip file and the file resulting from the unziping (because function TrocaEntry does not perform that job). ("Troca" is a portuguese language word).

I think these two files contain the code for the final virus. I tried openning the files with a text editor, but they are binary. I think it is exe, autoit compiled code, because they are passed as arguments to the Autoit3.exe standard executable that comes with autoit. Keep in mind that Autoit itself is not malicious, it is intended to be a Windows GUI automation tool.

Then, it renames one of the files to "<something>.dll" (I think it is a library used to encrypt the communication between the virus and their server). Despite trying multiple times (deleting all files and downloading all of them again) I couldn't manage to pass this step, it always throws an error, saying that the file doesn't exist. I'm not sure if their code has bugs, if I have introduced bugs in the code by trying to reverse engeneer it (which I think not because I only removed the VM verification part) or if the code has more hidden anti-reverse-engineering mechanisms that make it stop on this step and that I didn't pick up.

Then, it unzips another file and copies it to the final virus folder, renaming it to winx86.dll.
They probably placed all the needed dll's in the exe folder to make sure the virus runs even if the Windows machine doesn't have all the dll's. The dll's are also downloaded from server 144.217.17.185. Then, it deletes a file under the final virus folder and I get another error here. But I have moved the instruction pointer in the VS debugger forward so that it doesn't stop the program.

Then, it unzips another file that it copies to the final virus folder, with a fixed name of "libeay32.dll". Another dll to make sure the virus works well if the system does not have all the standard dll's. Then another unzip of another dll that is copied with the name of "ssleay32.dll". This step could have also been made more difficult to reverse engeneer by scrambling the final dll names, as they are hard-coded right where they are used, but, fortunately, it wasn't.

Finally, it unzips another file and copies it to the final virus folder, with the fixed extension ".exe". This is the final virus executable file. The virus they want to ultimately deploy is not written in VBS but, instead (I think) in Autoit. Autoit is a compiled language, that's why it produces an exe file, unlike VBS. I assume it is written in autoit because the exe file has an autoit logo. I think it is not possible to decompile de autoit exe, or at least not "feasible", so it is not possible to easily see what it is doing without using an exe debugger which is a task I'm not planning on doing right now.

Then, it executes multiple exe files which also open a TCP connection to 144.217.17.185 (as can be seen on the windows network manager). The exe files are executed in the following way: the generic autoit3.exe is called and then the files with no extension that are on the final virus folder, are passed as arguments. Since it has an encrypted communication dll on the final virus folder, I'm assuming it is communicating data. And since it is running on a victim's pc, it is easy to assume that it is stolen data. So, in my opinion this virus is to steal data, most likely passwords and credit card numbers, but I have not confirmed that because I didn't debug the exe. I think it uses the server at 144.217.17.185 to communicate the stolen data to. I've included an example of the final virus folder, in the collection, in folder "final virus folder example". Please keep in mind that the file names may be different on each run, as they are generated randomly.

Taking down this server would render this virus useless, I think, not only for newly infected users but also for already infected ones.

Many thanks for staying with me until here. I would be happy to receive feedback of any kind, even if it's not code debugging, can be suggestions on how to protect people agains this virus such as entities to inform. Suggestions on how to make the process of debugging malware easier, namely scripts or even exe's would be appreciated.

Virustotal analysis:

At the time of writting, only 14/60 antivirus engines of Virustotal detect the initial script as malware: 
https://www.virustotal.com/gui/file/49586090c223158b29e82a605f607904a51d88a79bf445687addbcb91bfbe050/detection

The second script is only detected by 2/60 antivirus engines:
https://www.virustotal.com/gui/file/bc3df706ae56dc9a840080dad1276c3d89579bb7436682cf140602013b1702d7/detection

The third script is detected by 10/58 antivirus engines:
https://www.virustotal.com/gui/file/5c2985fcdbd0b8f6c374b6714462b47ac0bc6292051a4ac25df35ef081ea9670/detection

 

I will send it to some antiviruses to make sure they detect this malware.
 

Edited March 3, 2021 by Vsearcher

[kao]

It's a decent writeup, thanks for the effort!

However, you stopped 2 steps too early:
1) The undetected file ("df65l1.l56") is not malicious per-se. It contains encrypted code - but without matching decryption code it's harmless. No wonder it gets only 3/60 detections on VirusTotal. Autoit script ("df65l") is the one that decrypts it.
2) Inside the AutoIt script, there's a DLL called "u0bhc83.dll". This DLL has only one real purpose - to decrypt and execute malicious code from "C:/p8yqa7ux6/df65l1.l56".  VT detection of the DLL 22/69.
3) Final malicious code is a banking trojan called Mispadu (https://malpedia.caad.fkie.fraunhofer.de/details/win.mispadu). VT detection 46/70.

 

 

[Vsearcher]

Thanks for your feedback.

Hmmm, interesting! I didn't see that coming 🙂

 

Btw, I'm just curious: How did you find that out?

Did you already knew this kind of trojan and since it was familiar it was easy to get right away? Or did you debug the exe with something like OllyDbg? Or anything else?

[Kurapica]

kao eats malware for breakfast

[kao]

@Kurapica: Pssst... don't tell anyone!

 

@Vsearcher: No, I didn't know the malware, just followed up on your work and did the remaining steps. Decompiling AutoIt is documented in plenty of places, debugging DLLs/EXES is my area of expertise, and name of the final malware was identified by an antivirus scan.

As for compromised server (lignesrecords[.]fr): malicious download was not actually hosted there. Instead, today it was redirecting to a Yandex Disk (https://webattach.mail[.]yandex.net/message_part_real/?sid=YWVzX3NpZDp7ImFlc0tleUlkIjoiMTc4IiwiaG1hY0tleUlkIjoiMTc4IiwiaXZCYXNlNjQiOiJzWjBueFoyK284NzNhMkhaNURpLzVnPT0iLCJzaWRCYXNlNjQiOiJwdXpDZ3FIRTVPaSt2OGJsVTJPRXhkN1JsNGtkbFlEQVBxUDlYa2pvYUxscnJPWjBrbWNscC9lUXRDZmc2ZkhERHF3NHYxWGdVUDBrTnR3UDRiWTZBNGduMzNrOEwvZGduMmFFTlNtaEIvYmI1UGxPcDZxbUJnd2RoWVRaTG9qbyIsImhtYWNCYXNlNjQiOiI2b1d6S3BkV0dITWZiNmk2bHowWU9TRGdTcGVXVEplNXRLZWZjUUt0VkNRPSJ9&name=774D00C0V11V4B4B5SSS5A5A4S111S00S1.zip). This malicious payload is very similar but not identical to the one in first post.

On the same server, there was also another phishing page impersonating different Portuguese company (www.ansr.pt). Method of infection was identical.

As for the campaign success, in last 3 hours each phishing page got 30~60 new victims. Considering that the panels were there since 21-February, I would guesstimate number of people who downloaded malicious ZIP file in low thousands.

 

[Vsearcher]

I searched for decompiling Autoit, but didn't manage any feasible way of doing it. I guess I need to start eating malware at breakfast too 😂

 

Thanks for taking the time to read that and for the follow-up, @kao.

I just checked the server at 144.217.17[.]185 and OVH has still not taken down the server 😟. Taking it down is the main circuit breaker since it will stop not only new infections but also already infected victims from getting their data stolen. I hope they shut it down soon, otherwise I work won't pay off.

1 hour ago, kao said:

As for compromised server (lignesrecords[.]fr): malicious download was not actually hosted there. Instead, today it was redirecting to a Yandex Disk (https://webattach.mail[.]yandex.net/message_part_real/?sid=YWVzX3NpZDp7ImFlc0tleUlkIjoiMTc4IiwiaG1hY0tleUlkIjoiMTc4IiwiaXZCYXNlNjQiOiJzWjBueFoyK284NzNhMkhaNURpLzVnPT0iLCJzaWRCYXNlNjQiOiJwdXpDZ3FIRTVPaSt2OGJsVTJPRXhkN1JsNGtkbFlEQVBxUDlYa2pvYUxscnJPWjBrbWNscC9lUXRDZmc2ZkhERHF3NHYxWGdVUDBrTnR3UDRiWTZBNGduMzNrOEwvZGduMmFFTlNtaEIvYmI1UGxPcDZxbUJnd2RoWVRaTG9qbyIsImhtYWNCYXNlNjQiOiI2b1d6S3BkV0dITWZiNmk2bHowWU9TRGdTcGVXVEplNXRLZWZjUUt0VkNRPSJ9&name=774D00C0V11V4B4B5SSS5A5A4S111S00S1.zip). This malicious payload is very similar but not identical to the one in first post.

I also checked the lignesrecords[.]fr server and the previous link is not working anymore. Where did you find the URL to yandex? I'm wondering if they removed it since you posted that.

1 hour ago, kao said:

On the same server, there was also another phishing page impersonating different Portuguese company (www.ansr.pt). Method of infection was identical.

I also couldn't find this. I think it was removed also.

1 hour ago, kao said:

As for the campaign success, in last 3 hours each phishing page got 30~60 new victims. Considering that the panels were there since 21-February, I would guesstimate number of people who downloaded malicious ZIP file in low thousands.

Which tool did you use to estimate the accesses to the phishing pages? And which page did you use to estimate it (because there are 3 pages so far we have discovered)?

Edited March 2, 2021 by Vsearcher

[kao]

23 hours ago, Vsearcher said:

Where did you find the URL to yandex?

At the moment of my writing, links were still working. 

23 hours ago, Vsearcher said:

I'm wondering if they removed it since you posted that.  ...  estimate the accesses to the phishing pages

Someone I know had admin access to the phishing page backend... Also, that someone cleaned up the server.
That's all I can say about that part, sorry.  

[Vsearcher]

1 hour ago, kao said:

Someone I know had admin access to the phishing page backend... Also, that someone cleaned up the server.
That's all I can say about that part, sorry.  

Oh, ok, I understand. But what do you exactly mean by "cleaned up", @kao? You mean he deleted all the client's password and data stored at 144.217.17[.]185?

Because all the servers are still working, that's why I'm not understanding what you mean by "clean".

[kao]

I was referring to lignesrecords[.]fr.  There are no more malicious pages, so no new victims (until actors hack another web server, upload their tools and send another wave of spam...)
144.217.17[.]185 is still alive and apparently hoster is ignoring abuse reports. There's not much anyone can do about that.

[Vsearcher]

1 hour ago, kao said:

I was referring to lignesrecords[.]fr.  There are no more malicious pages, so no new victims (until actors hack another web server, upload their tools and send another wave of spam...)
144.217.17[.]185 is still alive and apparently hoster is ignoring abuse reports. There's not much anyone can do about that.

Oh, ok I got it. So that's why I didn't find the scripts in lignesrecords[.]fr. But you mentioned "hack another web server". lignesrecords[.]fr was hacked by them? I thought it was their server that they hosted at OVH, because that one is hosted at OVH aswell, I checked it myself.

144.217.17[.]185 is hosted by OVH. I  contacted them through their abuse page and they still haven't done anything. Yeah, you are right about that one: there's nothing anyone can do.