What We Do
How We Do
Apply to become an e3 ecosystem partner with eSentire, the Authority in Managed Detection and Response.
Login to the Partner Portal for resources and content for current partners.
Get Started

NetWire RAT: The Stealthy Invasion via Frenchy Shellcode

BY eSentire Threat Response Unit (TRU)

November 1, 2023 | 6 MINS READ

Want to learn more on how to achieve Cyber Resilience?


Adversaries don’t work 9-5 and neither do we. At eSentire, our 24/7 SOCs are staffed with Elite Threat Hunters and Cyber Analysts who hunt, investigate, contain and respond to threats within minutes.

We have discovered some of the most dangerous threats and nation state attacks in our space – including the Kaseya MSP breach and the more_eggs malware.

Our Security Operations Centers are supported with Threat Intelligence, Tactical Threat Response and Advanced Threat Analytics driven by our Threat Response Unit – the TRU team.

In TRU Positives, eSentire’s Threat Response Unit (TRU) provides a summary of a recent threat investigation. We outline how we responded to the confirmed threat and what recommendations we have going forward.

Here’s the latest from our TRU Team…

What did we find?

In late September 2023, the eSentire Threat Response Unit (TRU) observed and prevented an infection by the NetWire RAT. NetWire was a publicly available remote administration tool with password-stealing and keylogging capabilities that first emerged in the wild in 2012.

In March 2023, the FBI shut down NetWire and arrested Mario Zanko, who resided in Croatia, and was responsible for distributing the RAT. Zanko was also responsible for operating the NetWire website where sales took place (Figure 1).

Figure 1: Website that used to sell NetWire and now seized by FBI

We assess with high confidence that the primary source of infection was a drive-by download. The user visited a website offering the Microsoft Office 2019 Professional Plus installer, along with an activator program named "Office 2013-2019 C2R Install".

The downloaded RAR archive, labeled “x64 v16.0.12130.20272_Multi.rar”, contained a binary file named OInstall.exe (MD5: 38be94769e4f59d9a90e551e505c2e07). Unfortunately, we could not identify the exact website or source from which the user obtained the archive.

The initial malicious file contained an AutoIT script that, upon execution and decryption, drops the OInstall.exe (Office 2013-2019 C2R Install) (MD5: b326fc82fb91811c223965d0d63c7a42) and install.exe (MD5: 6037361243f8c390326debbea5b85ac2) file under the %TEMP% folder, which is a .NET binary that we will be analyzing in this article.

Upon decompiling/detokenizing the AutoIt script, we got an encrypted file (Figure 2). The detokenized AutoIt script is decrypted using XOR operations, as illustrated in Figure 3. Notably, the key for each decryption is derived from the last byte of the preceding encrypted string.

Figure 2: Detokenized AutoIt script with decrypted data
Figure 3: XOR decryption function

The decrypted script also contains two embedded base64-encoded binaries that are mentioned previously in this article – OInstall.exe and install.exe.

Core Payload – install.exe

We will look at the core payload, install.exe. Immediately after loading the binary in dnSpy, we can see the resource file that might contain some encrypted data based on the size (121278 bytes). Next, we will try to look for the function that might be responsible for locating and loading the resource section.

