Malware Analysis • IIS Trojan

      BadIIS Malware: A Deep-Dive Analysis of the IIS SEO Poisoning Trojan    

By CyberDudeBivash • October 04, 2025 • Technical Threat Analysis

 cyberdudebivash.com |       cyberbivash.blogspot.com 

Disclosure: This is a technical malware analysis for security professionals. It contains affiliate links to relevant security solutions and training. Your support helps fund our independent research.

 Technical Analysis: Table of Contents 

1. Chapter 1: Threat Context — The Role of BadIIS in the UAT-8099 Campaign
2. Chapter 2: Part 1 — The Installation & Persistence Mechanism
3. Chapter 3: Part 2 — The Cloaking & Redirection Engine
4. Chapter 4: The Defender’s Playbook — A Forensic & Hunting Guide

Chapter 1: Threat Context — The Role of BadIIS in the UAT-8099 Campaign

In our recent reports on the **Search Integrity Crisis**, we identified a threat actor, UAT-8099, that is systematically compromising high-authority web servers. The core component of their operation is a custom malware we have named **BadIIS**. This malware is not a RAT or an infostealer in the traditional sense. It is a specialized, server-side implant designed for a single purpose: to conduct highly evasive, large-scale SEO poisoning campaigns. This is the deep-dive technical analysis of that malware.

Chapter 2: Part 1 — The Installation & Persistence Mechanism

BadIIS is a post-exploitation payload. The attacker must first gain administrative access to the target Microsoft IIS server. Once they have access, they deploy the malware by registering it as a native IIS module.

The Installation Command:

The attacker uses the legitimate IIS command-line tool, `appcmd.exe`, to install their malicious DLL:

%windir%\system32\inetsrv\appcmd.exe install module /name:"IIS Security Module" /image:"%windir%\System32\inetsrv\BadIIS.dll" /add:true

The Persistence Mechanism:

This command modifies the primary IIS configuration file, located at `%windir%\System32\inetsrv\config\applicationHost.config`, adding an entry to the “ section. This modification is the persistence mechanism. Every time the IIS service starts, it reads this configuration file and automatically loads the malicious `BadIIS.dll` into every `w3wp.exe` worker process on the server.

Chapter 3: Part 2 — The Cloaking & Redirection Engine

The core of the malware’s logic resides within the DLL. It hooks into the IIS request processing pipeline, typically at the `OnBeginRequest` event, allowing it to inspect every single HTTP request that hits the server.

The Cloaking Logic (Pseudo-code):

function OnBeginRequest(HttpRequest request) {
  string userAgent = request.Headers["User-Agent"];
  string referer = request.Headers["Referer"];

  // --- CLOAKING LOGIC ---
  if (userAgent.Contains("Googlebot") || userAgent.Contains("bingbot")) {
    // Visitor is a search engine. Serve spam content.
    ServeSpamPage();
    return HTTP_REQUEST_STOP; // Stop further processing
  }

  // --- REDIRECTION LOGIC ---
  if (referer.Contains("google.com") || referer.Contains("bing.com")) {
    // Visitor came from a search engine.
    if (IsSpamKeyword(request.QueryString)) {
      // They searched for a spam keyword we ranked for.
      response.Redirect(302, "http://illegal-gambling-site.com/...");
      return HTTP_REQUEST_STOP;
    }
  }
  
  // Visitor is a normal user. Do nothing.
  return HTTP_REQUEST_CONTINUE;
}

This simple but powerful logic allows the malware to run a full-scale SEO poisoning and traffic redirection campaign while remaining completely invisible to the website’s legitimate owners and visitors.

Chapter 4: The Defender’s Playbook — A Forensic & Hunting Guide

Finding this threat requires moving beyond simple malware scans and hunting for specific artifacts and behaviors.

Forensic Analysis:

1. **Audit IIS Modules:** The #1 check. Run `appcmd.exe list modules` and scrutinize the list for any non-default, unsigned, or suspiciously named DLLs.
2. **Analyze `applicationHost.config`:** Manually inspect the “ section of this file for any entries that do not belong to Microsoft or a known, legitimate application.

Log Analysis:

Analyze your IIS logs. Look for requests from known search engine bot User-Agents (e.g., “Googlebot”). Do the byte sizes (`sc-bytes`) for the responses served to these bots differ significantly from the byte sizes served to normal users for the same URL? This can be an indicator of cloaking.

EDR Threat Hunting:

The most powerful method is to hunt for the installation activity itself with your **EDR platform**. A high-fidelity query is:

ProcessName:'appcmd.exe' AND CommandLine CONTAINS 'install module'

The installation of a new native IIS module is a rare and highly privileged event that should always be investigated.

 Detect the Initial Breach: BadIIS is a post-exploitation payload. A modern EDR like **Kaspersky Endpoint Security for Windows Server** is essential for detecting the initial RDP brute force or vulnerability exploit that allowed the attacker to install the module in the first place.  

Get Daily Threat Intelligence

Subscribe for real-time alerts, malware analysis, and strategic insights.         Subscribe  

About the Author

CyberDudeBivash is a cybersecurity strategist with 15+ years in web security, incident response, and malware analysis, advising CISOs across APAC. [Last Updated: October 04, 2025]

  #CyberDudeBivash #BadIIS #Malware #IIS #SEO #CyberSecurity #ThreatIntel #InfoSec #ThreatHunting #EDR #MalwareAnalysis