Search

In the eye of our CyberSOC: Campo Loader, analysis and detection perspectives

How to detect and analyze Campo Loader? Answers from our CyberSOC. 

Campo Loader, a recent campaign 

Since January 2021, our CyberSOC has noted the fairly active use of a loader(1). This loader was quickly named "Campo Loader" on the Internet because of the rather striking patterns in its URL, observed during network communications. 

Notably used to "drop" in the second stage Ursnif/Gozi, a banking trojan, these campaigns use several exciting techniques and remain quite easily detectable with adequate security solutions.  

 Very similar campaigns have also been observed since the summer of 2020 and documented by Morphisec in September.  

It seems that this loader is still used to deliver Trickbot. However, we will note some differences with our case in the format of the maldoc and the final load deployed. 

Vector of infection: maldoc

Unsurprisingly, the first vector of infection is an e-mail containing an attachment. More precisely, an Excel XLSB (Excel Spreadsheet-Binary) document. 

This type of file is quite common for maldoc because it evades most AV (Anti-Viral) engines. Even after several days of existence on VirusTotal (VT), files are still detected by less than 10 AV out of 64. 

When the file is opened, it prompts the user to activate the content, making him believe that this action will decrypt the document and display its content. 

 

The usual tools such as olevba/oledump or XLMMacroDeobfuscator are not satisfactory in terms of static analysis. So we adopt another well, more manual technique:  

By decompressing the file, we identify a spreadsheet in binary format (BIFF12) that looks interesting. Indeed, a first "Strings" on this file indicates a routine that seems quite malicious:  

At first glance, the use of the certutil.exe binary would therefore be present to decode several files' contents. Then the functions and strings "Shell32", "rundll32.exe" as well as "ShellExecuteA" indicate that the role of this file is also to execute DOS commands or even a DLL. 

We go directly to the analysis of the document via Excel. It turns out that several Excel sheets are hidden. By unmasking the four hidden sheets, the correspondence with the previously displayed strings makes it possible to link the sheet4.bin file to one of the hidden sheets. 

A second sheet will prove interesting for understanding this file. Indeed, sheet 2 is in charge of the execution of the routine via an Auto_Open. 

However, the most interesting part is still missing. The associated Excel sheet is protected. 

To bypass the protection, simply save the file in another format (e.g., Xslm). Thus binary files will be converted to XML format. Then, removing the protection is relatively easy. Indeed, a simple tag is responsible for this mechanism. By removing it, the protection of the sheet is no longer effective.

We then identify several cells likely containing encoded content, which will turn out to be a PE (Portable Executable). 

Thus, we have a good understanding of the actions of this first xslb file: 

  • Drop a. txt file containing data encoded in b64 
  • Decoding of the file + drop of a new hex file via the binary certutil.exe 
  • Decoding of the second file via certutil.exe + drop of a PE. 

We then validated our first static analysis based on a dynamic analysis by running the file in the Orange Cyberdefense sandbox: 

Three files are well dropped: 

 

C:UsersPublic11250.txt 

C:UsersPublic11250.png2 

C:UsersPublic11250.png 

 

We fall well on PE "packaged" (UPX was noted on some campaigns). This DLL is then executed via rundll32.exe. It seems to be the Campo loader.  

Thanks to an analysis of http/https queries, we noticed a GET query to this URL : 

hxxp[://]172[.]104[.]129[.]156/campo/o/o 

It redirects (307 Temporary Redirect) to : 

hxxps[://]ciudadstereo[.]com[.]ec/wp-content/plugins/wp-calculated-fields/templates/01/out[.]dll 

This DLL purpose, which we will attach to the Campo loader, is to download and execute a second DLL. 

Note that several repositories identified in similar campaigns often have open directories, allowing to identify other malicious DLLs and get an idea about the temporality of the attacks thanks to the Last-Modified field. 

Another important point related to the temporary redirection: a "campo" URL allows you to distribute many payload dynamically. Indeed, by analyzing several times the same sample, we obtained a different final DLL. 

 

Without going into too much detail in this last stage analysis, the DLL corresponds to Ursnif / Gozi, a banking Trojan. A quick sandbox analysis will allow us to identify the control servers and thus feed our information base. 

Detection prospects  

Network communications (Campo Loader) 

While analyzing many campaigns, we noticed that a pattern was coming back often enough in the URL to be used as a detection/hunting means. 

Indeed, the uri path corresponds with this regex: " ^/(?:campo)/w{1}/w{1}$ "

Here are some examples of URLs we have identified: 

hxxp://172.104.143[.]130/campo/t/t 

hxxp://178.62.19[.]66/campo/v/v 

hxxp://pipkaboss[.]xyz/campo/b/b 

Some older campaigns also seem to follow this pattern: 
^/(?:campo)/[a-zA-Z0-9]{1,2}/[a-zA-Z0-9]{1,2}$, which will also be more flexible. 

Example :
hxxp://androidflash[.]space/campo/DQ/s9 

System behaviors  

The use of "certutil.exe" to decode the first charge is quite striking and generic enough to be used as a means of detection. Moreover, this approach fits within the Att&CKMITRE matrix, with the "T1140:Deobfuscate/Decode Files or Information" technique. 

A Sigma rule is already available on the GitHub of the same project: 

https://github.com/Neo23x0/sigma/blob/master/rules/windows/process_creation/win_susp_certutil_command.yml 

This rule should be triggered by the two commands extracted from our sandbox analysis (below). While generic enough to include most of the LOLBAS/LOLBINS (Living Off The Land Binaries and Scripts) related to this Microsoft binary. 

 

Several approaches can also be taken to DLL execution via "rundll32.exe".  

The first one being the detection of DLL execution passing a . png file with its extension. This technique is more and more used and can be approached using the "T1036: Masquerading" and "T1218.011: Signed Binary Proxy Execution: Rundll32/" techniques. 

The last detection method could be done via the process tree. By resuming the execution of the campaign in its entirety, we note a rather striking process tree from EXCEL.EXE: 

EXCEL.EXE > rundll32.exe > rundll32.exe 

Conclusion 

Analysis of anomalies in parent/child process relationships is very efficient, even when only considering the child processes in Excel. Here is a Sigma rule that summarizes how it works: 

https://github.com/Neo23x0/sigma/blob/master/rules/windows/process_creation/win_office_shell.yml 

IOCs and MITRE ATT&CK references 

Source: Orange Cyberdefense 

To download the IOCs and the MITRE ATT&CK references, click here.  

To discover our SOC and CyberSOC offers, click here  

(1)Loader: A loader is a malware program responsible for executing a malicious load on the target system. This second load can be remote (accessible from an IP/URL) or directly included in the loader. The purpose of a loader is to propose methods for evading and targeting users (encryption, memory injection, anti-vm, anti-sandbox, geographical analysis, system profiling, etc.).  

Incident Response Hotline

Facing cyber incidents right now?

Contact our 24/7/365 world wide service incident response hotline.