Spoofed Saudi Purchase Order Drops GuLoader – Part 2

In part one of this blog, FortiGuard Labs examined a recently discovered e-mail delivered to a coffee company in Ukraine that was seemingly sent by an oil provider in Saudi Arabia. Purporting to contain an attached purchase order, the image of a PDF file was actually a link to an ISO file hosted in the cloud that contained an executable for GuLoader. What makes this case interesting is that this executable uses NSIS (Nullsoft Scriptable Install System) to deploy itself.

GuLoader (also known as CloudEye and vbdropper) dates to at least 2019 and is generally used to deploy other malware variants such as Agent Tesla, Formbook, and Lokibot.

In this second part of the series, I will showcase a dynamic analysis of the main file, PO#23754-1.exe, as well as investigate the shellcode file “rudesbies.Par”. It will also highlight some of the defences it puts in place to hinder analysis.

Affected Platforms: Windows
Impacted Users: Windows users
Impact: Potential to deploy additional malware for additional purposes
Severity Level: Medium

PO#23754-1.exe dynamic analysis

This sample has a basic level of awareness of its surroundings. If it is executed in a virtual environment that has an obvious artefact (e.g., VirtualBox Guest Additions Tray), it will halt immediately.

As the file is executed from inside a mounted ISO file, the execution path will flow from Explorer.

By deploying from within a container such as an ISO, it is often possible to bypass MOTW (Mark-of-the-Web) controls that would stop files downloaded from the internet from executing. 

Since this is a NSIS file, anyone viewing the screen at the time of execution will see also see a progress window as files are installed.

The label use, as shown in the NSIS script from part one of the blog, now becomes apparent when looking at the title bar for the window as well as the lower centre.

As was suspected during static analysis, all identified files have been placed into the “Temp” directory of the active user account.

A unique directory name is created (always beginning with “ns”) to store “System.dll”. A temp file that also is uniquely named (and again always prefixed with “ns”) is used in the NSIS deployment process. 

In part one of the blog, a registry key was highlighted in the NSIS script. Figure 6 shows this when implemented on a victim system. It does not appear, however, that this is referenced later by the malware, nor does it appear that a file named “PARALLELIZING.log” is ever committed to disk.  It is possible that this is a remnant of the testing phase of the NSIS file that was no longer needed for the active campaign.

System.dll

As mentioned earlier, “System.dll” is dropped into a unique directory. On its own, “System.dll” is a non-malicious file. However, the NSIS script will effectively use this DLL to proxy Windows API calls to “kernel32.dll”. This is done to read the file “rudesbies.Par” and inject its contents into the already running NSIS process. Doing things in this fashion makes it more difficult to trace where the origin of the call is coming from, thereby making it appear to be legitimate. 

As can be seen in Figure 7, the “Call” function is used to actually make the API call to “kernel32.dll” 

Despite a different offset, i.e., the last four bytes of the address in Figure 7 (1817), it can be seen in Figure 8 when “Call” is called by the code executing in the debugger.

In all, five calls are made through “System.dll” to “kernel32.dll”. These read “rudesbies.Par” and then allocate appropriate space in memory within the running executable. The series of five figures shown below demonstrate the entire journey to make this happen. Note the spelling of kernel as “KERNel”. Referring again back to part one, this is identical to the representation in the NSIS script. 

Injection

Once rudesbies.Par is successfully read, it must then be injected back into the running NSIS process. This done into a random region of memory within the NSIS process.

Viewing that region of memory initially shows what looks to be a very large number of “cmp” operations. 

Shellcode

The instructions shown in Figure 15 are junk code and don’t actually do anything. Regardless of the memory offset used to load the shellcode, the first set of meaningful instructions start at 014E.

From this point, the code will attempt to decode the next 17208 bytes of “rudesbies.Par”. It does this by setting a counter and then incrementing by four bytes while transiting a loop. Each time it goes through the loop, four bytes are added to the counter until it reaches 17208.   

While that is occurring every four bytes, an instruction is XOR’d using the key 919E1E2E. Due to endian-ness, this is actually reversed and represented as 2E1E9E91.

Once this has all been completed, further impediments to analysis have been added to hinder review by analysts such as periodic RDTSC (Read Time-Stamp Counter) instructions. Due to the time difference it takes to step through instructions manually versus when running normally, this will create a break in the normal flow of the program.

FortiGuard Labs was unfortunately unable to retrieve the final payload that was to have been dropped by this GuLoader sample. As mentioned earlier, GuLoader has been known to drop different types of malware, such as Agent Tesla, Formbook, and Lokibot.

Conclusion

Despite being a dropper, this sample shows the advantages of when malware developers increase the number of defences against analysis in their code. It slows down analysts attempting to share the details of a campaign, thereby maximizing the amount of time a malicious actor can keep their infrastructure up before becoming known and then compromised or taken down.

GuLoader can be adapted for delivery in different campaigns with different malware types. It is an interesting and active threat that will likely continue for some time to come.

Fortinet Protections

The GuLoader sample mentioned in this blog is detected by the following (AV) signature:

NSIS/Injector.AOW!tr

Fortinet customers are protected from this malware through FortiGuard’s Antivirus, and CDR (content disarm and reconstruction) services and FortiMail, FortiClient, and FortiEDR solutions. 

Due to the ease of disruption, damage to daily operations, potential impact to the reputation of an organization, and the unwanted destruction or release of personally identifiable information (PII), etc., it is important to keep all AV and IPS signatures up to date.

Fortinet also has multiple solutions designed to help train users to understand and detect phishing threats:

The FortiPhish Phishing Simulation Service uses real-world simulations to help organizations test user awareness and vigilance to phishing threats and to train and reinforce proper practices when users encounter targeted phishing attacks.

In addition, we suggest that organizations also have their end users go through our FREE NSE training: NSE 1 – Information Security Awareness. It includes a module on Internet threats that is designed to help end users learn how to identify and protect themselves from various types of phishing attacks.

IOCs

Network IOCs

 bounceclick[.]live/VVB/COrg_RYGGqN229.binb

Thanks to Fred Gutierrez who helped contribute to this blog. 

Learn more about Fortinet’s FortiGuard Labs threat research and intelligence organization and the FortiGuard Security Subscriptions and Services portfolio.