Threat Research

Spoofed Saudi Purchase Order Drops GuLoader – Part 2

By James Slaughter | July 12, 2022

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.

Figure 1. Halting upon detection of a virtual environment.

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

Figure 2. Execution tree.

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.

Figure 3. Installation window.

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.

Figure 4. Script image from part one showing the title bar and label use.

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

Figure 5. Files installed in $TEMP (note, PROCEXP.exe is not deployed by this malware).

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. 

Figure 6. Registry entry created in HKCU\SOFTWARE.

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.


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. 

Figure 7. Call function as seen in IDA.

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

Figure 8. Call function as seen in the debugger.

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. 

Figure 9. CreateFileW is called to create a handle (a reference in memory within the OS) to the file “rudesbies.Par”.

Figure 10. GetFileSize is called to determine the amount of memory required to store “rudesbies.Par”when opened.

Figure 11. VirtualAllocEx is called to prepare a designated area of memory to store the contents of “rudesbies.Par”.

Figure 12. ReadFile is called to take the contents of “rudesbies.Par” and store them in memory.

Figure 13. CloseHandle asks the OS to release the handle to “rudesbies.Par”.


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.

Figure 14. By observing the memory map in the debugger, the addition of a region with the above characteristics can be seen.

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

Figure 15. Initial view of the injected 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.

Figure 16. Start of actual instruction set (0002014E in this example, still in its encoded format).

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.   

Figure 17. Compare instruction checking if the counter (edx) has reached 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.

Figure 18. XOR key.

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.

Figure 19. RDTSC instruction.

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.


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:


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.
























Network IOCs


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.