Home » Security Bloggers Network » Using Log Parsing to Stop Microsoft IIS Backdoor Attacks

Using Log Parsing to Stop Microsoft IIS Backdoor Attacks

by EclecticIQ Endpoint Security Team on November 23, 2022

Chances are you’ve heard of Microsoft’s Internet Information Services, (more commonly known as IIS) as it’s one of the most popular web servers in the world, boasting a user base of over one million websites and included in the tech stack of nearly 6,000 companies. Being popular is great, but it also means becoming a bigger target – just ask Microsoft, who recently warned users about the growing trend of threat actors planting backdoors into Exchange servers via IIS extensions.

Many of these attacks started with the exploitation of a vulnerability to gain initial access, followed by the deployment of a web shell as the initial payload. After that, the IIS extension is installed to serve as a backdoor and provide covert, unauthorized access to the server and a means of persistence.

Why IIS extensions, though? There’s little difference between the malicious and legitimate files, and they are buried several levels down on the server in the same location as normal extensions. These factors make for a low detection rate and a perfect recipe for long-term persistence.

There’s some good news, however – Microsoft has published several indicators of compromise which can help detect such attacks, as well as several rules that can be implemented. Control Validation Compass has also published a set of rules that could aid in catching malicious SQL

injections.

LOOK AT THE LOGS

Now for the bad news – these indicators are not entirely helpful as modern malware are polymorphic in nature and detection strategies that are driven via IOCs or behavior rules can be easily bypassed.

Proper detection requires an additional level of visibility that is achieved by not only monitoring the application’s behavior (IIS in this case), but also looking at its activity logs. EclecticIQ’s ER platform, for example, has the ability to parse and read log files, which can detect the relevant malicious activity right away so administrators can take corrective action before the damage is done.

The capability is an out-of-the-box feature of the osquery-based engine of the Endpoint Response agent, and additional rules can be created based on the log file entries to look for anomalous or suspicious behavior related to a specific application.

Since these rules may not be enough to stop all attacks, as threat actors are always trying to find new and innovative ways of bypassing them, there is a need for additional layers of security. As we mentioned earlier, the ability to parse and read log files can be the key to quick identification and remediation before it’s too late.

WHAT COMES NEXT?

This is a series of three posts in which we’ll look at three of the most common types of attacks that could follow the successful creation of a backdoor and how EclecticIQ’s Endpoint Response platform can be leveraged to detect them. They are:

SQL Injection
Running a scan using nmap or sqlmap
Uploading a malicious file

SQL INJECTION

If a website does not perform adequate input validation, it may be vulnerable to SQL injection attacks. Attackers use SQL injection to insert SQL statements to any vulnerable entry field and dump the database’s contents. In the 7-Eleven breach, for example, attackers used SQL injection to steal 130 million credit card numbers.

It is, of course, best to fix all possible SQL injection points via proper input validation, but this may not always be possible, especially when the entity developing the application is different from the entity hosting the application. If a SQL injection vulnerability becomes known, web administrators may want to monitor if they are being exploited until the developers release a patch that can be deployed.

Detecting SQL injection using Eclectic IQ’s Endpoint Response platform can be done in three steps:

Enable “failed trace login” in the IIS server.
Configure Eclectic IQ’s Endpoint Response to capture the logs generated by the IIS server.
Create a rule so that Eclectic IQ’s Endpoint Response can generate an alert when a suspicious log is read.
If an attack is detected, collect information for further analysis in the future.

We will now explain in detail each of these steps.

Enabling Failed Trace Logging in IIS Server

SQL injection relies on sending SQL queries as data in the body of HTTP post messages.
IIS server can be configured to log the contents of POST requests. Once configured, IIS will place the logs in %SystemDrive%\inetpub\Logs\FailedReqLogFiles. Below is an example of a POST request that is trying to perform a SQL injection attack.

Configure ER to Capture and Parse Logs

EclecticIQ’s ER platform has a table called win_logger_plugin. This plugin can be configured to capture and match arbitrary logs. Matching is done via a regular expression, and whenever a match is found, an event is raised. The screenshot below shows one possible regular expression that can be used. We have used a very simple regular expression but a more granular and more flexible regular expression can also be used. The watch_file_path field specifies which log files are to be monitored.

Additionally, we will change the configuration such that file modifications to the logs are tracked. This will help us investigate alerts later.

Configuring ER to Raise Alerts

In the last step, we configured the machine hosting the IIS server to raise an event whenever an SQL injection attack is attempted. The ER server will log this event, but an alert will only be generated if a rule is created to match the alert. The screenshot below shows how to create the rule which will generate the alert.

Analyze the Alert and Gather Data for Further Analysis

Now that everything is properly configured, if another SQL injection attack is performed, an alert will be generated.

By clicking on the alert, and then clicking on “Alerted Entry”, we can get more details about the alert.

Furthermore, since we set up file monitoring on the c:\inetpubs folder, we can see which process modified this file by searching recent events for the host. We can see that w3wp.exe with pid 1724 modified it.

Next, it would be a good idea to check if this instance of w3wp.exe has launched any other processes. This can be easily seen by filtering for process events and then searching for the pid. We can see that w3wp.exe has launched php-cgi.exe.

In an earlier blog post, we covered how process memory can be scanned for implants. We can scan w3wp.exe for any suspicious implants using Live Query. In this case, it turns out that there have been no suspicious implants in the address space of w3wp.exe. If suspicious implants were detected, remediation action could be taken and the process could be terminated using the response feature in EclecticIQ ER.

At this point, the admin might want to take a copy of the c:\inetpubs folder for further analysis. This can be done by first using the live terminal to create a zip file, and then using carves to pull the file from the victim machine.

Once the zip file is created, it can be pulled into the server by using carves.

The carved file can be downloaded from the “Carves” option in the panel.

The above analysis will give the administrator a comprehensive overview of the attack and will help them make an informed decision as far as what mitigating actions should be taken.

As we’ve seen in this situation, EclecticIQ Endpoint Response can quickly and accurately detect SQL injection attacks, and then forensically analyze them to determine the best and most efficient means of remediation.

Next time, we will look at how scans using sqlmap or nmap can be detected. In the meantime, if you’re interested in how Endpoint Response works and its capabilities, you can visit our website to learn more.