Swedish Windows Security User Group

Web exploitation and web shells are some of the most common entry points in the current threat landscape. Web servers provide an external avenue directly into your corporate network, which often results in web servers being an initial intrusion vector or mechanism of persistence. Monitoring for exploitation and web shells should be a high priority for all networks, and while these detection techniques are targeted towards malicious IIS modules, a lot of these techniques will also provide general web shell detections.

IIS modules and the creation of persistent backdoors by malicious IIS modules has recently been addressed in the Microsoft Security blog titled Malicious IIS modules creating persistent backdoors. In this blog by Microsoft Detection and Response Team (DART), we aim to provide further guidance on detecting malicious IIS modules and other capabilities (such as logging) that you can use during your own investigations. While we will cover Microsoft Defender for Endpoint detections in this blog, these detection methods should be tool agnostic. The queries listed are not definitive detection queries, but rather a base query that you can build on to suit your specific environment.

A history of malicious IIS modules

The concept of malicious IIS has been around since at least 2013. Historical malware analysis shows how crimeware groups used IIS modules to intercept client logons and payment details by using the BeginRequest triggers to read user-provided parameters before the webserver processes them.

One of the first examples of sophisticated IIS modules was discovered in late 2021. The vendor’s ICEAPPLE report details an IIS module that was used by an actor to reflectively load further .NET modules, which by extension, loads further .NET capability. This allowed the actor to have minimal malicious indicators in the base IIS module, then load further capabilities as required.

A more recent example was provided in a recent Microsoft blog, where the actor instead opted for child process execution rather than loading the capability directly into w3wp.exe. This blog delves further into the capability to discuss the different capabilities that malicious IIS modules have access to.

Malicious IIS modules techniques

Event handlers

A core part of IIS module functionality is event handling. Event triggers provide opportunities for code to be called when specific actions happen. IIS modules have access to 27 event triggers by default, including:

• Begin Request: When a request is received by the webserver.
• End Request: When a response is about to be sent to the client.
• Error: When an error happens.
• Log Request: When a request is about to be logged.

Event handlers, which run when their associated trigger is fired, can allow an actor to essentially setup a proxy on the IIS server. By setting up an event handler on the BeginRequest, EndRequest, and Error event triggers, the actor can intercept all requests before the web service can process them and before the response is sent to the client.

Event handlers are given full read and write access to the requests, which allows malicious IIS modules to hide web shell communications within any aspect on the web request, turning every page that does and does not exist into a web shell. This can include hiding web shell communications in the parameters, body, headers, or HTTP methods.

These aspects of malicious IIS modules make them very hard to detect in standard IIS logs. You cannot rely on usual web shell detection strategies, such as high frequency page requests or URI patterns. Malicious IIS modules instead require new detection techniques and use of advanced IIS logging.

Request and response tampering

An additional difficulty with malicious IIS modules is that they can tamper with any aspect of the request and/or response. This could include removing web shell commands from parameters or headers and preventing web shell commands from being logged.

IIS Modules can also intercept responses before they are sent, which presents the opportunity for an actor to serve malicious payloads into any response from the website, potentially infecting viewers of the website.

Process creation

‘W3wp.exe’, also known as IIS worker processes, is utilized by web applications that run within IIS. Process creation is the most common indication of a web shell on IIS servers. Monitoring for the creation of common shell tooling (cmd, PowerShell, rundll32, mshta) with the parent process w3wp.exe can help detect low-sophistication IIS modules.

This should not be considered a strong detection for IIS modules. With full integration with C# and the .NET framework, a large amount of functionality can be integrated to execute directly within the IIS process without relying on creating child processes.

.NET assembly loading

A common execution path for actors is to load .NET modules directly into memory through reflectively loading assemblies. This can allow common tools, such as SharpHound or the Potato PrivEsc family, to be loaded without being written to disk. This is also seen as a stealthier alternative to process creation because it’s within the context of w3wp.exe rather than within a child process.

As mentioned in the vendor paper earlier, assemblies can be provided arbitrarily to deliver additional functionality. This may be through providing the assembly through the web request or downloading the assembly from an actor-controlled C2. The figure below shows: 

1. SharpHound being downloaded from an external C2 and loaded through the Reflection Assembly Load method.
2. Two methods being invoked within the binary and the output directory being set to ProgramData.

With access to .NET, malicious actors can add additional layers of evasion to prevent detection of their IIS modules, such as encoding or encryption. In the figure below, we can see:

1. A base64 encoded blob and the size of the decoded assembly.
2. A new memory allocation is made, where the assembly is decoded and deflated into the new allocation.
3. The assembly is loaded and invoked, executing the command whoami.

Logging and monitoring

Advanced IIS Logs

