Malware downloads from fake site to consult CURP (a population registry code in Mexico)


In this report we describe the analysis of a sample obtained from a site where Mexican users could supposedly consult and download their CURP (Unique Population Registry Code). The trojan gathers information about the system, cipher it and then send it to remote servers. It also uses three different methods to maintain its persistence on the infected computer.



A phishing site of the Mexican Tax Administration Service (SAT , for its acronym in Spanish), where a user could allegedly check and download his CURP after sending certain personal information, was reported to the UNAM-CERT. The URL hxxp:// displayed a form that looked like the one on the image below. After filling out the form, the file Curp.jpg.exe was downloaded to the user’s computer.

After inspecting the source code of the website, we discovered that the form was inserted through an iframe from the URL hxxp://xx.xx.xx.142/servicios/CurpPS_HTML/jsp/CurpTDP.html.


According to the, website, that contains a list of IP addresses and URLs related to malicious activity, the IP of the fake site to consult the CURP is and hosts other domains for phishing and for malware downloads.



Dynamic Analysis

The file downloaded after filling in the form was called Curp.jpg.exe. The “jpg” extension was added to the name to make the user believe the executable was an image.

During the execution of the sample in a controlled environment, the process curp.jpg.exe gets created and, from it, the sub process explorer.exe.


The sample checks Internet connection by making requests to and On the network traffic, requests to the following domains can also be observed:


Domain IP Country Argentina Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos Estados Unidos



After the execution, the sample deletes itself. When we tried to stop the process from the Process Explorer tool an error message, like the one on the image below, popped up.


File System

Two directories called “Sound Series X” were created, one in C:\ProgramData\ y the other in C:\Users\All Users\. Subsequently, the executable copies itself in both directories, with a random name formed of nine lower case letters.




If Process Explorer is opened with administrator privileges, it is possible to stop the fake explorer.exe process; however, after a few seconds, the sample created in the “Sound Series X” directory gets executed and then creates one or more subprocesses with the same name until the trojanized explorer.exe is creating again, as shown on the image below:


In the legitimate explorer.exe gets terminated, the malicious sample generates itself as a subprocess of another application that is currently executing; in this case for example, the parent process was regshot.exe.


The methods employed by this sample to assure persistence are described next:

1)      Modification of the registry subkeys HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\ and HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, adding the value “Sound Series X” and the path of the malicious executable created during the execution of Curp.jpg.exe.



2)      Creation of two subkeys in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\, one with the name of the malicious executable created and one with “rstrui.exe”, Windows application to restore the system.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\rpeulaaql.exe\DisableExceptionChainValidation: ""

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\rstrui.exe\Debugger: "hemxc.exe"

The string  “DisableExceptionChainValidation” is added to the first subkey to disable the exception validation for the copy or Curp.jpg.exe with a random name, in this case “rpeulaaql.exe”.

On the second subkey, the value “Debugger”  is added so that when the user attempts to restore the system, a copy of the malicious program gets executed instead.


3)   Windows 7 uses a DCOM (Distributed Component Object Model) mechanism to start Explorer with this command: explorer.exe /factory,{GUID}, so that communication between processes can be carried out on Windows environments. The factory class created an instance of the object indicated on the CLSID. A CLSID (Class ID) is a number of 128 bits that identifies an application or component of the system without having to know its name; for example: certain important directories in Windows have a CLSID associated, as can be seen on the following link:


C:\Windows\explorer.exe /factory,{682159D9-C321-47CA-B3F1-30E36B2EC8B9} -Embedding


In this case, the CLSID is  {682159D9-C321-47CA-B3F1-30E36B2EC8B9} and identifies the DesktopExplorerFactory class, as shown on the field called “Command line” on the next image.


On the properties of the troyanized explorer.exe, there’s a field called  “Autostart location” with the subkey HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Sound Series X. Due to this, every time a new instance of explorer.exe is created, the malicious sample is also executed.



This malicious program also performs the following activities:

-          Read the hosts file without writing in it.

-          Search for registry keys that indicate the installation of any of the following antivirus: Symantec, AVG, Kaspersky, AVP, BitDefender, Trend Micro Titanium, Avast!, Trend Micro Client Framework, G Data, ZoneAlarm, Avira, ESET, Arcabit, Bkav, AhnLab y Baidu.


-          Looks for registry keys that indicate the presence in the computer of: Runescape, Blizzard Entertainment applications (Diablo, StarCraft, World of Warcraft, etc.), Minecraft, League of Legends, Skype, VMware or Visual Studio.



Network Activity


After giving Internet access to the sample, it attempted to send information, using the POST method, to the domains mentioned previously.


As seen on these images, the data was ciphered and the key seemed to change on every packet.



Static Analysis

The tool Exeinfo PE was used to discover whether the sample was packed, however, it didn’t detect the use of any software to compress or cipher executables (packer).


The next step was to obtain information about the type of cipher used to on the data that was sent to remote servers. Amongst the imported functions obtained during the static analysis of the executable there was none related to data encryption. This left us with two options: the sample could be using its own encryption algorithm or it calls encryption related functions during its execution, in other words, dynamically, using the functions  LoadLibrary y GetProcAddress. With LoadLibrary the DLL gets loaded and with GetProcAddress it obtains the address of the functions. By calling functions dynamically the size of the file gets reduced because it is not necessary to link the library statically.


To know if the functions were called dynamically, we made a full memory dump of the malicious explorer.exe process with the tool LordPE.


The generated file is called “dumped.exe” and, as shown on the image below, it has the same properties as the legitimate explorer.exe.


After opening the file with Bintext the following strings, corresponding to some functions of the Crypt32.dll, module used to implement many of the routines related to cryptography in the Windows and Windows Server operating systems, can be seen.


CryptAcquireContextW: Used to obtain the handle of a cryptographic service provider (CSP) and is the first step to use this API.

CryptCreateHash: Creates the hash object.

CryptHashData: This is the function used to add data, such as a password.

CryptGetHashParam: Used when the value of the hash is required.

CryptDestroyHash: Destroys the hash object.

CryptReleaseContext: This is the last step, with this function the CSP handle is released.


Now we know the malware uses Windows functions to cipher the data sent to remote servers. Using IDA Pro’s plugin FindCrypt that determines whether a program uses cryptographic algorithms or hash functions based on the constants used, we only got this result:

FindCrypt only detected the table of pre-calculated values of CRC32 , which can be seen on the following image.