While the server is running IIS (Internet Information Services), it is statistically unlikely that the vulnerability lies within the IIS software itself (unless the server is running a strictly obsolete version like IIS 6.0).

In 99% of these cases, the "known vulnerability" mentioned in the email refers to the web application running on top of IIS.

Given that the target is an insurance firm (which often uses ASP.NET enterprise software) and the result was a folder creation hack, here are the most likely specific vulnerabilities:

1. Telerik UI for ASP.NET AJAX (The #1 Suspect)

If this is a corporate website built on ASP.NET, this is the most probable culprit.

• The Vulnerability: (CVE-2019-18935 or CVE-2017-11882). Telerik is a popular suite of UI components used by developers to build forms and grids.
• Why it fits: There is a well-known critical vulnerability in older versions of Telerik that allows Remote Code Execution (RCE).
• The Attack Chain: Bots scan for specific Telerik files (like WebResource.axd). If found, they exploit the serialization flaw to upload a malicious file (a web shell) to the server. This shell is then used to create the /blank folder and generate the spam files.

2. Unrestricted File Upload

Insurance websites frequently have features allowing users to "Upload Claims" or "Submit Documents."

• The Vulnerability: If the application does not strictly validate file types, a hacker can upload a malicious script (e.g., shell.aspx or image.asp;.jpg) instead of a PDF or image.
• The Result: Once uploaded, IIS executes this script, giving the hacker full control to create directories like /blank and inject the SEO spam.

3. WordPress on IIS

Many companies run WordPress on Windows servers using IIS.

• The Vulnerability: If the site is WordPress, the vulnerability is likely in a Plugin or Theme (e.g., Slider Revolution, Elementor, or a File Manager plugin).
• Why it fits: The /blank folder hack is historically very common in WordPress "pharma hacks" or "Japanese keyword hacks." The hacker exploits a plugin to modify the web.config file or drop PHP scripts that generate the spam.

4. ViewState Deserialization

• The Vulnerability: ASP.NET uses a mechanism called "ViewState" to maintain the state of a page. If the encryption keys (MachineKey) are leaked or weak, or if the application deserializes untrusted data, a hacker can inject malicious objects.
• The Result: This leads to RCE, allowing the attacker to run commands like mkdir blank (make directory blank) and write files to it.

Summary of the Likely Attack Path

Regardless of which specific bug let them in, the mechanics on IIS usually look like this:

1. Entry: Hacker hits the vulnerability (e.g., Telerik RCE).
2. Payload: They drop a Web Shell (a backdoor script) into a writable directory (often \App_Data\ or \Uploads\).
3. Execution: They use the Web Shell to create the /blank directory.
4. Cloaking: They upload a script that checks the visitor's "User Agent."

• If it's GoogleBot: Show the "CURB stock" spam content (to rank in search).
• If it's a Human: Redirect to a scam or show a 404 error (to stay hidden).

You are absolutely right to suspect a virtual mechanism. In modern IIS hacks, it is standard practice for attackers to avoid leaving physical files (like a real /blank/ folder) on the disk because they are too easy to find and delete.

Since the folder doesn't exist physically, the server is intercepting the request for /blank/ and processing it dynamically. On IIS, this is almost certainly happening in one of two ways:

1. The "Reverse Proxy" Hack (Most Likely)

This is the most common technique for the specific "cloaking" behavior described in the email. The hacker hasn't just created a fake page; they have turned your server into a gateway for their own server.

• How it works: The hacker modifies your web.config file (located in the site's root directory). They add a URL Rewrite Rule.
• The Logic: The rule says, "If a user asks for .../blank/..., do not look on the disk. Instead, secretly fetch the content from hacker-site.com and display it."
• Why it's invisible: The spam content (the stock trading text) lives on the hacker's server, not yours. Your server just relays it. To Google, it looks like the page belongs to you.

What to check: Open your root web.config file and search for the <rewrite> section. Look for a rule that matches the pattern blank or generally redirects traffic to an external IP or domain.

It will look something like this:

<rule name="hacker_rule">
    <match url="^blank/(.*)" />
    <action type="Rewrite" url="http://malicious-external-site.com/{R:1}" />
</rule>

2. The "Malicious Handler" (Code Injection)

If they didn't use a rewrite rule, they may have injected code that tells IIS to "handle" any request starting with /blank/ using a specific piece of code rather than looking for a folder.

• How it works: They upload a compiled DLL file into your /bin/ folder or modify the Global.asax file.
• The Logic: The code listens to every request. If (Request.Url.StartsWith("/blank")) { Response.Write(SpamContent); }.
• Why it's invisible: The "folder" is purely code. It exists only in the server's memory while the application is running.

3. Database Injection (CMS Specific)

If you are running a CMS (like DotNetNuke, Umbraco, or a custom ASP.NET MVC app), the hacker might have injected these pages directly into your database.

• How it works: They use a SQL Injection vulnerability to add records to your "Pages" or "Articles" table with the slug /blank/why-retail-traders....
• Why it's invisible: The CMS routing engine sees a valid database record and renders the page dynamically, effectively creating a virtual folder.