IIS logs are a great place to start hunting for web shells, but advanced IIS logging is recommended because IIS modules can remove malicious traffic from the standard IIS logs. The IIS Service can provide additional advanced logging, such as the Microsoft IIS Configuration Operational log, which can be enabled through the event log tool by using the following commands:

• Lists additional logs available for IIS: `wevtutil el | findstr -i IIS`
• Configuration for the selected log: `wevtutil gl Microsoft-IIS-Configuration/Operational` 
• Enable the selected log: `wevtutil sl /e:true Microsoft-IIS-Configuration/Operational`

The log that we will be focusing on in this blog is the Microsoft IIS Configuration Operational log. When enabled, the default path for this log is `C:\Windows\System32\winevt\Logs\Microsoft-IIS-Configuration%4Operational.evtx’ (shown in the figure above).

The Microsoft IIS Configuration Operational log captures the additional and removal of IIS modules (Event ID 29).  IIS modules are not commonly added to a production IIS server, so alerting on this event ID should be enabled within your SIEM or security products.

Note: This IIS module has no correlation with the Exchange Vulnerability ProxyShell.

IIS module listing

IIS modules can be installed at a global level or at a site level. In detecting malicious IIS modules, it is important to check both the global and site level for unauthorized modules. Regular monitoring of these locations for such modules and comparing against a known good list can help detect and identify malicious IIS modules. Appcmd (path: %windir%\system32\inetsrv\appcmd.exe), a command line tool for managing your IIS servers, can be used to that purpose. The command ‘appcmd list modules’ will list global IIS modules on your server. The command ‘appcmd list modules /app.name:<appName>/’ will let you search specific websites.

Modules listed through appcmd will be ordered based on the order of installation. In Figure 9, the two malicious IIS modules, ProxyShell and Malicious IIS Module, were the two most recent IIS modules installed and therefore the last two on the list. The type parameter also shows the class that is called when the module is loaded.

Web.config

The web.config file, which details the settings for a website, can include modules that the website loads and should therefore be monitored when detecting malicious IIS modules. Monitoring of web.config should primarily focus on tracking modifications to the file, and can be done through multiple tools and sources. For example, the Microsoft IIS Configuration Operational event log produces Event ID 50 when a modification is made to a website. Because the content of the modification is not captured, a backup of the web.config should be stored for easy comparison between the modified file and the original.

Most EDRs capture file modification events as well. Enabling an alert for the modification of web.config, especially from the w3wp.exe process, will enable detection of unwarranted changes to the config.

Hunting for malicious IIS modules

IIS module loading

While loaded IIS modules are standardly loaded DLLs, not all tools list .NET modules that are loaded into w3wp.exe. One tool that does show IIS modules loaded into w3wp.exe is Process Hacker, which if used with administrative privileges, will show them under the Modules tab.

In Microsoft Defender for Endpoint, an IIS module that is loaded into w3wp.exe will appear twice: First when loaded from the bin directory from which it resides, then immediately after from the temporary ASP.NET directory.

By default, IIS modules are loaded when the w3wp.exe process is created. If an IIS module is loaded while the w3wp.exe process is already executing and at a different time than the rest of the module, it can be an indicator for malicious IIS module loading. Monitoring for abnormal module loads may help detect malicious IIS modules. Using a query like the KQL one below can group together modules loaded into w3wp.exe at the same second. In Figure 12, we can see a large number of modules being loaded within a three second time period, followed by the malicious ProxyShell IIS module three hours later.

DeviceImageLoadEvents
| where InitiatingProcessFileName has "w3wp.exe"
| summarize loaded_modules=make_set(FileName) by format_datetime(Timestamp, 'yy-MM-dd HH:mm:ss')
| project Timestamp, loaded_modules, count=array_length(loaded_modules)

Assembly loading

While IIS modules have the capability to load .NET modules arbitrarily and reflectively within the context of w3wp.exe, the AppDomains are still registered within the hosting process. By listing AppDomain loaded within an assembly through a tool like Process Hacker, you’ll be able to find the loaded IIS module and any .NET modules that have been loaded.

In the figure above, the malicious IIS module ProxyShell can be seen alongside the loaded assemblies SharpHound and SweetPotato. Another thing to note is that reflectively loaded modules usually do not have Flags: in Figure 13, all the assemblies without Flags are either loaded through the malicious IIS module or through Visual Studio debugging.

The ETW provider Microsoft-Windows-DotNETRuntimeRundown provides a snapshot in time of the loaded .NET modules within active processes. Two events can help detect malicious assemblies loaded within IIS:

• Event ID 151 lists loaded AppDomains.
• Event ID 155 enumerates assemblies loaded at the time of the rundown.

The ModuleILPath field shows the path of the loaded assembly; however, if this assembly is loaded reflectively, rather than a path to the file, it will instead just list the name of the assembly. The figure below shows how SharpHound and SweetPotato, both with reflectively loaded assemblies, do not have paths while other events do.

The Assembly Flags field may also be 0, similar to Figure 13 where Process Hacker shows empty Flags for the assemblies.

IIS module installation

Processes which contain appcmd or gacutil within the command line and the parent process w3wp.exe should be investigated for potential installation of malicious IIS modules. The following Defender for Endpoint queries can help detect such malicious IIS module installation:

DeviceProcessEvents
| where ProcessCommandLine has "appcmd.exe add module"
| where InitiatingProcessParentFileName == "w3wp.exe"

DeviceProcessEvents
|where ProcessCommandLine has "\\gacutil.exe /I"
| where InitiatingProcessParentFileName == "w3wp.exe"

Process creation

Process creation events with the parent process of w3wp.exe should be monitored for abnormal child processes. For IIS servers that require child processes of w3wp.exe, ignore lists should be created for these child processes to prevent false flags.

DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ('w3wp.exe', 'httpd.exe')
| where FileName in~ ('cmd.exe', 'powershell.exe', 'cscript.exe', 'wscript.exe', 'net.exe', 'net1.exe', 'ping.exe', 'whoami.exe')
| summarize instances = count() by ProcessCommandLine, FolderPath, DeviceName, DeviceId 
| order by instances asc

Query source: Azure-Sentinel/Webserver Executing Suspicious Applications.yaml

If one of the Potato-sploits are being used to create processes, the AccountName field may also be “System” while the InitiatingProcessAccountName will be the Application Pool.

Conclusion

Threat actors use a variety of techniques to conceal their activity when using malicious IIS modules. Enabling additional logging in your environment is recommended to facilitate the detection of these harmful modules. Specifically, IIS servers should enable the optional event log Microsoft IIS Configuration Operational. This log can provide insight into IIS modules being added or removed from the IIS server and track any modifications made to web.config.

IIS Servers should have their web.config and IIS modules monitored for malicious modifications being made. For example, Gacutil.exe and appcmd.exe being executed from w3wp.exe should be monitored for potential installation of IIS modules. Additionally, the bin directories of websites and the default GAC path should be monitored and regularly scanned for malicious modules being created.

Hunting for malicious IIS modules can be performed through Microsoft Defender for Endpoint or your EDR of choice, and it should be conducted regularly to detect abnormal w3wp.exe interactions. This can include, but is not limited to, process creation, file creation and named pipe creation. Due to the wide flexibility around how IIS modules can execute malicious code, it’s important to look for irregularities in behavior.

Detecting web exploitation and malicious IIS modules should be a priority for all organizations, and Microsoft DART believes that following the recommendations provided in this blog and along with the monitoring and detection strategies will assist your organization in the detection and response of these threats.

The post IIS modules: The evolution of web shells and how to detect them  appeared first on Microsoft Security Blog.

Attackers are increasingly leveraging Internet Information Services (IIS) extensions as covert backdoors into servers, which hide deep in target environments and provide a durable persistence mechanism for attackers. While prior research has been published on specific incidents and variants, little is generally known about how attackers leverage the IIS platform as a backdoor.

Malicious IIS extensions are less frequently encountered in attacks against servers, with attackers often only using script web shells as the first stage payload. This leads to a relatively lower detection rate for malicious IIS extensions compared to script web shells. IIS backdoors are also harder to detect since they mostly reside in the same directories as legitimate modules used by target applications, and they follow the same code structure as clean modules. In most cases, the actual backdoor logic is minimal and cannot be considered malicious without a broader understanding of how legitimate IIS extensions work, which also makes it difficult to determine the source of infection.

Typically, attackers first exploit a critical vulnerability in the hosted application for initial access before dropping a script web shell as the first stage payload. At a later point in time, the attackers then install an IIS backdoor to provide highly covert and persistent access to the server. Attackers can also install customized IIS modules to fit their purposes, as we observed in a campaign targeting Exchange servers between January and May 2022, as well as in our prior research on the custom IIS backdoors ScriptModule.dll and App_Web_logoimagehandler.ashx.b6031896.dll. Once registered with the target application, the backdoor can monitor incoming and outgoing requests and perform additional tasks, such as running remote commands or dumping credentials in the background as the user authenticates to the web application.

As we expect attackers to continue to increasingly leverage IIS backdoors, it’s vital that incident responders understand the basics of how these attacks function to successfully identify and defend against them. Organizations can further improve their defenses with Microsoft 365 Defender, whose protection capabilities are informed by research like this and our unique visibility into server attacks and compromise. With critical protection features like threat and vulnerability management and antivirus capabilities, Microsoft 365 Defender provides organizations with a comprehensive solution that coordinates protection across domains, spanning email, identities, cloud, and endpoints.

In this blog post, we detail how IIS extensions work and provide insight into how they are being leveraged by attackers as backdoors. We also share some of our observations on the IIS threat landscape over the last year to help defenders identify and protect against this threat and prepare the larger security community for any increased sophistication. More specifically, the blog covers the following topics:

• Understanding IIS extensions
• Attack flow using a custom IIS backdoor
  • Command runs
  • Credential access
  • Remote access
  • Exfiltration
• Types of IIS backdoors
  • Web shell-based variants
  • Open-source variants
  • IIS handlers
  • Credential stealers
• Improving defenses against server compromise

Understanding IIS extensions

IIS is a flexible, general purpose web server that has been a core part of the Windows platform for many years now. As an easy-to-manage, modular, and extensible platform for hosting websites, services, and applications, IIS serves critical business logic for numerous organizations. The modular architecture of IIS allows users to extend and customize web servers according to their needs. These extensions can be in the form of native (C/C++) and managed (C#, VB.NET) code structures, with the latter being our focus on this blog post. The extensions can further be categorized as modules and handlers.

The IIS pipeline is a series of extensible objects that are initiated by the ASP.NET runtime to process a request. IIS modules and handlers are .NET components that serve as the main points of extensibility in the pipeline. Each request is processed by multiple IIS modules before being processed by a single IIS handler. Like a set of building blocks, modules and handlers are added to provide the desired functionality for the target application. In addition, handlers can be configured to respond to specific attributes in the request such a URL, file extension, and HTTP method. For example, Aspnet_isapi.dll is a pre-configured IIS handler for common .aspx extensions.

Creating custom managed IIS modules

To create a managed IIS module, the code must implement the IHttpModule interface. The IHttpModule interface has two methods with the following signatures: Init() and Dispose().

Inside Init(), the module can synchronize with any number of HTTP events available in the request pipeline, listed here in sequential order:

• BeginRequest
• AuthenticateRequest
• AuthorizeRequest
• ResolveRequestCache
• AcquireRequestState
• PreRequestHandlerExecute
• PostRequestHandlerExecute
• ReleaseRequestState
• UpdateRequestCache
• EndRequest
• PreSendRequestHeaders
• PreSendRequestContent

The newly created extension should then be mapped with the target application to complete the registration. Generally, there are several methods that can be used to map managed modules for legitimate purposes. On the other hand, we observed that attackers used the following techniques to register malicious IIS extensions during attacks:

Register with global assembly cache (GAC) PowerShell API: Every device with Common Language Runtime (CLR) hosts a device-wide cache called the global assembly cache (GAC). The GAC stores assemblies specifically designated to be shared by several applications on the device. GacInstall() is a PowerShell API to add modules into the global cache. Once installed, the module is available under the path %windir%\Microsoft.NET\assembly and is mapped to IIS (w3wp.exe) using appcmd.exe.

Register using appcmd.exe: Appcmd.exe is the single command line tool for managing IIS. All critical aspects, such as adding or removing modules and handlers, can be performed using the utility. In this case, the attackers drop the malicious extension in the target application’s /bin folder and map it using the add module command.

Register using gacutil.exe: Gacutil.exe is a Visual Studio shipped .NET GAC utility. The tool allows the user to view and manipulate the contents of the GAC, including installing new modules using the -I option.

Register using web.config: After dropping the module in the application’s /bin folder, attackers can also edit the web.config of the target application or the global config file, applicationHost.config, to register the module.

Upon successful registration, the module is visible inside the IIS manager application.

Attack flow using a custom IIS backdoor

Between January and May 2022, our IIS-related detections picked up an interesting campaign targeting Microsoft Exchange servers. Web shells were dropped in the path %ExchangeInstallPath%\FrontEnd\HttpProxy\owa\auth\ via ProxyShell exploit.

After a period of doing reconnaissance, dumping credentials, and establishing a remote access method, the attackers installed a custom IIS backdoor called FinanceSvcModel.dll in the folder C:\inetpub\wwwroot\bin\. The backdoor had built-in capability to perform Exchange management operations, such as enumerating installed mailbox accounts and exporting mailboxes for exfiltration, as detailed below.  

Command runs

PowerShDLL toolkit, an open-source project to run PowerShell without invoking powershell.exe, was used to run remote commands. The attacker avoided invoking common living-off-the-land binaries (LOLBins), such as cmd.exe or powershell.exe in the context of the Exchange application pool (MSExchangeOWAAppPool) to evade related detection logic.

Credential access

The attackers enabled WDigest registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attackers to steal the actual password, not just the hash. Later, Mimikatz was run to dump local credentials and perform a DCSYNC attack.

Remote access

The attackers used plink.exe, a command-line connection tool like SSH. The tool allowed the attackers to bypass network restrictions and remotely access the server through tunneled RDP traffic.

Exfiltration

The attacker invoked the IIS backdoor by sending a crafted POST request with a cookie EX_TOKEN. The module extracts the cookie value and initiates a mailbox export request with the supplied filter.

The value decodes to: ep,06/21/2022,06/21/2022,C:\Windows\Web,Administrator, where ep is the command to initiate the mailbox export request with filters determining the start and end dates followed by the export path. The final command has the following syntax:

The table below details all the commands found in the backdoor:

Command	Description
test	Attempts to load Exchange Management Shell (EMS)- Add-PSSnapin Microsoft.Exchange.Management.Powershell.SnapIn
box	List all UserPrincipalNames-  foreach ($name in Get-Mailbox -ResultSize unlimited){ Write-Output $name.UserPrincipalName}
ep	Run New-MailboxExportRequest cmdlet with supplied mailbox name, start and end date, and export path as filters.
gep	Get the task ID associated with the export request
ruh	Tamper with Exchange logs

Types of IIS backdoors

Reviewing the malicious managed (.NET) IIS extensions observed over the past year, we grouped these extensions based on various factors such as similar capabilities and sources of origin, as further detailed in the below sections. 

Web shell-based variants

Web shells like China Chopper have been widely used in numerous targeted attacks. As China Chopper’s usage increased over the years, so did the detections. As a result, the attackers evolved and added IIS module-based versions of these web shells that maintain the same functionality. The module uses the same eval() technique that’s used in the script version for running the code. While most antivirus solutions would detect the one-liner web shell, such as < %@page language=js%><%eval(request.item(<password>),”unsafe”);%>, embedding the same code in an IIS module generates lower detection rates.

In the module version, the attacker-initiated POST request contains the code along with the arguments in parameters z1 and z2, like the script-based version.

In a different version, the module has the backdoor logic hardcoded inside the DLL and only waits for parameters z1 and z2. The parameter kfaero has the command exposed as sequential alphabets from ‘A-Q’.

Like the script version, the IIS module has similar capabilities, such as listing and creating directories, downloading and uploading files, running queries using SQL adaptors, and running commands. To run commands, the attacker-initiated POST request contains the command “M” along with the arguments.

Antsword is another popular web shell widely used in various targeted attacks. Custom IIS modules inspired from the web shell’s code have been observed in the wild, which include similar architecture and capabilities. Interesting new features of these malicious modules include fileless execution of C# code and remote access via TCP socket connection.

Based on the request, the module can take one of the two code paths. In case of /server-status, a socket connection is initiated from values in the custom header Lhposzrp.

Command	Description
FSoaij7_03Ip3QuzbIhvuilKIsoM9a48DTkvQKdwtKNA	Socket connection
8CDztbQb4fsQeU5AAuBs9OmRokoyFJ7F5Z	Close connection
31FKvk8VDcqZMA3iAq3944wjg	Send data
TU_LDzOsv	Receive data

For any other URL, the module follows a China Chopper-style architecture of commands, ranging from “A” through “R”. The additional “R” command allows the attackers to run C# code reflectively.

Open-source variants

GitHub projects on creating backdoors for IIS have been available for some time now. Though mostly shared to educate the red team community, threat actors have also taken interest and lifted code from these projects. Using a public project that has been actively leveraged by attackers as an example, the original code includes the following capabilities:

Command	Implementation
cmd	Run command via cmd.exe /c
powershell	Run powershell via RunspaceFactory.CreateRunspace()
shellcode	Inject supplied shellcode into userinit.exe

In this case, the in-the-wild variants change the cookie names, keeping the rest of the code intact:

On supplying a whoami command to the backdoor, the generated cookie has the following format:

Cookie: BDUSS=P6zUsk/1xJyW4PPufWsx5w==

The backdoor responds with an AES encrypted blob wrapped in base64. The decoded output has the following format:

IIS handlers

As mentioned earlier, IIS handlers have the same visibility as modules into the request pipeline. Handlers can be configured to respond to certain extensions or requests. To create a managed IIS handler, the code must implement the IHttpHandler interface. The IHttpHandler interface has one method and one property with the following signatures:

Handlers can be registered by directly editing the web.config file or using the appcmd utility. The handler config takes a few important fields like path, which specifies the URL or extensions the handler should respond to, and verb, which specifies the HTTP request type. In the example below, the handler only responds to image requests ending with a .gif extension:

The handler is visible in the IIS manager application once successfully installed:

Most of the handlers analyzed were relatively simple, only including the capability to run commands:

Interestingly, the response Content-Type is set to image/gif or image/jpeg, which presents a default image when browsing the image URL with the output hidden in <pre> tags. A possible reason for this could be to bypass network inspection since image files are generally considered non-malicious and are filtered and identified based on extensions.

Credential stealers

This subset of modules monitors sign-in patterns in outgoing requests and dumps extracted credentials in an encrypted format. The stolen credentials allow the attackers to remain persistent in the environment, even if the primary backdoor is detected.  

The modules monitor for specific requests to determine a sign-in activity, such as /auth.owa default URL for OWA application. On inspecting the request, the module dumps the credentials in a .dat file. The contents are encrypted using XOR with a hardcoded value and wrapped with base64 encoding. The below image depicts a decoded sample output:

In another variant, the module looks for common placeholder variables for passing credentials used in different ASP.Net applications. The dumped credentials are AES encrypted and wrapped with Base64 encoding, located in %programdata%\log.txt.

Improving defenses against server compromise

As we expect to observe more attacks using IIS backdoors, organizations must ensure to follow security practices to help defend their servers.

Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations impacting servers. Deploy the latest security updates, especially for server components like Exchange as soon as they become available. Use Microsoft Defender Vulnerability Management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

Keep antivirus and other protections enabled

It’s critical to protect servers with Windows antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission in Microsoft Defender Antivirus to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and Windows Management Instrumentation (WMI). Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT professionals to help determine the true impact of these settings. Security teams and IT professionals should collaborate on applying mitigations and appropriate settings.

Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

Restrict access

Practice the principle of least-privilege and maintain good credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and enable MFA. Use tools like Microsoft Defender for Identity’s Local Administrator Password Solution (LAPS).

Place access control list restrictions on virtual directories in IIS. Also, remove the presence of on-premises Exchange servers when only used for recipient management in Exchange Hybrid environments.

Prioritize alerts

The distinctive patterns of server compromise aid in detecting malicious behaviors and inform security operations teams to quickly respond to the initial stages of compromise. Pay attention to and immediately investigate alerts indicating suspicious activities on servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Prioritize alerts related to processes such as net.exe, cmd.exe originating from w3wp.exe in general.

Inspect config file and bin folder

Regularly inspect web.config of your target application and ApplicationHost.config to identify any suspicious additions, such as a handler for image files—which is suspicious itself, if not outright malicious. Also, regularly scan installed paths like the application’s bin directory and default GAC location. Regularly inspecting the list of installed modules using the appcmd.exe or gacutil.exe utilities is also advisable.

Hardik Suri
Microsoft 365 Defender Research Team

Appendix

Microsoft Defender Antivirus detects these threats and related behaviors as the following malware:

• Backdoor:MSIL/SuspIISModule.G!gen
• Backdoor:MSIL/SuspIISModule.H!gen
• Backdoor:MSIL/SuspIISModule.K!gen
• Backdoor:MSIL/OWAStealer.B
• Backdoor:MSIL/OWAStealer.C
• Behavior:Win32/SuspGacInstall.B

Endpoint detection and response (EDR)

• Suspicious IIS AppCmd Usage

Hunting queries

To locate malicious activity related to suspicious IIS module registration, run the following queries:

Suspicious IIS module registration

DeviceProcessEvents
| where ProcessCommandLine has “appcmd.exe add module”
| where InitiatingProcessParentFileName == “w3wp.exe”

DeviceProcessEvents
| where InitiatingProcessFileName == “powershell.exe”
|where ProcessCommandLine has ” system.enterpriseservices.internal.publish”
| where InitiatingProcessParentFileName == “w3wp.exe”

DeviceProcessEvents
|where ProcessCommandLine has ” \\gacutil.exe /I”
| where InitiatingProcessParentFileName == “w3wp.exe”

Indicators of compromise (IOCs)

File name	SHA-256
HttpCompress.dll	4446f5fce13dd376ebcad8a78f057c0662880fdff7fe2b51706cb5a2253aa569
HttpSessionModule.dll	1d5681ff4e2bc0134981e1c62ce70506eb0b6619c27ae384552fe3bdc904205c
RewriterHttpModule.dll	c5c39dd5c3c3253fffdd8fee796be3a9361f4bfa1e0341f021fba3dafcab9739
Microsoft.Exchange.HttpProxy. HttpUtilities.dll	d820059577dde23e99d11056265e0abf626db9937fc56afde9b75223bf309eb0
HttpManageMoudle.dll	95721eedcf165cd74607f8a339d395b1234ff930408a46c37fa7822ddddceb80
IIS_backdoor.dll	e352ebd81a0d50da9b7148cf14897d66fd894e88eda53e897baa77b3cc21bd8a
FinanceSvcModel.dll	5da41d312f1b4068afabb87e40ad6de211fa59513deb4b94148c0abde5ee3bd5
App_Web_system_web.ashx.dll	290f8c0ce754078e27be3ed2ee6eff95c4e10b71690e25bbcf452481a4e09b9d
App_Web_error.ashx.dll	2996064437621bfecd159a3f71166e8c6468225e1c0189238068118deeabaa3d

The post Malicious IIS extensions quietly open persistent backdoors into servers appeared first on Microsoft Security Blog.

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, as part of Update Tuesday, we released 14 security updates – four rated Critical, nine rated Important, and two rated Moderate, to address 33 Common Vulnerabilities and Exposures (CVEs) in Microsoft Windows, Internet Explorer (IE), Office, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

We encourage you to apply all of these updates, but for those who need to prioritize deployment planning, we recommend focusing on the Critical updates first. For additional insight on deployment priority, review the Security Research and Defense blog “Assessing risk for the November 2014 security updates.”

For more information about this month’s security updates, including the detailed view of the Exploit Index (XI) broken down by each CVE, visit the Microsoft Bulletin Summary webpage. If you are not familiar with how we calculate XI, a full description can be found here.

We re-released one security advisory this month:

• Update for Vulnerabilities in Adobe Flash Player in Internet Explorer (2755801)

In related security news, through Microsoft Update, we are expanding best-in-class encryption protections to older, supported versions of Windows and Windows Server. To learn more, visit the Microsoft Cyber Trust blog.

For the latest information, you can follow the MSRC team on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, we provide advance notification for the release of 16 Security Bulletins. Five of these updates are rated Critical, nine are rated as Important, and two are rated Moderate in severity. These updates are for Microsoft Windows, Internet Explorer, Office, Exchange, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

As per our monthly process, we've scheduled the Security Bulletin release for the second Tuesday of the month, November 11, 2014, at approximately 10 a.m. PST. At that time, we'll provide deployment guidance. Until then, please review the ANS summary page for more information to help you prepare for Security Bulletin testing and deployment.

We also want to let you know about a new way we will deliver our Security Bulletins. To streamline the way customers receive our security updates, we are directing customers to resources that will be available on the MSRC blog on Update Tuesday.

Follow us on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Today, we provide advance notification for the release of 16 Security Bulletins. Five of these updates are rated Critical, nine are rated as Important, and two are rated Moderate in severity. These updates are for Microsoft Windows, Internet Explorer, Office, Exchange, .NET Framework, Internet Information Services (IIS), Remote Desktop Protocol (RDP), Active Directory Federation Services (ADFS), Input Method Editor (IME) (Japanese), and Kernel Mode Driver (KMD).

As per our monthly process, we've scheduled the Security Bulletin release for the second Tuesday of the month, November 11, 2014, at approximately 10 a.m. PST. At that time, we'll provide deployment guidance. Until then, please review the ANS summary page for more information to help you prepare for Security Bulletin testing and deployment.

We also want to let you know about a new way we will deliver our Security Bulletins. To streamline the way customers receive our security updates, we are directing customers to resources that will be available on the MSRC blog on Update Tuesday.

Follow us on Twitter at @MSFTSecResponse.

Tracey Pretorius, Director
Response Communications

Security Updates
Today we released six security bulletins to help protect our customers – four Critical, one Important, and one Moderate – addressing 19 vulnerabilities in Microsoft Windows Shell, Windows Kernel, Internet Explorer, Internet Information Services (IIS), .NET Framework, and Excel. For those who need to prioritize deployment, we recommend focusing on these two Critical updates first:

MS12-071 (Internet Explorer): This bulletin addresses three privately disclosed issues, none of which are currently known to be under active attack. Successful exploitation of these issues could result in code execution with the current user’s privileges. As such, we recommend the best practice of running applications with the least privileges possible in order to help mitigate potential risks. These issues do not affect Internet Explorer 10.

MS12-075 (Windows Kernel): This security update addresses three privately reported issues, none of which are currently known to be under active attack. This bulletin affects all supported versions of Microsoft Windows. The most severe issue could result in remote code execution if an attacker is able to lure a user to a website with a maliciously crafted TrueType font file embedded.

Security Update Re-release
In October we released Security Advisory 2749655 that addresses potential compatibility issues due to signature timestamps expiring before they should and noted we would be providing updates as they become available. Today we are providing one such update for MS12-046 (Visual Basic), which is now listed as available in the advisory. We have also released MS12-062 (System Center Configuration Manager 2007) to address an issue in the localization of resource files. Users who have already successfully installed the English versions of this update do not need to take any action.

You can find more information about this month’s security updates on the Microsoft Security Bulletin Summary web page. For an overview of the bulletins please watch the video below.

 

We recommend that customers deploy all security updates as soon as possible. Below is our deployment priority guidance to further assist customers in deployment planning (click for larger view).

 

Our risk and impact graph provides an aggregate view of this month’s severity and exploitability index (click for larger view).

 

Thanks for reading and join us tomorrow (Wednesday, Nov. 14, 2012) at 11 a.m. PST for a live webcast with Jeremy Tinder and myself, as we share greater details about these bulletins. As always, we will answer bulletin-related questions live during the webcast. You may register for that one-hour event here.

Thank you,

Dustin Childs
Group Manager
Microsoft Trustworthy Computing

Hello all —

Today, as part of our monthly security
bulletin release, we have 12 bulletins addressing 22 vulnerabilities in
Microsoft Windows, Office, Internet Explorer, and IIS (Internet Information
Services). Three bulletins are rated Critical, and these are the bulletins we
recommend for priority deployment:  

o   
MS11-003. This bulletin resolves three
critical-level and moderate-level vulnerabilities affecting all versions of
Internet Explorer. Due to existing mitigations, this bulletin is only rated at
Moderate severity for all versions of Windows Server, has an Exploitability
Index rating of 1, and will deprecate Security
Advisory 2488013.

o   
MS11-006. This bulletin addresses one Critical-level
vulnerability affecting Windows XP, Vista, Server 2003, and Server 2008. Newer
versions of our operating system are unaffected. The vulnerability involves
Windows Shell Graphics and could if exploited lead to remote code execution.
This has an Exploitability Index rating of 1 and will deprecate Security
Advisory 2490606 which we released on January 4^th. Since that
time, we have not seen any attacks against this issue.

o   
MS11-007. This bulletin addresses one privately
reported vulnerability affecting all supported versions of Windows and
involving the OpenType Compact Font Driver. It’s rated Critical for Windows
Vista, Windows 7, Server 2008 and Server 2008 R2; it’s rated Important for
Windows XP and Server 2003.  This issue has
an Exploitability Index rating of 2.

In this video, Jerry Bryant discusses this
month’s bulletins in further detail:

As always, we recommend that customers
deploy all security updates as soon as possible. Below is our deployment
priority guidance to further assist customers in their deployment planning
(click for larger view).

Our risk and impact graph shows an aggregate
view of this month’s severity and exploitability index (click for larger view).

More information about this month’s
security updates can be found on the Microsoft Security Bulletin summary web page. 

As mentioned, we are addressing Security Advisory 2488013 as part of the regularly scheduled
Internet Explorer cumulative update. This Security Advisory and the zero-day
disclosure on which it was predicated caused discussion in the security
community, and some observers thought that we might be forced to release an
out-of-band bulletin to protect customers. However, out-of-band releases are
disruptive to customers and we try to avoid them where possible. Based on our
capabilities to closely monitor the threat landscape, we were able to determine
that attempts to attack this vulnerability were very low. With that
information, we were able to extensively test a bulletin to be released as part
of our regular bulletin cadence. The MMPC (Microsoft Malware Protection Center)
blog has
details about the telemetry we used to guide us. There we
contrast this issue with telemetry from an out-of-band release last year to
demonstrate why one was not needed here.

Also this month, we’re updating Security Advisory 967940, “Update for Windows Autorun,” to change
how earlier versions of Windows handle security when reading “non-shiny”
storage media. (“Shiny” storage media would include CD-ROMs and DVDs.) Windows
7 already disables Autorun for devices such as USB thumb drives, which prevents
malware lurking on such drives from loading itself onto computers without user
interaction. With the change to the Advisory, earlier versions of Windows that
receive their updates automatically via Windows Update “AutoUpdate” will now
gain that security-conscious functionality as well. We believe this is a huge
step towards combating one of the most prevalent infection vectors used by
malware such as Conficker.

Finally, we’re excited to announce that
changes are coming to the system we use for publishing our bulletins and
security advisories – changes that will bring better integration with the
wealth of other content on Technet and a richer experience for customers. We
are expecting the changes to go live in the June 2011 timeframe. The main
impact to customers will be a URL change from microsoft.com/technet/security to
technet.microsoft.com/security. We are planning to have both the old and new
sites available simultaneously for a period of time and will be providing more
details in March.

Please join the monthly technical webcast
with your hosts, Jerry Bryant and Jonathan Ness, to learn more about all the February
2011 security bulletins. The webcast is scheduled for Wednesday, February 9,
2011 at 11:00 a.m. PST (UTC -8). Registration is available here.

For all the latest information, you can
follow the MSRC team on Twitter at @MSFTSecResponse.

Thanks,

Angela Gunn
Trustworthy Computing.