Retour 
Netskope Threat Research Labs discovered an interesting drive-by download attack in Google. The threat actor involved in this attack initially deployed a Banking Trojan using the file cabinets template in Google sites as a delivery vehicle. The malware dubbed “LoadPCBanker” used SQL as an exfiltration channel to send the compromised victim data to the server.
There are two aspects of this attack that are noteworthy:
- First, users place an implicit trust to vendors like Google. As a result, they are more likely to fall victim to an attack launched from within a Google service.
- Second, whereas other services like Gmail block some malicious file uploads, Google File Cabinet does not appear to have any such protections.
This post describes our discovery and analysis of the attack and the malware payload. We will also conclude with some recommendations to help protect and remediate such threats.
Netskope Detection
Netskope Advanced Threat Protection detects the malware associated with this attack as Win32.LoadPCBanker.Gen.
Netskope customers can also create a policy to generically block all uploads and downloads from Google sites as shown in Figure 1.
Disclosure
Netskope reported the associated Google sites hosting malware using the report abuse option to Google on 12 April 2019.
Malware hosted Google Sites
We originally found the malware being delivered from the following Google Sites URL:https://sites.google[.]com/site/detailsreservations/Reserva-Manoel_pdf.rar?attredirects=0&d=1.
The files are being hosted using the classic Google Sites. Using the ‘Recent site activity’ option on the site containing the file, we found out there were two files resident at the top level, as shown in Figure 2.
The threat actor used classic Google sites to create a website, then used the file cabinet template to upload the payload, and finally sent the resulting URL to the potential targets. A visual depiction of this process is shown in Figure 3.
Attack Kill chain
The depiction of the attack kill chain of the LoadPCBanker malware is shown in Figure 4. It begins with a first-stage parent downloader, which downloads the next stage payloads from a file hosting website. The next stage payloads collect screenshots, clipboard data, and keystrokes from the victim. Finally, it uses SQL, an exfiltration channel to send the victim data to the server.
Analysis of LoadPCBanker
The downloaded RAR archive “Reserva-Manoel_pdf.rar” contained an executable ”PDF Reservations Details MANOEL CARVALHO hospedagem familiar detalhes PDF.exe”. The filename translates to “PDF Reservations Details MANOEL CARVALHO guest house details PDF.exe” from Portuguese to English, indicating to be likely targeting Brazil or Portuguese speaking users.
The malicious executable compiled in Delphi uses a PDF document icon disguise as shown in Figure 5.
This sample primarily works as a downloader to download the next stage payloads. On execution, a hidden folder named ‘clientpc’ is created in the C drive. Then, the next-stage payloads libmySQL50.DLL, otlook.exe, and cliente.dll are downloaded to this same location from a file hosting website, kinghost[.]net, using the URL drivemailcompartilhamentoanexos[.]kinghost.net, as shown in Figure 6.
While Otlook.exe and cliente.dll are malicious files, libmySQL50.DL is a library of mysql. The threat actor used libmySQL50.DLL as a to send the victim data to the server. Next, otlook.exe is executed. The downloader deletes all its download URLs from the system’s WinINet cache as shown in Figure 7.
Once this is done, the malware further connects to the URL hosted in zzz.com[.]ua to notify the victim has been infected with the malware, as shown in Figure 8.
Analysis of the Next Stage Payloads
Otlook.exe is a delphi compiled executable that loads libmySQL50.DLL and cliente.dll during execution, as shown in Figure 9.
Otlook.exe functions primarily as spyware, doing the following:
- Records screenshots and saves as saves the file name as screen<number>.jpg in the location “C:\clientpc” (using API’s GetDesktopWindow, GetDC)
- Records the clipboard data in the location “C:\clientpc\capctrl.txt” (using the API GetClipboardData)
- Records all the keystrokes in the location “C:\clientpc\relatorio.log” (using the API GetAsyncKeyState)
- Similar to the first stage downloader, delets all its download URLs from the WinINet cache.
Otlook.exe downloads a file named “dblog.log” from the URL http://www.albumdepremios.com[.]br/hostmeu with the User-Agent: Otlook as shown in Figure 10.
It contains the external SQL database server credentials in an encoded format. This is decoded in the decryption loop present in otlook.exe as shown in Figure 11.
The decoded values contain the credentials of the server,user_name, password, port, and database to exfiltrate the victim details to the SQL server as shown in Figure 12.
An export of the SQL C2 exfiltration is shown in Figure 13.
Otlook.exe also downloaded two cfg files named cliente.cfg and filtro.cfg from the URL http://www.albumdepremios[.]com.br/heisen to the location “C:\clientpc”. The cfg files contained the configuration details like DNS, port, log, ID and filter for the connection. We also observed that the attacker constantly rotated the database credentials by updating the dblog.log file.
The SQL database contained a database and two tables in the server as shown in Figure 14.
During our analysis, we identified that the threat actor was particularly interested in surveilling a specific set of machines and capturing screenshots of the victims’ machines that were compromised from this attack. We derived this because we noticed a lot of infected machine responses, but only a few were being actively surveilled. At the time of writing, the threat actor was actively monitoring 20 infected hosts.
Similar strains – Ties and connections
Using VirusTotal Passive DNS, we were able to identify similar samples communicating to the C2 – albumdepremios[.]com.br, as shown in Figure 15.
We believe that similar malware has been around since early 2014, and this latest wave of attacks has been ongoing since February 2019, based on the passive DNS results and our in-house threat intelligence framework. It is possible that the same threat actor has been involved in these attacks, or the source code has been reused by multiple actors over this period.
As we continued our analysis on the similar strains, ties, and connections, we identified another Google sites URL created by the threat actor. The site activity is shown in Figure 16.