In cybersecurity, the adage “what’s old is new” continues to hold true as attackers resurface longstanding techniques or repurpose them with new twists and adaptations. The popularization of Living Off the Land Binaries (LOLBins) — legitimate, Windows-native tools commonly abused for malicious uses — is a great example of this. Many of these methods have existed for decades yet remain effective in the modern security landscape, especially as many organizations are still ill-advised and unequipped to combat them. Being able to spot Mustang Panda’s use of MAVInject in recent campaigns is very important for security teams.

The LOLBin star for today’s blog is Microsoft Application Virtualization Injector (MAVInject) which is (un)surprisingly still kicking since its first buzz around 2017. We’ll cover its particular role in a novel attack chain reported by Trend Micro researchers whereby the threat group Mustang Panda combines legitimate components with malicious payloads to reduce likelihood of detection.

In this blog we’ll emulate the infection chain described in the report and analyze the activity it produces in Graylog. Throughout and at the end of the post, we share threat hunting and detection approaches that you can apply in your own environments.

Attack Overview

The attack likely starts with a spear-phishing email attachment. When executed by the victim, IRSetup.exe is used to drop multiple files to the system. In the case of the Trend Micro report, the files were placed in a newly created C:\ProgramData\session directory.

The report’s execution flow diagram seen below shows how the kill chain progresses from the initial dropper all the way to payload execution, ultimately leading to Command and Control (C2) communication to the attacker-controlled server www[.]militarytc[.]com over port 443.

Key elements

• exe opens a decoy PDF to distract the victim while the malicious payload is deployed in the background.
• The legitimate Electronic Arts (EA) application OriginLegacyCLI.exe is executed to sideload EACore.dll, which contains the actual malicious functionality. The DLL is a modified version of Mustang Panda’s TONESHELL backdoor.
• The malware checks if ESET security software is running on the host by looking for its associated processes ekrn.exe or egui.exe.
• If present, it uses MAVInject to inject itself into the legitimate Windows application waitfor.exe and triggers code that establishes the connection to its C2 server.
• Otherwise, MAVInject is skipped and the code is directly injected into waitfor.

“DLL? Sideloading?? Injection???”, one might be thinking as they read through that. Not to worry, these concepts will be demystified as we emulate the chain ourselves later.

It seems that Mustang Panda might’ve found this use of MAVInject to fly under the radar of ESET software specifically, though that remains unclear – ESET since responded that this technique is not a bypass to its protections.

Persistence

 While researching this attack, we came across a report on Any.Run that exhibits a similar kill chain. It includes a persistence mechanism via registry Run key that wasn’t mentioned in the original report.

This mechanism enables the malware to maintain its foothold on the compromised host. Even if the system is restarted, it will be re-infected once the user logs in.

Emulating the Adversary

Lab setup

To emulate and analyze the attack, we’ve set up a lab environment with Graylog Enterprise 6.1.7 and Illuminate Windows Security Event Logs Content Pack enabled to parse, normalize and enrich the logs. Graylog Security is also included to integrate Sigma rule detections.

A Windows Server 2022 system will serve as our “victim host”. Its configuration sends System, Security, PowerShell/Operational, and Defender event logs via Graylog Sidecar to our Graylog instance. Auditing is explicitly enabled for process execution (command line included), registry changes in commonly abused locations, and file system changes in the ProgramData folder.

We’ve built custom binaries — programs, that is — that closely mimic the malware’s core functionality based on Trend Micro’s analysis, all bundled into a custom IRSetup dropper. To trigger the Mavinject flow, we placed “dummy” programs that mimic ESET running processes. This works because the malware only checks for the process names.

Detonating the mimic malware

Aaaaand, detonate💥!

We see that the mimic dropper wrote files to the ProgramData\session folder and auto-launched the decoy PDF. Waitfor.exe is also running in Task Manager.

It looks like the infection chain of our mimic malware followed through. Let’s hop over to Graylog to get a detailed view of the activity that occurred.

IRSetup dropper

 IRSetup.exe itself isn’t malware — it’s created using a legitimate Windows software installer builder named Setup Factory, in this case abused to drop and execute the malicious files. Attackers favor legitimate tools to blend into environments and make it harder for detection logic to separate malicious from benign activity. It also saves them the trouble of implementing these components themselves.

