Overview

The HawkEye family, first observed in the wild as early as 2013 and later rebranded as HawkEye Reborn, has long been sold in underground forums as a ready-made tool for cybercriminals. This particular sample shows why it continues to attract attention: it is not a single-purpose program, but a combination of techniques stitched together to stay hidden and steal information effectively.

The infection chain begins with an executable (hawkeye.exe) that plays the role of a dropper. Its job is to release a second file, RegAsm.exe, which poses as a legitimate Windows utility. From there the real trick unfolds: the malware uses process hollowing, starting RegAsm.exe in a suspended state and then replacing its memory with malicious code. To normal monitoring tools, it looks like a normal Windows process running in the .NET framework — but underneath, it is carrying out the attacker’s agenda.

Once active, the malware spawns multiple additional processes called vbc.exe to handle the heavy lifting: logging keystrokes, stealing credentials, and exfiltration. This layered approach and masquerading makes it harder to spot.

The findings confirm HawkEye’s reputation as more than just a simple keylogger — it is a full-featured info-stealer that blends stealth, persistence, and data theft into one package.

---

Static Analysis

For this sample my static analysis was quite short because when I first opened the sample in ghidra, I was met with a maze of nested functions. I started from the main function, but each branch only led to more helper functions. Whenever I reached the potentially suspicious ones, they offered little to no clarity. There were no obvious hardcoded indicators — only placeholders like “Destination IP address”, “Port number” tied to variables that would later resolve at runtime. Most of the memory addresses I examined, especially those linked to critical variables, resolved to invalid or uninitialized values rather than meaningful data.

In short, static analysis provided only fragments with no coherent picture. This is a reflection of the sample’s design: it relies heavily on runtime behavior. For that reason, a shift to dynamic analysis was essential. Although the imports provided some initial clues; a lot to do with network communication, I still needed to confirm whether they were actually leveraged for malicious purposes and not just standard functionality.

Fingerprint & Threat Intel

sha256hash 94243b53eceb2662ae632d9c3e02b5b947ea56ac4ac1db3a69fc0ca3e5100816

Above we can see some of the malware’s capabilities, such as direct CPU clock access — a common anti-analysis technique used to detect if the execution environment is being manipulated. It also includes debugging checks, where it attempts to determine if it is running inside a debugger. Finally, many of its modules are designed to resolve and execute only at runtime, which makes static inspection more difficult.

Malware Families identified: AutoIt & AutInject

• AutoIt: Originally a legitimate scripting language for automating Windows GUI tasks (like clicking buttons, and simulating user input). Malware authors abuse AutoIt to create trojans that masquerade as normal GUI applications while performing malicious tasks such as credential theft.

• AutInject: Trojans that inject code into memory or other processes, appearing harmless while performing hidden malicious operations.

File

The sample is a 32-bit Windows executable that initially appears to be a graphical user interface (GUI) application. However, dynamic analysis reveals that the GUI elements are superficial, and the program does not function as a genuine user-facing application. Instead, its behavior aligns more with background tasks.

Extracted strings mostly reflected imported API functions and common Windows library calls. No hardcoded credentials, IP addresses, domains were present.

Imports

The executable makes use of several DLLs with functions that are commonly abused by malware:

• KERNEL32.dll – process manipulation, scanning for active processes, and potential process hollowing.
• WSOCK32.dll – low-level TCP/IP communications, often leveraged for C2 traffic.
• WININET.dll – higher-level HTTP/HTTPS communication, commonly abused for data exfiltration.
• ADVAPI32.dll – registry access and privilege management.
• USER32.dll – user interface hooks, which can enable keystroke logging or input monitoring.
• SHELL32.dll – execution of files and commands, persistence through COM objects, and file manipulation.
• MPR.dll – manages network shares and mapped drives, potentially abused for lateral movement.
• IPHLPAPI.dll – network configuration and troubleshooting (ICMP), potentially useful for host/network reconnaissance.

Summary

From the imports, the program appears to be capable of:

• Logging and monitoring keystrokes
• Establishing internet connectivity
• Command-and-control (C2) communication
• Privilege escalation
• Persistence
• Executing arbitrary commands/files
• File upload and download
• Network diagnostics and scanning (ICMP, TCP, UDP)
• Leveraging network shares for lateral movement
• Potential widespread infection across a network

Overall, the import profile suggests a strong focus on networking capabilities (C2 channels, diagnostics, and lateral movement) combined with surveillance and persistence mechanisms.

The Debug Data section shows references to WOW64 redirection.
This suggests the malware is designed for compatibility across both 32-bit and 64-bit systems.

---

Dynamic Analysis

For this stage, I executed the sample inside a controlled Windows analysis environment (FlareVM) to observe its runtime behavior and confirm the techniques I had identified during static analysis.