The highlighted function in Figure 4 looks quite interesting. It extracts every 5th character from the obfuscated string (“aL0mTs;1lUmnUrgzBFN7:NS^B/R\\pm/qfg^(:Vrj??O<g<E8X@ggHKVujPsXi=VUnd]>7j>90\\N[D=JH0]7Wl-:`lE9uMU:a@J2Q-l>Q^f04<0AHL^E-V9vZFw3sb]r7NV{d?r@3cwYh2w:[5}efGX)uVTg/2Vik(Pt<<?PJYe<jusjs;vGKiloHKzWpoAefJgL>\\`S>[P6ih0jMH\\-[pDi9lVLy]?9u=+=NCY)5tP6(\\<9:/ReJ5(<XZO?Weia<[6O?fwh<RleE01am@cogvA0Nsf:F6><Gm`[YU`Ra^[wy-U@8nz0`O<AeHAu-ndREZeKuQ0iH2`-uVs?9_XLA]BdJe*9;N6)e9Km)5qkn?2KfC”) to recreate the original string.

Figure 4: Function that contains the obfuscated string

We can recreate the deobfuscation function as shown in Figure 5 and apply our obfuscated string.

Figure 5: Function responsible for deobfuscating the string and the reproduced code

As a result, we receive the string “asmz://(?<guid>[0-9a-fA-F]{32})/(?<size>[0-9]+)(/(?<flags>[a-zA-Z0-9]*))?”. This string pattern is a regular expression that describes a specific string format and can extract parts of it. Let's break down what this pattern is looking for:

The requirements match with the name of our resource file within the install.exe binary “asmz://87aec78c4c6931fe7cdf575766b54ea2/138240/z‎”, where “87aec78c4c6931fe7cdf575766b54ea2” is the GUID capture group, “138240” is the size and “z’ is the flags.

The resource file is then decompressed with DeflateStream. This is a stream class provided by .NET to handle the deflate compression algorithm. Upon decompressing the resource file, we get a DLL file (MD5: 797b3318a7323b73df2bdc910f6ce92f). The method “ResourceDecrypt” is responsible for retrieving the resource file within the DLL binary and then decrypting the file AES.

Figure 6: Method responsible for retrieving the resource file and decrypting it with AES

We receive another executable upon the AES decryption (MD5: a60238d3d7d3d6d90bae440cc4ff25ea). We will proceed with renaming the method names to simplify the analysis.


The “antivm” method checks the system's registry for indications that it's running within a virtual machine (VM). It accesses the BIOS description in the registry to retrieve the system's product name and manufacturer, accesses another system-related registry key to obtain the BIOS version, then checks if any of the retrieved values contain "VM", "VMware", or "VBOX".

If the values contain the mentioned strings, the binary terminates the current running process (Figure 7).

Figure 7: AntiVM function


The method “persistence” is responsible for setting up the persistence mechanism on the infected machine by creating a folder named “apppatch” under %APPDATA%, the binary copies itself into the created folder under “mtstocom.exe” and adds itself to the “Load” registry value to load the malicious binary when the user logs on under the registry path “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows” as demonstrated in Figure 8.

Figure 8: Persistence method

UAC Bypass

The binary determines the version of the operating system. If the version is 7, it performs the UAC bypass using Eventvwr.exe; if it's 10, it uses Fodhelper.exe for the bypass, as shown in Figure 9.

Figure 9: UAC Bypass function

Frenchy Shellcode

Finally, it decrypts one of the resource files using AES and then decompresses it, which leads us to the final payload – NetWire RAT (MD5: 2da7b1cf405f791165e42ce5a3efad97), the second decrypted file is a Frenchy Shellcode (frenchy_shellcode_002 – based on the mutex, MD5: abdb5f121849f3f3718768d37abe0173) that is responsible for process hollowing into RegAsm.exe process.

The shellcode function in Figure 10 extracts a list of functions from the Process Environment Block (PEB). It then dynamically resolves the addresses of the NtOpenSection and NtMapViewOfSection functions using the list and a function labeled as “mw_resolve_fnc”. “mw_resolve_fnc” is an export address table (EAT) lookup function.

Given the base address of a module (DLL) and the name of a function, it will locate and return the address of that function from the module's export table.

Figure 10: The code responsible for resolving the functions dynamically


NetWire encrypts its configuration with RC4 as shown in Figure 11.

Figure 11: Encrypted data and RC4 decryption function

The extracted configuration:

C2 list: “qayshaija.ddns[.]net:1515”
Password: "Password",
Host ID: "HostId-%Rand%",
Mutex: "-",
Install Path: "-",
Startup Name: "-",
ActiveX Key: "-",
KeyLog Directory: "%AppData%\\Logs\\"

What did we do?

What can you learn from this TRU Positive?

Recommendations from our Threat Response Unit (TRU) Team:

Indicators of Compromise

Name Indicators
OInstall.exe 38be94769e4f59d9a90e551e505c2e07
install.exe 6037361243f8c390326debbea5b85ac2
DLL binary (second payload) 797b3318a7323b73df2bdc910f6ce92f
Executable binary (third payload) a60238d3d7d3d6d90bae440cc4ff25ea
NetWire RAT 2da7b1cf405f791165e42ce5a3efad97
Frenchy Shellcode abdb5f121849f3f3718768d37abe0173
NetWire C2 qayshaija.ddns[.]net:1515
eSentire Threat Response Unit (TRU)
eSentire Threat Response Unit (TRU)

The eSentire Threat Response Unit (TRU) is an industry-leading threat research team committed to helping your organization become more resilient. TRU is an elite team of threat hunters and researchers that supports our 24/7 Security Operations Centers (SOCs), builds threat detection models across the eSentire XDR Cloud Platform, and works as an extension of your security team to continuously improve our Managed Detection and Response service. By providing complete visibility across your attack surface and performing global threat sweeps and proactive hypothesis-driven threat hunts augmented by original threat research, we are laser-focused on defending your organization against known and unknown threats.

Read the Latest from eSentire