While we don’t have the actual Setup Factory installer, our mimic dropper does replicate its main function. In the screenshot below we see activity marking the beginning of the infection, sorted by ascending time (read top to bottom):

1. Event ID 4688 (process creation) shows IRSetup.exe being executed
2. This is followed by file system events where the installer writes the PDF, EACore.dll, and OriginLegacyCLI.exe files to C:\ProgramData\session
3. The installer proceeds to execute OriginLegacyCLI.exe

This is where the fun begins (props if you know that reference). Shown below is the rest of the infection chain following OriginLegacyCLI.exe execution. We’ll break down each part and write some threat hunting queries along the way.

EACore DLL sideloading

OriginLegacyCLI.exe gets executed in block 1. We don’t have the visibility from these Windows events to see EACore.dll getting sideloaded as a result (Sysmon would help with that), but we can infer that it happened based on the activity following.

So, what is DLL sideloading? Before that even, what’s a DLL?

A DLL, or Dynamic Link Library, is a shared file used by Windows programs to perform certain functions without having to include all the necessary code within the program itself. Developers load and import ready-made code libraries from DLLs into their applications so they don’t have to reinvent functionality that’s already been written.

DLL sideloading is a technique where a legitimate application unknowingly loads a malicious DLL instead of the intended one, allowing attackers to execute their code while appearing legitimate. It’s similar to DLL hijacking, the difference being that the attacker places the trojanized DLL alongside the target application EXE and directly invokes the application to proxy execute the DLL.

In the Mustang Panda infection chain, the attacker positions the legitimate, signed 3rd-party application OriginLegacyCLI.exe and a tampered EACore.dll in the same directory. When OriginLegacyCLI.exe runs, it follows a search order to look for the DLL it needs by name, in this case “EACore.dll”, and load it.

DLLs in the same folder as the application take priority in the search order hierarchy. OriginLegacyCLI finds that the backdoored EACore.dll matches its search first, and loads it unaware that it’s been swapped. Upon load or import of functionality, the malicious code housed in the DLL gets executed.

This method is highly effective because it exploits trust in legitimate applications and is difficult to identify, helping malware evade security detections. For this reason it’s often a preferred execution method by Red Teams and threat actors alike.

ESET check and RegSvr32

At this point the malicious code in EACore is running under the mask of OriginLegacyCLI, and we move to block 2.

According to the Trend Micro report, the malware checks for ESET running on the system and, if present, “registers EACore.dll using regsvr32.exe to execute the DLLRegisterServer function”, seen in the command line:

“C:\Windows\System32\regsvr32.exe” /s “C:\ProgramData\session\EACore.dll”

Put simply, RegSvr32 is a Windows utility that can be abused to proxy execute malicious code. Instead of EACore invoking its own function, it takes the long way of having RegSvr32 do it. The result is the start of the next infection phase now under the parent process of regsvr32.exe.

Again, we see the use of a built-in Windows utility in an attempt to thwart detections.

DLL injection via MAVInject

Now for what we’ve all been waiting for. If you’re here, you’ve probably weathered the technical hailstorm that was the last few sections, and to that I give a swift salute.

We’re now in block 4, where we see waitfor.exe process creation followed by DLL injection into that process using MAVInject.

So, DLL injection.

In this context, DLL injection is a method of executing malicious code inside of another, often legitimate, running process. It takes a DLL and forces the separate process to load and execute it, enabling malicious activity under the guise of that process.

As we see above, the malware first launches the legitimate Windows program waitfor.exe with the intent to inject into it.

“C:\Windows\SysWOW64\waitfor.exe” “Event19030087251541”

It captures the process ID (PID) 6896 of the newly spawned waitfor.exe to be referenced during injection.

It then runs Mavinject.exe to inject itself, EACore.dll, into waitfor.exe referencing its PID 6896.

“C:\Windows\SysWOW64\mavinject.exe” 6896 /INJECTRUNNING “C:\ProgramData\session\EACore.dll”

Once EACore.dll is injected into waitfor.exe, it establishes a network connection to the C2 server for control over the compromised system.