To monitor network activity, I set up INetSim on a separate REMnux machine. INetSim provides simulated internet services such as DNS, HTTP, HTTPS, SMTP, and FTP, which allowed the malware to believe it was communicating with real servers. Any network request made by the sample was redirected to INetSim, which responded with generic but valid replies (such as HTTP 200 OK). This prevented the malware from stalling if it expected responses while still giving me visibility into the services and domains it attempted to reach.

Runtime Behaviour

When I first executed the malware, it was identified as a GUI application, but no visible window appeared. To understand its behavior, I set up Procmon to monitor the malware’s system activity.

Using Procmon, I focused mainly on file creations, the paths where files were dropped, and registry queries.

We see Hawkeye creating a file known as RegAsm.exe. within the .NET framework directory. RegAsm.exe is a legitimate Microsoft .NET Framework utility used to register assemblies for COM interop, allowing .NET programs to talk to older Windows systems. There are two possibilities: malware is spawning the legitimate file or it is injecting malicious code into the regasm.exe process to mask its intentions. On its own, RegAsm.exe analysed in pestudio appeared clean with no malicious indicators.

Network Indicators Procmon itself did not show any direct network details for hawkeye.exe. However, when checking the INetSim logs, I saw that RegAsm.exe queried the URL: http:bot.whatismyipaddress to get my machines Public IP.

Suspicious winlogons Files

In Procmon, I observed the creation of several new files named winlogons.url, winlogons.exe, and winlogons.vbs.

The legitimate Windows process is called winlogon.exe (note the singular form). It normally resides in C:\Windows\System32\winlogon.exe and is a critical component of the. Its role is to handle user logon and logoff, start the user’s shell (explorer.exe), and manage secure attention events such as Ctrl+Alt+Del. Because of its importance, this executable should only ever run from the System32 folder.

In contrast, the files I observed had an extra “s” at the end (winlogons), a masquerading trick known as typosquatting to make the victim overlook it. Even more suspicious, both winlogons.exe and winlogons.vbs were created under the AppData\Roaming directory. System executables should not exist in AppData, and this location is a common hiding spot for malware due to user-level write permissions. The altered spelling combined with the abnormal location strongly suggests these are malicious artifacts rather than legitimate system files.

The third file, winlogons.url, was placed in the Startup Menu directory. This ensures it will automatically execute each time the system boots, providing persistence for the malware. A .url file in this context can act as a shortcut to launch a malicious script, executable, or even a remote payload. Examnining the contents of this url we see it points to the winlogons.exe file path.

Looking at the winlogons.vbs file, we notice that it is executed using wscript, that is used for running scripts in windows. A .vbs file is a VBScript file, which allows commands to be run directly by the operating system. wscript supports scripting languages such as VBScript and JScript, making it useful for automating tasks. When this vbs file is run it executes the winlogons.exe.

Analysis of the winlogons.exe file shows no sign of malicious operations it is just used as a loader for the main payload and in procmon it spawns up the RegAsm.exe which confirms it to be the main payload.

Spawned vbc.exe

In Procmon we also see RegAsm.exe spawning multiple processes called vbc.exe, another legitimate executable used in the .NET framework.

• vbc.exe stands for Visual Basic Compiler, part of the Microsoft .NET Framework. Normally used by developers to compile VB.NET code into executables or libraries. Malware may abuse it by dynamically compiling malicious code at runtime instead of dropping a ready-made binary.

DLL Loading Behavior
I also noticed that some DLLs are being loaded directly from the same directory as the executable instead of the trusted system paths (System32, SysWOW64).

• A technique called DLL planting.
• The malware ensures its own malicious DLLs are used in place of legitimate ones, allowing it to execute arbitrary code without needing elevated privileges or tampering with protected system directories.

Targeted Applications
The malware does not stop at process injection and DLL hijacking. It actively probes popular applications, including:

• Browsers (Chrome, Firefox, Internet Explorer, Edge) – for saved passwords, cookies, and session data.
• Email clients like Microsoft Outlook, Mozilla Thunderbird, and SeaMonkey – to harvest stored account credentials and messages.
• FTP applications such as FileZilla and CoreFTP – known targets for extracting saved site credentials, which are stored locally on the PC in configuration files or XML databases, making them directly accessible to the malware.

vbc.exe also performs multiple lookups and queries, such as:

• Interacting with DNSClient and reading TCP/IP parameters in the registry.
• Creating temporary files and folders that are quickly deleted.
• Checking for updated versions of installed software in order to harvest new data sources or bypass outdated credential stores.

Credential & History Harvesting
Beyond Windows applications, the malware also shows signs of targeting cross-platform credential storage:

