Technical Analysis of ProfileVisitor Malware on Facebook

Gary Kong
7 min readMar 30, 2021

Introduction

“Hi, you can see who is using ProfileVisitor application to visit your personal details!” How would you react when this kind of post appearing on your Facebook feed? Many would be tempted to click on the hyperlink.

This article documented the technical findings performed for this ProfileVisitor attack that came out recently. Let’s see how the attack works!

Part 1: Analysis of HTTP Request and Response

Before clicking on the https://is[.]gd (“malicious link”) on Facebook, Burp Suite, a web proxy server is configured in our lab to intercept all the HTTP request sent from our browser. Each of the HTTP request and response is analyzed manually in Burp Suite to understand the flow of how the malware is obtained from adversary’s server.

By intercepting the HTTP communications, the malicious URLs associated with the malicious link are recorded in HTTP history. As shown in the screenshot below, four (4) HTTP requests are found.

HTTP response status code 301 shown in item #13 indicates the first malicious link https://is[.]gd tries to redirect the victim to visit Google Cloud Storage (http://storage[.]googleapis[.]com/). An interesting JavaScript snippet is found at the HTTP response from Google Cloud Storage in item #14.

1.1 Anatomy of JavaScript

The JavaScript snippet is obfuscated. To make it easier for us to understand the concept, the JavaScript is simplified in the screenshot below.

A list of Unicode is stored into an array idtorg. Each of the Unicode to be added by 18 (value stored in variable fvvea) in a For Loop to gain the ideal Unicode. Once the ideal Unicode are calculated, the Unicode are converted into string data type by using String.fromCharCode() method (value stored in variable gtfct and jhxckx) and stored into variable zuenyt. Lastly, JavaScript stored in variable zuenyt as string data type is executed using eval() method.

A HTTP request is made (item #17) to https://pu***** by using fetch() method. Again, JavaScript snippet is found at the HTTP response that trigger a file download for malicious file ProfileVisitors (v1.6.7).mp4.

1.2 Blob URL

In variable getBlob, a HTTP fetch is sent to https://pu*****/ajax/7z[.]php. A Binary Large OBject (blob) object is returned from the HTTP response with the MIME type of MP4 movie (video/mp4) and used to generate a hyperlink later.

An invisible <a> element with opacity level of 0 is created using document.createElement(“a”) and append to <body> using document.body.appendChild(). The snippet below illustrate how the hyperlink is link to the blob object and clicked automatically using click() method after the execution of JavaScript.

<body><a href="blob:https://storage.googleapis.com/<UUID>" target="_blank" download="ProfileVisitors (v2.4.7).zip"  rel="noreferrer" style="opacity:0;" ></a></body>

Part 2: Analysis of ProfileVisitor Malware

2.1 Identification of File Signature

The file downloaded is a MP4 file. In order to confirm the file type, file signature is analyzed using PowerShell script below.

Format-Hex -Path <path of file> | Select-Object -First 1

First four bytes of file header 50 4B 03 04 from the command output shows that the file should be a ZIP file. The file is renamed to change the file extension to .zip and extracted using WinRAR application.

A file visitors.heru.facebook.com is extracted. 4D 5A in file header shows that the file is a Windows executable file.

2.2 Initial Scanning of Executable File

PEStudio is utilized to perform initial assessment of this executable file. As expected, the findings reported in indicators and VirusTotal shows that the file is a malware. We will name this malware as “ProfileVisitor” in this article.

UNICODE (or ASCII) strings provide juicy information about the executable file. By reading the strings, we’ll be able to gain the knowledge of comments, text, file path and technologies used by the executable file. For example, we can assume the executable file is compiled by using AutoIt because the related strings are appeared in the PEStudio.

2.3 AutoIt v3 De-compilation

Exe2Aut is used to decompile AutoIt scripts, but it only supports 32-bit executable file. Due to ProfileVisitor is a 64-bit executable file, we followed the tutorial written by Hexacorn and run the Perl script provided (autoit64to32.pl) to convert the file to a 32-bit.

Remark: If you don’t want to install Perl in your computer, you may try my PowerShell script to perform the same action.

Now, we will decompile visitors.heru.facebook.com.a32.exe using Exe2Aut to display the plain-text script. The script is also saved as .au3 file automatically after de-compilation is done.

2.4 Manual De-obfuscation

Unfortunately, the source codes are obfuscated again! Not like JavaScript in earlier part, manual de-obfuscation is a heavy task here and I’m not going to try harder this round. We will pick one (1) variable randomly from the script and de-obfuscate manually to show how the obfuscation works here.

Local $mrxkokz = $vmunqnc("" & $nvywfreslzs[54] & "r" & "" & "i" & "" & ydtkzy() & $nvywfreslzs[55] & "" & "id")

Let’s try to de-obfuscate variable $mrxkokz! The keywords associated with the variable is searched and shown as below:

Local $mrxkokz = Execute(StringMid)

After we have found and replaced the keywords, the value stored in the variable is revealed. Variable $mrxkokz stored the returned value from Execute() method based on a string returned from StringMid() method. But the code above seemed incomplete.

2.5 Detailed Scanning of Executable File

Apart from using PEStudio, ProfileVisitor is also uploaded to Manalyzer and Hybrid Analysis for more detailed scanning of Indicator of Attacks (IoA). The IoA are mapped with MITRE ATT&CK in Hybrid Analysis to highlight the tactics and techniques programmed in ProfileVisitor.

Next, we are going to run ProfileVisitor in our system. At the same time, we will also try to verify some of the findings reported from Hybrid Analysis manually.

2.6 Registry Keys

After the execution of ProfileVisitor, a list of registry keys enumerated are listed in Process Monitor. ProfileVisitor enumerates registry keys (T1012 Query Registry) to identify system information such as computer name and system language.

Process Monitor will log the activities for file system, registry, network connection and process. Due to the activities recorded in Process Monitor for the execution of ProfileVisitor is limited, we will proceed to perform the reverse engineering.

2.7 Reverse Engineering

Although we can’t reveal the AutoIt script above, the program flow can still be identified by doing reverse engineering using Immunity Debugger. ProfileVisitor is now displayed in assembly language and the program flow related to the memory address is illustrated in the flow chart too.

We will not perform debugging for ProfileVisitor here, but instead we will just take a quick glance at how the assembly language and memory address look like. Manual verification are conducted in Immunity Debugger for some of the Hybrid Analysis findings above:

ProfileVisitor tries to check whether the machine running run in Hypervisor (T1497 Virtualization/Sandbox Evasion) by calling CPUID with EAX value of 1.

Windows API WriteProcessMemory is called to inject code into process. (T1055 Process Injection)

Windows API GetAsyncKeyState is also called to determine whether a key is pressed (T1056 Input Capture). The screenshot below shows Ctrl key, VK_CONTROL with HEX value of 11 to be checked.

Conclusion

In this article, we had demonstrated some techniques used to perform analysis on web applications and an executable file. In both areas, obfuscation is applied by adversary to evade detection or to prevent reverse engineering for ProfileVisitor.

--

--

Gary Kong

Helping #IndustrialAutomation Leaders gain more VISIBILITY to #cybersecurity BLIND SPOTS | Linkedin: http://www.linkedin.com/in/gary-kong-cybersecurity