Leprechaun – A New Malware Loader

Introduction

The Leprechaun malware loader is a nascent threat that has emerged as a potential replacement for the IcedID malware. Leprechaun is a sophisticated malware loader with capabilities that make it a serious threat.

In the current landscape, a novel malware loader has emerged, exhibiting a set of limited features. Specifically, this loader comprises three critical components:

Installbot: This component plays a crucial role in the initial infection process by installing the second-stage payload. Essentially, it acts as the gateway for subsequent malicious activities.

Fetch-command: Responsible for retrieving commands from the threat actor’s infrastructure, this component serves as the bridge between the compromised host and the attacker. These commands dictate the actions to be executed on the target system.

updateCommand: As the name suggests, this component handles task updates. It ensures that completed tasks are reported back to the threat actor, allowing for dynamic adjustments and fine-tuning of the attack.

Additionally, the command-and-control (C2) server associated with this loader was hosted at IP address 65[.]20[.]106[.]109 on port 80. Notably, this loader draws inspiration from Irish mythology, adding an intriguing layer of mystique to its origins.

Key Insights

1. Behavioral Analysis:
   • We meticulously examine Leprechaun’s behavior, observing its interactions with the system, network, and other processes.
   • We analyze its persistence mechanisms, file system modifications, and registry entries.
2. Payload Extraction:
   • The malware loader likely fetches a payload from a remote server.
   • We traces network traffic, identifies communication channels, and extracts the payload.
   • Potential payload types (e.g., ransomware, spyware, or banking Trojans).
3. Evasion Techniques:
   • Leprechaun may employ anti-analysis tricks to thwart reverse engineers.
   • We explore techniques such as anti-debugging, sandbox detection, and code obfuscation.

Now, let’s delve into the fascinating process of reverse-engineering this loader to uncover its inner workings

Technical Analysis

SHA-256: 1d0753beaabc660960bb5297f43eae38128647c2a23b02b2550646d58aff8797

Upon initiating the IDA-Freeware with the given sample and allowing the automatic analysis to complete, we arrive at the initial function. Here, it becomes evident that the function employs the LoadLibraryW method to introduce the UrlMon.dll. This particular DLL is instrumental in providing access to a suite of functions that are essential for conducting activities over the network.

Subsequently, the analysis reveals that the GetProcAddress function is utilized to ascertain the memory address of the URLDownloadToFileW API, which is exported by the previously loaded UrlMon.dll. The address obtained is then assigned to a variable aptly named URLDownloadToFileW. This particular API is designed to facilitate the downloading of content from the internet.

Moving forward, the procedure progresses by establishing a Mutex, which is designated as ‘LeprechaunHvnc’, through the invocation of the CreateMutex API. This Mutex serves as an Indicator of Compromise (IOC) and proves to be a valuable asset for malware analysts and researchers who are actively engaged in monitoring the activities of this particular malware loader.

Following the creation of the mutex, the sequence proceeds to utilize the InternetConnectW API to initiate a connection to the Command and Control (C2) server. The connection is established to the server located at the IP address 65.20.106.109, targeting port 80. The parameter dwService is set to the value of 3, which indicates an attempt to establish an HTTP connection with the C2 server.

As we delve into the subsequent function, it becomes apparent that the RegOpenKeyW API is employed to verify the existence of the subkey Software\LeprechaunHvnc within the HKEY_CURRENT_USER registry hive. This step is crucial as it determines whether the LeprechaunHvnc implant has been successfully embedded within the target machine.

Based on the result, the program bifurcates into two distinct code segments. Let’s examine them individually. The first segment, referred to as sub_4012A0, is triggered in the event that the subkey is absent, which, to put it simply, means that the LeprechaunHvnc implant has not been installed on the system yet. This particular function is tasked with the installation of the implant.

In the initial phase, the function invokes GetUserNameW to retrieve the username of the system in question. Following this, it employs IsUserAnAdmin to ascertain whether the current user possesses administrative rights or operates under standard user privileges.

The function labeled sub_401680 appears to be another subroutine within the malware’s code.

Upon examining the function in question, it becomes evident that its primary role is to ascertain the version of the Windows operating system. It accomplishes this by identifying and returning the precise OS version that is currently running on the target machine, distinguishing between server-grade systems and those intended for personal use. With this understanding established, we can now proceed to analyze the originating function that invokes this particular function.

The subsequent operation involves the utilization of the HttpOpenRequestW function to initiate a GET request. This process entails the duplication of the target URL into the v10 variable. Following this, the function is employed to retrieve content from the internet, which is then utilized to store the data pertaining to the implant.

Following that, the program proceeds to establish a new registry key within the HKEY_CURRENT_USER directory. This key is designated as “Software\LeprechaunHvnc”. Within this newly created key, it then assigns a value labeled “ID”, effectively setting up a unique identifier within the registry.

In the event that the lpString2 variable holds the string “User”—a condition determined by a prior check—the software undertakes the creation of a directory. This directory, named “WindowsecurityUpdates,” is situated within the Documents folder that belongs to the current user’s profile. Subsequently, the software transfers the current executable file into this newly minted directory, bestowing upon it the new name “windowsupdates.exe.” In addition to these actions, the software goes on to generate a subkey labeled “windowsupdates” under the HKEY_CURRENT_USER branch of the Windows registry. This marks the completion of the function sub_4012A0, which is designated to run in scenarios where the implant has not yet been installed. Our attention now shifts to the examination of another function, sub_4011F0, which is set to execute contingent upon the discovery of the registry key “Software\LeprechaunHvnc”.

The function in question performs a straightforward task: it verifies the existence of the value labeled “ID” within the registry key “Software\LeprechaunHvnc”. This check is essential to determine whether the specific identifier required by the program is already established within the system’s registry.

Advancing to the subsequent segment of the code, we observe that it employs Internet APIs to dispatch a GET request. This request is formulated using the URL encapsulated within the v15 variable. With this step completed, we are now poised to delve into a detailed analysis of the code in the ensuing section.

Picking up from where we previously paused, we had observed the execution of a GET request. In this current phase, it is apparent that the function sub_4019D0 is tasked with the retrieval of content from the internet. This content is situated on a server controlled by the Command and Control (C2) infrastructure, indicating that sub_4019D0 is integral to the malware’s ability to download directives or additional payloads from the attacker’s designated server.

Continuing with the analysis, we encounter an additional function whose responsibility encompasses the acquisition of tasks and the communication of task statuses back to the operator. This function is also charged with the execution of specific tasks as dictated by the operator, thereby playing a pivotal role in the malware’s operational cycle.

As we progress further, the code segments in question are designed to set up the path for a temporary directory. They also define the filename that will be used for the file once downloaded. Additionally, these segments involve the assignment of a function pointer to the URLDownloadToFileW function. This clearly suggests that the program’s intention is to download a file from a specified URL and store it in the designated directory path.

Upon the successful download of the implant, the program dispatches a confirmation message to the operator. This act signifies the completion of the loader’s task. With this step concluded, our reverse engineering process focused on the loader’s features reaches its end.