Since last June 2020, a new wave of the URSA trojan – a derivation and also known as mispadu malware by ESET – has affected users from several countries, including Bolivia, Chile, Mexico, Argentina, Ecuador, Peru, Colombia, Paraguay, Costa Rica, Brazil, Spain, Italy, and Portugal. This malware is a trojan malware, and when installed on the victim’s devices, it collects passwords from browsers and from popular software such as FTP and email services and also performs banking browser overlay to lure the victims to introduce the banking credentials while the flow is executed – step-by-step – in the background by criminals.
Below, a geographic representation of the number of infections between June and mid-September 2020 around the world according to Table 1.
URSA trojan – Geomap of Infections
June – mid-September 2020
Table 1: URSA trojan – infections by country between June and mid-September 2020.
In total, 3.379 users were impacted by this threat from June – mid-September 2020 according to data obtained from some C2s this wave. With a total of 1977 infections, Mexico is the country with more users affected, followed by Spain – 631 victims, Portugal – 514, and Chile – 331.
It is important to realize that the number of infections may have been much higher, as these indicators are only related to the data existing in some of the C2s presented at the end of the article. For example, no infections have been identified in Italy, which cannot be true.
How URSA trojan spreads
URSA malware is a relatively recent trojan and aims to steal credentials from victims’ machines and to create banking overlay windows when the victim visits their home banking portals. URSA is propagated via social engineering schemas – namely, phishing/malscam campaigns. In Portugal, the threat has been disseminated in-the-wild and impersonating four popular organizations, namely Vodafone, EDP (Energias de Portugal), MEO (Serviços de Comunicações e Multimédia, S.A), and Polícia Judicíaria – one of the police organizations responsible for criminal investigations in Portugal.
The email message generally refers to overdue invoices – the decoy – in order to lure the victim to download the malicious file (a .zip file downloaded from the Internet). These emails are often sent between the end and the beginning of each month.
Figure 1: Email templates of URSA impersonating Vodafone, EDP and Polícia Judíciaria – Portugal.
URSA loader in detail and the rabbit holes
At first glance, the file downloaded via the malicious URL sent by criminals on the email scam is a zip file with an MSI (Microsoft Installer) inside. By analyzing the MSI file, it’s possible to observe that another file is available inside, and probably dropped when the MSI is executed. That file called px3q8x.vbs is a VBscript file responsible for loading and executing the next stages. Interesting to note this file has a low detection rate bypassing, thus, popular antivirus (AV) engines.
Threat name: 554S2000A2S144D1S4111D.zip
Threat name: 554S2000A2S144D1S4111D.msi
Threat name: px3q8x.vbs (initial payload – VBScript)
Figure 2: MSI file with another file inside – a VBScript called px3q8x.vbs – the Ursa trojan VBScript loader.
During this article, we can observe that the URSA trojan has two loaders. First, a VBScript loader followed by several rounds of obfuscation and rabbit holes. The final VBScript is responsible for starting and dropping the files on disk and executing an AutoIt loader/injector. That binary injects into the memory via the Process Injection technique some DLLs, including a Delphi binary related to the banking overlay windows, and also the one that establishes all the communication with the C2 server.
The following image presents a high-level diagram of how the URSA trojan works.
Figure 3: URSA trojan / Mispadu 2020 – high-level diagram.
VBScript deobfuscation rounds
After extracting the VBscript loader, we observed that it is very confused and obfuscated as presented in Figure 4.
Figure 4: URSA VBScript loader – code obfuscated to bypass AV and make hard its analysis.
Some deobfuscation rounds after, we got a more readable version. Notice that some parts related to useless code were removed. In detail, the VBscript is grouped into two parts. The first part is the method of the Installer object that returns a new Record object with the requested number of fields (code highlighted below).
Figure 5: Analysis of URSA loader VBScript – first part – record object part.
The second part is the code of the next payload encoded. That payload is then executed and is responsible for decoding another payload (the 2nd payload in Figure 5 – step 5).
Figure 6: Analysis of URSA loader VBScript – second part – payload 2.
This new payload (after deobfuscating the code and renaming some functions and variables) is another VBScript, with the final payload that requests the next stage from the C2 server. Of course, this was funny, some rounds of rabbit holes.
Figure 7: Analysis of URSA loader VBScript – third part – payload 3 – step 8.
Figure 8: Network traffic when the next malware stage is downloaded from C2.
Finally and highlighted above, we got the C2 IP address (191.235.99.]13) and the final payload this stage from the C2 server.
URSA trojan – VBscript loader/dropper (the final VBScript)
Threat name: final payload (VBScript)
After some rabbit holes, finally, we got the URSA VBScript loader totally deobfuscated from the C2 server. Just the malware configuration is encrypted, and all the communications between the C2 server and trojan clients are performed using the same algorithm, even during the final stage of this malware – a Delphi PE file responsible to create the banking overlay windows, collect credentials from the victim’s machine, and send all the date to the C2 online.
Figure 9: URSA final VBScript loader and its configuration.
From Figure 9, we can observe the following:
- some paths from the C2 server (SRoleX and sRoleXW2)
- the path where binary files from C2 are downloaded to (cRaiz1); and
- some sections that are used to build the final stage (an AutoIT binary responsible for injecting and executing the malware final stage into the memory – the mentioned Delphi file).
As mentioned, all the communications from this point are encrypted between the malware and the C2 server. In order to decrypt the malware communication, we can use the next script available on GitHub.
By executing the script, decrypt the malware config was possible as observed below.
Figure 10: Ursa trojan config decrypted.
The variables “#wp#” are the final C2 endpoint where the victim’s information is sent during the malware execution. Also, several host repetitions were identified. This is a potential C2, that notifies criminals when a new victim is affected. Nonetheless, the malware next stage is downloaded from the IP address (191.235.99.]13) as analyzed above.
During the VBScript code analysis, some functions were identified:
Function GetWmiPropertyValue(strNameSpace, strClassName, strPropertyName) function crypt(cText, cCod) function decrypt(cText, cCod) Function UnZip(ZipFile, ExtractTo) Function StringGetURL(sUrl) Function BinaryGetURL(strURL) Function StringGetURL(strURL) Function SaveBinaryData(arrByteArray, strFileName) Sub writeBinary(bstr, path) Function makeArray(n) ' Small utility function Function TrocaEntry(strFileName1, strFileName, sSenhaVelha, sSenhaNova) function cr1pt(x, c)
In general, the next malware stage is retrieved from the C2 server in several parts and then built on the fly. The files are encrypted and are decrypted during the malware execution. Next, a final PE file is built during this process. Some interesting functions are presented below. Interesting to note that the user agent used to download the files is: “strUserAgentString = “binary_getter/1.0”“.
Figure 11: Some parts and functions of the VBScript file.
After this initial process, some validations regarding the victim device are performed to start the next stage. The Operating System (OS) version is retrieved, and if it is a virtual environment, the script terminates its execution. Interesting to observe this anti-VM technique earlier on the trojan loader. With this logic in place, the final payload is not loaded and downloaded from the C2 allowing it not to be at least flagged by antivirus engines.
Figure 12: Anti-VM technique found on the URSA loader.
Next, the script validates the victim devices is geo-located in target locations defined by the malware operators, namely:
- Spanish – Spain (Traditional) 1034
- Portuguese – Brazil – 1046
- Spanish – Mexico – 2058
- Portuguese – Portugal – 2070
- Spanish – 58378, 3082
Figure 13: Target locations affected by URSA malware.
If the victim’s computer is executing in a language ID different from the hardcoded, or the computer name is equal to “JOHN-PC“, the infection process stops. Change the computer name to “JOHN-PC” is a potential killswitch to avoid URSA infections.
At this moment, the next stage is downloaded from the C2 server. The files are stored into the C:\Users\Public folder (tmp file), and next moved to a random folder created on the C:\ drive. The name of this folder is based on the computer name.
Figure 14: Next binaries (AutoIT – the injector/loader) and the URSA trojan (a Delphi binary injected into memory are download from the C2 server.
Along the way, two additional DLLs are also downloaded. One is a DLL for SSL and the other for SQLite3. They are probably dependencies packaged in the malware, and to avoid a failure if the target machine does not have these DLLs/resources installed on the device. We will observe that the final binary – URSA Delphi – has two tools inside and packed. These tools are legitimate software used during the credential harvesting process.
After this complex process, the final files are moved into the C:\”artibrary_name” folder.
Figure 15: Final stage is moved into a random folder created on the C:\ (o0t – in this case).
Next, another loader/injector, the AutoIT file is executed. It is responsible for loading into the memory the final payload (Delphi file that contains the trojan code and the malicious process).
Figure 16: Final payload is executed.
Ursa trojan – AutoIT loader/injector
Threat name: n11ai.exe
Threat name: n111.11n
Threat name: winx86.dll
Threat name: libeay32.dll
Threat name: n11
The AutoIT binary is protected and can be decompiled with the following script available on GitHub. That script is a build of myAut2Exe modified from the original and based on the version 2.12.
Figure 17: AutoIT decompiled code (n11ai.exe).
As observed, some calls from kernel32.dll are imported in order to perform the Process Injection technique.
LOCAL $KERNELHANDLE=DLLCALL($_MDKERNEL32DLL,"ptr","LoadLibrary","str","kernel32.dll") $_MFHOOKBAK=DLLSTRUCTCREATE("ubyte") DLLCALL($_MDKERNEL32DLL,"int","WriteProcessMemory","ptr",-1,"ptr",DLLSTRUCTGETPTR($_MFHOOKBAK),"ptr",$_MFHOOKPTR,"uint",7,"uint*",0) DLLCALL($_MDKERNEL32DLL,"int","WriteProcessMemory","ptr",-1,"ptr",$_MFHOOKPTR,"byte*",184,"uint",1,"uint*",0) DLLCALL($_MDKERNEL32DLL,"int","WriteProcessMemory","ptr",-1,"ptr",$_MFHOOKPTR+5,"ushort*",57599,"uint",2,"uint*",0)
In detail, the file n111.11n is one of the DLLs imported – the Delphi PE file. All the DLL files are injected depending on the passed arguments. These command lines are executed in Figure 17, at the end of the VBScript loader.
"C:\o0t\n11ai.exe" n11 @ "C:\o0t\n11ai.exe.exe" n11 ##1 "C:\o0t\n11ai.exe.exe" /stext "WWy1" "C:\o0t\n11ai.exe.exe" n11 ##3 "C:\o0t\n11ai.exe.exe" /stext "WWy0"
In detail, this AutoIT loader is seen as a maestro. It loads the malware by parts, namely:
- n11 @ – DLL inside AutoIT that loads the Delphi binary into the memory.
- n11 /stext “WWy1” – executes the module of collecting passwords from the browser.
- n11 /stext “WWy0” – executes the module of collecting credentials from popular software (FTP, email, etc.).
Figure 18: DLLs injected into the memory (Delphi binary, and other).
On the other side, the two DLLs seem to be referred to SSL and SQLite3, probably dependencies to execute the tool available inside the Delphi PE file (winx86.dll and libeay32.dll).
Figure 19: DLLs stored in the same path of AutoIT binary (the Delphi loader).
Digging into the URSA final stage (Delphi trojan)
Threat name: 36f0000.rec.dll (extracted from memory)
The last stage is a Delphi binary responsible to execute browser overlay to control and steal the victim’s data while they are accessing their home banking portals. The activity and code similarities here observed are much close to other analyzed and popular trojans operating in Portugal and Latin America, such as Grandoreiro and Lampion [1, 2]. According to an ESET analysis, the final payload is Mispadu, an ambitious Latin American banking trojan that extends its attack surface to web browsers.
The Delphi binary has also two legitimate tools inside. These tools are used to collect credentials stored on the victim’s device.
Figure 20: Binary files available inside the Delphi binary.
These tools are executed when the final stage starts, and the data is stored between the tags “F1” and “F2” highlighted below.
Figure 21: Blocks of code where the credential stealer modules are executed.
In detail, these tools are legitimate and from Nir Sofer. The first one – WebBrowserPassView is launched in memory and used to exfiltrate credentials from the popular web browsers. On the other side, Mail PassView is used to collect data from several locations.
Figure 22: Tools embedded inside the trojan file and used to collect data from the infected device.
At the end of the harvesting process, the data is sent to the C2 server.
Figure 23: Victim’s credentials collected and sent to the C2 server.
The trojan is simultaneously listening and monitoring which windows and websites are accessed by the victim (it get the focus windows on the web-browser). When a target banking portal is accessed, an overlay window is created on the legitimate web browser window depending on the accessed banking portal.
In short, the next figure shows some target banks “operated” by URSA trojan criminals.
Figure 24: Target banking organizations operated by URSA trojan loader criminals.
The complete list can be found below.
.text:039E67D0 00000010 unicode BMSC_BO .text:039E67EC 0000001C unicode BANCOUNION_BO .text:039E6814 0000000E unicode BNB_BO .text:039E6830 00000010 unicode BISA_BO .text:039E684C 0000000E unicode BCP_BO .text:039E6868 00000014 unicode FASSIL_BO .text:039E6888 00000018 unicode BANCOFIE_BO .text:039E68AC 00000018 unicode BANCOSOL_BO .text:039E68D0 0000000C unicode BG_BO .text:039E68E8 00000014 unicode BANECO_BO .text:039E6908 0000001A unicode CORPBANCA_CH .text:039E6930 00000010 unicode BBCA_CH .text:039E694C 00000024 unicode BANCOFALABELLA_CH .text:039E697C 00000020 unicode BANCOEDWARDS_CH .text:039E69A8 0000001E unicode BANCORIPLEY_CH .text:039E69D4 00000018 unicode TBANCWLS_CH .text:039E69F8 00000014 unicode BANEFE_CH .text:039E6A18 0000001C unicode SCOTIABANK_CH .text:039E6A40 00000010 unicode BICE_CH .text:039E6A5C 0000001C unicode BANCOINTER_CH .text:039E6A84 00000024 unicode BANCOCONSORCIO_CH .text:039E6AB4 00000010 unicode BITCOIN .text:039E6AD0 0000000E unicode PAYPAL .text:039E6AEC 00000014 unicode BANKIA_ES .text:039E6B0C 00000018 unicode SABADELL_ES .text:039E6B30 0000001A unicode BANKINTER_ES .text:039E6B58 00000018 unicode IBERCAJA_ES .text:039E6B7C 0000001A unicode LIBERBANK_ES .text:039E6BA4 00000014 unicode ABANCA_ES .text:039E6BC4 0000001C unicode KUTXABANCA_ES .text:039E6BEC 00000016 unicode UNICAJA_ES .text:039E6C10 00000012 unicode GERAL_PT .text:039E6C30 0000000E unicode BPI_PT .text:039E6C4C 0000001A unicode NOVOBANCO_PT .text:039E6C74 0000000E unicode BCP_PT .text:039E6C90 0000000E unicode CGD_PT .text:039E6CAC 00000014 unicode ACTIVO_PT .text:039E6CCC 00000018 unicode MONTEPIO_PT .text:039E6CF0 0000001C unicode CREDITOAGR_PT .text:039E6D18 0000000E unicode BPM_IT .text:039E6D34 00000010 unicode BPER_IT .text:039E6D50 00000016 unicode UNICRED_IT .text:039E6D74 00000018 unicode SAMPAOLO_IT .text:039E6D98 0000000E unicode BNL_IT .text:039E6DB4 00000018 unicode BANCAMPS_IT .text:039E6DD8 0000001A unicode SANTANDER_CH .text:039E6E00 0000001A unicode SANTANDER_ES .text:039E6E28 00000010 unicode BBVA_ES .text:039E6E44 0000001A unicode CAIXABANK_ES .text:039E6E6C 0000001A unicode SANTANDER_PT .text:039E6E94 00000010 unicode BBVA_MX .text:039E6EB0 00000014 unicode AZTECA_MX .text:039E6ED0 00000016 unicode BANAMEX_MX .text:039E6EF4 00000016 unicode BANORTE_MX .text:039E6F18 00000012 unicode SANTA_MX .text:039E6F38 00000010 unicode HSBC_MX .text:039E6F54 00000014 unicode SCOTIA_MX .text:039EA11C 0000000A unicode bbva .text:039EA134 0000000A unicode xico .text:039EA15C 00000008 unicode 99_ .text:039EA170 00000006 unicode 99 .text:039EA184 0000000A unicode BBVA .text:039EA1AC 0000000C unicode banco .text:039EA1C4 0000000E unicode azteca .text:039EA1E0 0000001A unicode Banco Azteca .text:039EA208 0000001C unicode banconacional .text:039EA230 00000010 unicode agrcola .text:039EA24C 00000032 unicode Banco Nacional de México .text:039EA28C 00000010 unicode banorte .text:039EA2A8 00000010 unicode Banorte .text:039EA2C4 00000014 unicode santander .text:039EA2E4 0000001E unicode bancadeempresa .text:039EA310 0000000C unicode mxico .text:039EA328 00000012 unicode gobierno .text:039EA348 0000000A unicode pyme .text:039EA360 00000020 unicode Banco Santander .text:039EA38C 00000014 unicode caixabank .text:039EA3AC 00000008 unicode bpi .text:039EA3C0 00000014 unicode CaixaBank .text:039EA3E0 00000016 unicode scotiabank .text:039EA404 0000000E unicode Scotia .text:039EA420 0000000A unicode hsbc .text:039EA438 0000000A unicode HSBC .text:039EA450 0000000A unicode solu .text:039EA468 00000010 unicode advance .text:039EA484 00000012 unicode investor .text:039EA4A4 00000012 unicode Santader .text:039EA4C4 00000016 unicode blockchain .text:039EA4E8 00000010 unicode bitcoin .text:039EA504 00000010 unicode binance .text:039EA520 00000012 unicode coinbase .text:039EA540 0000000E unicode kraken .text:039EA55C 0000000E unicode crypto .text:039EA578 00000012 unicode primebit .text:039EA598 0000000C unicode bitso .text:039EA5B0 0000000E unicode paypal .text:039EA5CC 0000000E unicode bankia .text:039EA5E8 0000001C unicode bancosabadell .text:039EA610 00000014 unicode bankinter .text:039EA630 00000012 unicode ibercaja .text:039EA650 00000014 unicode liberbank .text:039EA670 0000000E unicode abanca .text:039EA68C 00000014 unicode kutxabank .text:039EA6AC 0000001A unicode unicajabanco .text:039EA6D4 00000012 unicode bancobpi .text:039EA6F4 00000014 unicode novobanco .text:039EA714 0000001C unicode millenniumbcp .text:039EA73C 0000001A unicode caixadirecta .text:039EA764 00000016 unicode activobank .text:039EA788 00000012 unicode montepio .text:039EA7A8 00000014 unicode crditoagr .text:039EA7C8 0000002C unicode bancapopolaredemilano .text:039EA800 00000012 unicode bancobpm .text:039EA820 0000000A unicode bper .text:039EA838 00000014 unicode unicredit .text:039EA858 00000010 unicode banking .text:039EA874 00000028 unicode bancaintesasanpaolo .text:039EA8A8 00000008 unicode bnl .text:039EA8BC 0000000C unicode banca .text:039EA8D4 00000012 unicode bancamps
During the malware analysis, some interesting overlay windows were obtained. More details and full images available at the end of the article.
Figure 25: Banking overlay windows from URSA trojan banker.
When the malware detects the victims accessed a target home banking portal, a socket connection is established to the malware operator (C2 server). Criminals control each step, requesting specific data step-by-step in a back-office portal. Some commands hardcoded inside the malware are presented in Figure 26.
Figure 26: Internal commands of URSA trojan.
C2 details and victim’s data
The victim’s data is sent to C2 during the malware execution. During our analysis, it was possible to collect information on the number of victims affected during this wave (June – mid-September), as well as all data exfiltrated from the victims’ devices.
Figure 27: Some affected users and AV engine installed and running in the infected device.
Interesting that this malware evades AV detection, at least the phase where credentials were collected. We can see in Figure 28 that many affected computers were running popular antivirus and were infected by this threat. On the other side, all the victim’s data is stored in TXT files on the C2 server. The file starts with the id language (Portugal – 2070), followed by the computer name, trojan compilation ID, and finally, the victim ID present on the C2 database.
Figure 28: Ursa trojan – victim’s details.
The geo-map initially addressed in this article was based on the C2s available below, and based on the number of available infections found there.
URSA trojan – Banking Overlay Windows
Mitre Att&ck Matrix
Indicators of Compromise (IOCs)
---- Phishing URLs Portugal #0xSI_f33d --- hxxps://medeiros-boatworks.]com/wp-content/!/https:/my.vodafone.pt/?client=xxx hxxps://publichealth.msu.ac.]th/eng/wp-content/languages/--/my.vodafone.pt/?client=xxx hxxps://kresna.co.]id/sarikresnakimia/wp-content/!/www.edp.pt/?client=xxx hxxps://robyn-plombier-chauffagiste.fr/wp-admin/css/--/https:/www.policiajudiciaria.pt/?cliente=xxxx ---- URLS ----- hxxp://191.235.99.]13/lp1a.php hxxp://191.235.99.]13/m/ ---- C2 ----- 191.235.99.]13 191.239.122.]4 40.70.86.]161 52.91.227.]152 87.98.137.]173 144.217.32.]24 51.81.104.]17 104.44.143.]28 51.143.39.]80 45.132.242.]89 13.58.123.]122 51.222.39.]127 66.70.237.]175 54.233.78.]131 51.222.39.]128 54.39.33.]188
Online Sandbox URLs
px3q8x.vbs initial VBScript:
final payload (VBScript): https://www.virustotal.com/gui/file/5b91c8acffe1980653718a493e24bde7211ee825ea2947df54c03e9733d61a70/details
n11ai.exe (AutoIt loader/injector): https://www.virustotal.com/gui/file/237d1bca6e056df5bb16a1216a434634109478f882d3b1d58344c801d184f95d/details
6f0000.dll (Delphi trojan): https://www.virustotal.com/gui/file/93488eab403fafb3d8e10d38c80f0af745e3fa4cf26228acff24d35a149f6269/detection
Samples MalwareBazaar: https://bazaar.abuse.ch/browse/tag/URSA%20trojan/
➡️target countries: #PT🇵🇹, #BO🇧🇴, #CH🇨🇱 #ES🇪🇸, #MX🇲🇽, #BR🇧🇷, #IT🇮🇹
➡️browser overlay (banking)🏦
➡️C2 [ 188.8.131.52, 184.108.40.206] @ azure & aws✅
➡️origin: BR 🇧🇷 pic.twitter.com/GW3XtXB8BD
— Pedro Tavares (@sirpedrotavares) September 13, 2020
Pedro Tavares is a professional in the field of information security, working as an Ethical Hacker, Malware Analyst, Cybersecurity Analyst and also a Security Evangelist. He is also a founding member at CSIRT.UBI and Editor-in-Chief of the security computer blog seguranca-informatica.pt.
In recent years he has invested in the field of information security, exploring and analyzing a wide range of topics, such as pentesting (Kali Linux), malware, hacking, cybersecurity, IoT and security in computer networks. He is also Freelance Writer.
Read more here.