The Logging Dead: Two Event Log Vulnerabilities Haunting Windows

You don’t have to use Internet Explorer for its legacy to have left you vulnerable to LogCrusher and OverLog, a pair of Windows vulnerabilities discovered by the Varonis Threat Labs team.

Microsoft ended support for Internet Explorer on June 15, 2022. However, IE’s deep integration into the Windows ecosystem impacts the security and stability of current Windows operating systems.

One feature of the IE and Windows integration is an Internet Explorer-specific Event Log that is present on all current Windows operating systems. This IE-specific Event Log has a distinct set of permissions that enable two exploits against Windows systems:

1. LogCrusher, which allows any domain user to remotely crash the Event Log application of any Windows machine on the domain.

2. OverLog, which causes a remote denial-of-service (DoS) attack by filling the hard drive space of any Windows machine on the domain. (CVE-2022-37981)

In this article, we’ll explain how both exploits work and detail their respective attack flows. As part of our research, we promptly disclosed these vulnerabilities to Microsoft, which released a partial patch on October 11, 2022. We urge everyone to patch their systems.

Enter Microsoft Event Log Remoting Protocol (MS-EVEN)

These exploits (LogCrusher and OverLog) both use functions of the Microsoft Event Log Remoting Protocol (MS-EVEN), which allows for remote manipulation of a machine’s event logs.

From Microsoft:

The Event Log Remoting Protocol is an RPC-based protocol that exposes remote procedure call (RPC) methods for reading events in both live event logs and backup event logs on remote computers.

Internet Explorer log handle

OpenEventLogW is a Windows API function that allows a user to open a handle for a specific event log on a local or remote machine.

This function is useful for services that can use it to read, write, and clear event logs for remote machines without the need to connect manually to the machines themselves.

The function takes two parameters:
lpUNCServerName — The remote machine name, or NULL for a local connection
lpSourceName — The specific Event Log to get the handle to

By default, low-privilege, non-administrative users cannot get a handle for event logs of other machines.
The one exception to this is the legacy “Internet Explorer” log — which exists in every Windows version and has its own security descriptor that overrides the default permissions.

The Internet Explorer Event Log security descriptor can be found under the registry hive:

- HKLM\SYSTEM\CurrentControlSet\Services\EventLog\Internet Explorer

CustomSD = O:BAG:SYD:(A;;0x07;;;WD)S:(ML;;0x1;;;LW)

Parsing the security descriptor string:

Can you see it? The DiscretionaryACL specifies it!

This ACL allows any user to read and write logs to it. An attacker can get a log handle to every Windows machine in the domain from any domain user. This sets the stage for our two exploits.

LogCrusher

ElfClearELFW logic bug

ElfClearELFW is an MS-EVEN function that allows administrators to remotely clear and backup event logs.

The function takes two parameters:

LogHandle — Log handle that has an already opened OpenEventLog function.
BackupFileName — a pointer to a Unicode string struct that holds the location for backing up the event log before it is cleared.

Unfortunately, the ElfClearELFW function has an improper input validation bug. It expects that the BackupFileName structure will be initialized with some values or zeros, but when the pointer to the structure is NULL, the process crashes.

Attack flow

Combining these two functions, it's easy to understand the LogCrusher attack flow. Call the OpenEventLog function for the “internet explorer” Event Log on the victim machine: Handle = OpenEventLog(, internet explorer)

Call the ElfClearELFW function with the handle that was returned, and NULL as the BackupFileName parameter:
ElfClearELFW(Handle, NULL)

That’s it! Just like that, we crashed the Event Log on the victim’s machine.
By default, the Event Log service will try to restart itself two more times. On the third time, it will stay down for 24 hours.

A demonstration of LogCrusher repeatedly crashing the Event Log service until it stops restarting.

That’s cool. Where’s the impact?

The impact lies in the fact that many security controls rely on the normal operation of the Event Log service.

Without logs, security controls are blind.

Security control products, in some cases, attach themselves to the service! This means that when it crashes for good, the product will also crash and burn alongside it.

This in turn could allow an attacker to use any type of usually detected exploit or attack with impunity as many alerts won’t trigger.

Event viewer console shows an error while attempting to communicate with the service, meaning it's stopped.

Déjà vu?

Another interesting finding was that the bug in ElfClearELFW function was discovered two years ago, and reported to Microsoft by a researcher that goes by the nickname “limbenjamin.”

At the time, it was not possible to exploit the bug from a non-admin normal user account (and Internet Explorer), so the impact was unclear and Microsoft opted not to patch it.

OverLog

With this attack we were able to use the same methodology and “internet explorer” Event Log handle together with another vulnerability in BackupEventLogW function to cause permanent DoS for every Windows machine.

According to Microsoft, the BackupEventLogW function:

Saves the specified event log to a backup file. The function does not clear the event log.

…The BackupEventLog function fails with the ERROR_PRIVILEGE_NOT_HELD error if the user does not have the SE_BACKUP_NAME privilege.

The bug here is even more simple, and although it says in the documentation that the backup user needs to have SE_BACKUP_NAME privilege, the code does not validate it — so every user can backup files to a remote machine if they have write access to a folder on that machine.

Attack flow

Get a handle to the Internet Explorer Event Log on the victim machine (same as before).

Write some arbitrary logs to the Event Log (random strings; different lengths).

Backup the log to a writable folder on the machine (example: “c:\windows\tasks”) that every domain user has write permission to by default.

Repeat the backup process until the hard drive is full and the computer ceases operation.

Victim machine is unable to write “pagefile” (virtual memory), rendering it unusable.

Microsoft response and recommendations

Microsoft has opted not to fully fix the LogCrusher vulnerability on Windows 10 (more recent operating systems are unaffected).

As of Microsoft’s Oct. 11, 2022 Patch Tuesday update, the default permissions setting that had allowed non-administrative users access to the Internet Explorer Event Log on remote machines has been restricted to local administrators, greatly reducing the potential for harm.

While this address this particular set of Internet Explorer Event Log exploits, there remains potential for other user-accessible application Event Logs to be similarly leveraged for attacks.

We recommend that all potentially vulnerable systems apply the Microsoft-provided patch and monitor any suspicious activity.