• History.IE5 – legacy Internet Explorer folders containing browsing history broken into time-based subfolders.
• WebCacheV01.dat – a JET Blue database used by Internet Explorer 10 and Edge to store history, cookies, and cache in one place.
• keychain.plist – Apple macOS/iOS credential storage file. Its presence in the malware’s target list suggests an attempt to harvest credentials from Apple users, especially those who may have synced or backed up their devices to a Windows system.
• Mozilla Thunderbird/SeaMonkey profiles – both store emails, account configurations, and sometimes saved passwords that can be harvested.

Taken together, these behaviors clearly point to a credential-stealing stealer family: probing multiple applications, browsers, email clients, and FTP software, while also harvesting login data, browsing history and system credential stores for exfiltration.

Taking a look at the Chrome Login Data file, we see that it is a SQLite database. Malware often issues queries against it to extract stored login information and encrypted passwords, which are then decrypted using Windows DPAPI.

We can conclude that the multiple vbc.exe processes spawned do the heavy-lifting assigned by RegAsm.exe.

Analyzing RegAsm.exe memory dump

When we load the RegAsm.exe sample from the path indicated in Procmon into PEStudio, nothing malicious is flagged. This suggests that the executable itself is a legitimate Microsoft binary being abused to masquerade the actual payload as an anti-analysis technique.

To confirm this, we turn to Hollows Hunter and PE-sieve.

Hollows Hunter will help us determine if there is process hollowing happening.

• Process hollowing is when a legitimate process is launched in a suspended state, its memory is emptied or replaced (“hollowed out”), and malicious code is injected in its place. When the process resumes, it appears legitimate to the system, but it is actually executing the attacker’s code in memory. In this case the malware is using a legitimate microsoft binary to load and execute its payload, a technique known as LOLBin (Living Off the Land Binary).

As shown in the screenshots, Hollows Hunter flags RegAsm.exe as a process performing process hollowing:

This means the malicious payload is executing within the memory space of the legitimate RegAsm.exe. To dig deeper, we use PE-sieve to dump the suspicious memory regions and extract the malicious code.

PE-sieve gives us two dumps: RegAsm.exe and mscorwks.dll.

mscorwks.dll is a legitimate component of the .NET Framework runtime. It provides the execution engine for .NET applications — essentially the core library that manages code execution, memory, and JIT compilation. Its presence here makes sense since both RegAsm.exe and vbc.exe are .NET tools. However, the fact that PE-sieve marks it as modified suggests the malware may have tampered with it in memory. From the images below we see 19 patches applied as shown in the following memory offsets.

In short, RegAsm.exe is being hollowed, acting as the visible face of the process, while malicious code runs inside its memory space. At the same time, mscorwks.dll shows signs of tampering, suggesting the malware is also manipulating the .NET runtime environment to keep its payload running and possibly to interfere with analysis.

The memory dump shows that the executable is a .NET application whose PE headers have been modified in several ways:

• PE replaced / Entry Point (EP) modified / File Header modified / Section headers modified – these flags indicate that the original executable in memory has been altered, due to process hollowing and payload injection.

• Connected to PEB – this shows the dump reflects a live process and not just the on-disk file.

These flags together suggest that the executable running in memory is not the standard RegAsm.exe, but a hollowed process now hosting the malicious payload.

Basic Static Analysis

Analysis of the dumped executable and metadata reveals:

• URL references:

  • pomf.cat/upload.php – a file hosting service, that is likely used for exfiltration of images.
  • bot.whatismyipaddress – like we saw earlier queried every 12 minutes thereabout.

• Malware identity:

  • Real name of the application is reborn_stub.exe.
  • Evidence of form grabbing: monitoring user input on login pages such as www.google.com:443/Please log in to your Google Account and www.google.com:443/Please log in to your Gmail Account, allowing the malware to capture credentials before they are encrypted.
  • And some interesting API functions being used.

• Use of Crypt32.dll – likely leveraged for DPAPI decryption, enabling the malware to decrypt stored passwords and credentials.

DIE findings:

• Confirmed as a .NET application, obfuscated with ConfuserEx- that is used to protect .NET applications from reverse engineering.Although its now outdated.
• Language detection shows VB.NET, but its actually C#.

---

.NET Analysis

• To overcome the obfuscation i used de4dot which gives us a cleaned version allowing the code to be more readable and easier to analyze.

Overview of its Capabilities

The image above shows various variables used by the malware to manage configuration, system profiling, and runtime operations giving us a great picture of what the malware does. The .NET code resolves these at runtime to orchestrate tasks such as credential extraction, HTTP/FTP exfiltration, keylogging, webcam capture, disabling monitoring tools, and persistence mechanisms.

Multi-Channel Exfiltration

The malware uses multiple methods to send stolen data, ensuring redundancy and stealth.

HTTP:
Data is sent to an exfiltration server with a secret key for authentication.

FTP / SFTP:
It uses FTP as a simple, widely-supported transfer method, and SFTP for encrypted transfer through SSH when stealth is required. These backup channels ensure stolen data reaches the attacker even if the primary HTTP POST route is blocked or monitored.