That’s the gist. If you’re here for the details, it triggers an execution flow to decrypt, allocate and execute shellcode that opens a reverse shell to the C2 and sends information about the victim host. The C2 server communicates with the host using a custom command protocol.

We can hunt for MAVInject DLL injection using the following query in Graylog.

process_command_line:/.* \/INJECTRUNNING .*/

Looking for waitfor.exe spawned under regsvr32.exe is another useful query.

process_name:waitfor.exe AND process_parent_name:regsvr32.exe

Decoy PDF

As a little bonus, our mimic dropper also opens the decoy PDF.

Run key persistence

Going back to the start of this blog post, we identified that the malware might also set autostart persistence in the registry to survive reboots.

In block 3 above, there are registry modification events that show the malware creating a Run key under `HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run`.

Viewing the details of Event ID 4657 (registry value was modified) in Graylog, we see that the key name masquerades as Microsoft Edge Auto Launch. It’s set to execute OriginLegacyCLI.exe (and therefore the EACore.dll TONESHELL backdoor) upon user logon in order to re-infect the system.

We can hunt for registry HKCU\Run key persistence with event IDs 4657 or 4663. Here is an example query using ID 4663 to uncover registry Run key writes from OriginLegacyCLI.exe (Bear in mind that this won’t catch instances where OriginLegacyCLI is renamed or replaced, remove the process_name condition to cover those).

event_code:4663 AND process_name:OriginLegacyCLI.exe AND file_path:/.*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run/

Detections

We recommend the following SigmaHQ rules to detect this attack chain and similar events:

• Mavinject Inject DLL Into Running Process
• Potentially Suspicious Child Process Of Regsvr32 (waitfor.exe added)

We can easily add these rules with Graylog Security. Add the SigmaHQ repository and import all, then search for and enable the rules.

For “Potentially Suspicious Child Process of Regsvr32” you will have to add waitfor.exe to the Image list, like so.

Indicators

These indicators will primarily be useful for hunting past intrusions that went unnoticed. They have little effectiveness in detecting future intrusions by Mustang Panda as threat actors tend to burn or alter their tools and infrastructure between campaigns.

OriginLegacyCLI.exe (legitimate application targeted for sideloading) SHA-256:
91357E6E5A8DB3D9D3B23CE4368425A148683287D917D927EE2BB6E835C87EBE

EACore.dll (modified TONESHELL backdoor) SHA-256:
DC673D59A6A9DF3D02E83FD03AF80E117BEA20954602AE416540870B1B3D13C4

Registry HKCU/Run key (persistence mechanism) Name:
MicrosoftEdgeAutoLaunch_DAC5ED36BBAC4D19045B4BAFA91EF8729

Value:
“c:\programdata\session\OriginLegacyCLI.exe”

www[.]militarytc[.]com:443 (C2 server hostname and port)

193[.]56[.]255[.]179 (C2 server IP address)

In general, look for Mavinject.exe execution and outbound network connections from unexpected Windows programs. Ensure that execution of Potentially Unwanted Programs (PUPs) and unauthorized software is tracked in your environment.

Graylog Detections

Graylog has provided the Sigma Rules and Indicators here to share threat detection intelligence with those not running Graylog Security. Note that Graylog Security customers receive a content feed including Sigma Rules, Anomaly Detectors, Dashboards, and other content to meet various security use cases.

To learn how Graylog can help you improve your security posture, contact us today or watch a demo.

Graylog has always been associated with log management, metrics, SIEM and security monitoring—but it’s also a great tool for creative, low-cost experiments in a home lab. I wanted to use it for real-world sensor data, so I built a DIY temperature and humidity monitor using an ESP-WROOM-32 development board and a DHT22 sensor. This project shows you how to create a lightweight API endpoint on the ESP32, poll it regularly using Graylog’s HTTP API input, and visualize the results in a live dashboard.

I wanted a way to integrate temperature and humidity status into Graylog and send alerts for temperature and low humidity for my equipment room.  Really, my guitar room! I wanted to ensure the humidity was not going below a certain level, potentially causing damage to my prized guitars.

Hardware Used

• ESP-WROOM-32 (ESP32) development board
• DHT22 Digital Temperature & Humidity Sensor
• A few jumper wires
• A WiFi Network for it to connect to
• A Graylog Instance on the same network
• An HTTP API Input configured on Graylog

DHT22 Sensor

The DHT22 data pin is connected to GPIO4. Power comes from the ESP32’s 3.3V rail.

Wiring It Up

The Arduino Code

Arduino is a great way to experiment with many sensors and modules. With most ESP32 boards having WiFi, Bluetooth and a very large community you can almost do anything. You will require the Arduino IED on Windows or Linux to load the code onto an ESP32 Module.  There many aftermarket ESP32 boards so finding the correct board in the IDE can be tricky.  A little trial and error might be necessary.

How This Setup Works

The ESP32 hosts a web server on port 80. When a GET request is sent to “http://ipaddress/sensor”, it responds with the current temperature (in both Celsius and Fahrenheit) and humidity in JSON format. I used the AsyncWebServer, DHT, and ArduinoJson libraries.

Here’s the code running on the ESP32:

#include <WiFi.h>
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>
#include <DHT.h>
#include <ArduinoJson.h>

// http://<ESP32_IP>/sensor (how to poll the data)

// WiFi credentials
const char* ssid = "ssidname";
const char* password = "ssidpassword";

// Define DHT type & GPIO
#define DHTPIN 4
#define DHTTYPE DHT22

DHT dht(DHTPIN, DHTTYPE);
AsyncWebServer server(80);

// Define device location
const char* deviceLocation = "Room Location"; // Change this to machine your sensor location

void setup() {
  Serial.begin(115200);
  dht.begin();

  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.println("Connecting to WiFi...");
  }
  Serial.println("Connected to WiFi");

  server.on("/sensor", HTTP_GET, [](AsyncWebServerRequest *request){
    float tempC = dht.readTemperature();
    float tempF = dht.readTemperature(true);
    float humidity = dht.readHumidity();

    if (isnan(tempC) || isnan(tempF) || isnan(humidity)) {
      request->send(500, "application/json", "{\"error\":\"Failed to read from DHT sensor\"}");
      return;
    }

    StaticJsonDocument<200> jsonDoc;
    jsonDoc["location"] = deviceLocation;
    jsonDoc["temperature_C"] = tempC;
    jsonDoc["temperature_F"] = tempF;
    jsonDoc["humidity"] = humidity;

    String jsonResponse;
    serializeJson(jsonDoc, jsonResponse);
    request->send(200, "application/json", jsonResponse);
  });

  server.begin();
}

void loop() {
  // Nothing needed in loop since server runs asynchronously
}

The Output

Once it’s running, you  can visit http://<ESP32_IP>/sensor to get output like this:

{
"location": "Location Name",
"temperature_C": 20,
"temperature_F": 68,
"humidity": 44.1
}

Getting Data into Graylog

To get this data into Graylog, I set up an HTTP API input. This input type is perfect for ingesting structured JSON from IoT devices or scripts. Note: I did not setup advanced token security or any other more secure setup. This could include an API key in your Arduino setup.  This was for basic use and always for best practice, secure your stuff.

Here’s the approach:

• The ESP32 code doesn’t push data—it just serves it in this case.
• I scheduled the input to poll every 6 hours
• It hits the /sensor endpoint, and then pulls the data to Graylog.

Visualizing It in Graylog

Once the data is flowing in, it’s easy to build a dashboard that gives you a real-time view of your environment. I created widgets to show temperature and humidity over time, and also added gauges for current values.

If you want to get creative, you can even trigger alerts for thresholds—like if the humidity spikes or the temp drops below safe levels for a server rack or in my case, the guitar room 🙂

Ideas for Future Expansion

• Add multiple sensors and Graylog inputs for different rooms
• Include motion or door sensors
• Combine sensor data with home firewall logs to correlate physical presence with network activity
• Use anomaly detection to flag environmental shifts

Final Thoughts

This was a fun way to get another project into Graylog alerts. Feeding in structured JSON from a homemade sensor opens the door to a wide range of creative monitoring setups.

If you try something similar or take it further, I’d love to hear about it.