Image Hosting:
Captured images are uploaded to public image hosts like pomf.cat, blending exfiltration with normal traffic.

Credential Theft

The malware targets multiple applications to extract stored credentials, including browsers, FTP clients, and locally stored passwords.

FileZilla:
The malware targets FileZilla by reading its main configuration files: sitemanager.xml and recentservers.xml. These files store all the connection details for saved and recently accessed FTP servers, including server addresses, ports, usernames, and passwords. By parsing these XML files, the malware can harvest the user’s FTP credentials, giving attackers direct access to any servers the victim has connected to. The passwords are base64-encoded, not encrypted thus can be easily decoded.

Browsers:
Chrome and Firefox login data, cookies, and browsing history are accessed.

The malware specifically targets Firefox’s password storage files, including key3.db, logins.json, signons.txt, signons2.txt, signons3.txt, and signons.sqlite. The key3.db file holds the encryption keys Firefox uses to protect saved passwords, while logins.json and the various signons files contain the actual stored usernames and encrypted passwords. By targeting this combination of files, the malware can access credentials across both legacy and current versions of Firefox, ensuring it captures the widest possible set of saved login information for exfiltration.

System Hooks & Monitoring

The malware uses Windows API hooks to silently monitor user activity, through WH_KEYBOARD_LL and WH_MOUSE_LL, that are installed to intercept all keystrokes and mouse clicks system-wide. This allows the malware to capture typed credentials, detect clicks on sensitive fields, and track user interactions without relying on high-frequency polling, making its monitoring stealthy and efficient.

System Reconnaissance

The malware collects extensive information about the victim's machine to identify security software, hardware, and high-value targets. This includes OS details, installed .NET frameworks, antivirus and firewall products, processor, graphics, memory, disk drives, network configuration, and user privileges.

Anti-Analysis Techniques

HawkEye Reborn implements multiple anti-analysis and evasion techniques to avoid detection and interfere with security measures. It first checks for installed antivirus products and disables them. The malware also targets critical system and monitoring tools, including System Restore (rstrui.exe), keyboard encryption software like KeyScrambler, and utilities such as HijackThis.exe, effectively blocking protections that could reveal or block its activity. Additionally, it hides itself from Task Manager, registry editors, the command prompt, and other system utilities, preventing both users and analysts from observing or interfering with its operations.

These measures, combined with obfuscation and runtime protections, make dynamic analysis and manual inspection significantly more difficult. List below shows the tools that the malware attempts to disable.

---

IOCs

• C:\Users<Username>\AppData\Roaming\winlogons\winlogons.exe
• C:\Users<Username>\AppData\Roaming\winlogons\winlogons.vbs
• C:\Users<Username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\winlogons.url
• C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe
• C:\Windows\Microsoft.NET\Framework\v2.0.50727\vbc.exe
• pomf.cat/upload.php
• bot.whatismyipaddress
• 94243b53eceb2662ae632d9c3e02b5b947ea56ac4ac1db3a69fc0ca3e5100816

---

TTPs

Tactic	Technique (MITRE ID)	Description
Execution	Process Hollowing (T1055.012)	Hollowing of RegAsm.exe to execute the .NET payload in memory.
Persistence	Registry Run Keys / Startup Folder (T1547.001)	Uses Startup folder or Run keys to maintain persistence.
Credential Access	Credentials from Web Browsers (T1555.003)	Extracts Chrome and Firefox login data.
	Credentials in Files (T1552.001)	Extracts FileZilla and CoreFTP credentials.
Discovery	System Information Discovery (T1082)	Collects hardware, OS, memory, disk, network, and security software info.
Defense Evasion	Impair Defenses (T1562)	Disables Task Manager, Registry Editor, CMD, KeyScrambler, HijackThis, and System Restore.
	Process Injection / Hooks (T1055)	Installs keyboard/mouse hooks to monitor activity stealthily.
Collection	Automated Collection (T1119)	Captures browser credentials, FTP data, and screenshots.
Exfiltration	Exfiltration Over Alternative Protocol (T1048)	FTP/SFTP with hardcoded credentials.
	Email Collection (T1114)	Sends stolen data via email.
	Application Layer Protocol (T1071.001)	Uploads images taken to image hosting (pomf.cat).

---

Tools

• REMnux
• FLARE VM
• Hollows Hunter
• PE-sieve
• Cutter
• Ghidra
• dnSpy
• Procmon
• PEStudio
• Detect It Easy (DIE)
• InetSim

---

Conclusion

HawkEye Reborn is a sophisticated .NET credential stealer that demonstrates a well-rounded threat profile. It employs process hollowing to execute stealthily, persistence mechanisms to ensure longevity on compromised hosts, and multiple exfiltration channels to guarantee delivery of stolen data.