.png)
Update 2/14/2024: February Windows Updates did not patch this issue, so it remains a 0day. We did have to re-issue patches for three Windows versions because the updates changed wevtsvc.dll and patches had to be ported to the new versions.
Update 3/14/2024: March Windows Updates did not patch this issue, so it remains a 0day. We did have to re-issue our patch for Windows Server 2022 because the update changed wevtsvc.dll and our patch had to be ported to the new DLL.
Update 4/10/2024: April Windows Updates did not patch this issue, so it remains a 0day (now 70 days without an official fix).
Update 5/16/2024: May Windows Updates did not patch this issue, so it remains a 0day (now 106 days without an official fix). We did have to re-issue our patch for several Windows versions because updates changed wevtsvc.dll and our patch had to be ported to new DLLs.
Update 7/9/2024: Neither June nor July Windows Updates patched this issue, so it remains a 0day (now 6 months without an official fix).
Update 8/14/2024: August Windows Updates did not patch this issue, so
it remains a 0day.
Update 9/12/2024: September Windows Updates did not patch this issue , so
it remains a 0day.
Update 10/25/2024: Windows 11 24H2 has this issue patched, but all other Windows versions that are still receiving Windows Updates remain vulnerable to this 0day.
If you ever troubleshooted anything on Windows or investigated a suspicious event, you know that Windows store various types of events in Windows Event Log. An application crashed and you want to know more about it? Launch the Event Viewer and check the Application log. A service behaving strangely? See the System log. A user account got unexpectedly blocked? The Security log may reveal who or what blocked it.
All these events are getting stored to various logs through the Windows Event Log service. Unsurprisingly, this service’s description says: “Stopping this service may compromise security and reliability of the system.”
The Windows Event Log service performs many tasks. Not only is it responsible for writing events coming from various source to persistent file-based logs (residing in %SystemRoot%System32WinevtLogs), it also provides structured access to these stored events through applications like Event Viewer. Furthermore, this service also performs “event forwarding” if you want your events sent to a central log repository like Splunk or Sumo Logic, an intrusion detection system or a SIEM server.
Therefore, Windows Event Log service plays an important role in many organizations’ intrusion detection and forensic capabilities. And by extension, their compliance check boxes.
The “EventLogCrasher” 0day
“That’s a nice Event Log service you have here.
Would be a shame if something happened to it.”– every attacker
On January 23, 2024, security researcher Florian published details on a vulnerability that allows any authenticated user in a Windows environment (including in Windows domain) to crash Windows Event Log service either locally or on any remote computer (!)
As Florian explained, “according to MSRC, the bug does not meet the bar for servicing and therefore they allowed me to publish a proof of concept.” In addition, “they claimed it was a duplicate of another bug from 2022 (coincidence?) that didn’t meet the requirements for servicing.“
Florian’s POC (proof of concept) is remarkably simple: it makes a single call to RegisterEventSourceW, which retrieves a handle to an event log on the specified computer. (This function allows an application on computer A to obtain a handle to, say “Application” log on computer B, by sending a specific request to computer B’s Windows Event Log service.) However, before the request is sent to the target computer, the POC modifies its in-memory structure to confuse the receiving Event Log service. It manages to confuse it so much to cause a null-pointer dereference and crash the service. The attack only takes a second and works reliably.
The good news at this point is that Windows Event Log service is set to automatically restart if unexpectedly stopped. The bad news is that it only gets restarted twice, then not anymore. So crashing the Event Log service three times makes it persistently stopped.
Now, what does this mean? With Windows Event Log service stopped, no events can be written to logs, forwarded to other locations, or read from logs using event logging functions. For all practical purposes, logging has gone dark. And indeed, any Application events, and many other event source’s events that occur during the service downtime get irrecoverably lost.
Fortunately, Security and System events don’t get lost – at least not yet. Someone was smart enough to expect the possibility of a temporarily unavailable Event Log service and implemented an event queue for these important events. If Windows can’t report a Security or System event (perhaps some others too, we did not investigate), they put such event in some internal queue that then periodically retries to log all queued events until they finally succeed. We found no useful information about this queue’s implementation or configuration; in fact, the only official mention of this queue we could find was Event 4612(S), described as “This event is generated when audit queues are filled and events must be
discarded. This most commonly occurs when security events are being
generated faster than they are being written to disk.“
Our tests have shown that such queue in fact exists: if we left the Event Log service stopped and let some Security and System events occur, these events – of course – could not get logged. But after we started the Event Log service, they quickly got logged. Clearly something was storing them and making a real effort to get them logged. This is not really perfect news for the attacker: while security and system events they might trigger would not be logged while the Event Log service was down, they would get logged if the admin subsequently started the service.
Obviously, our next step was to see if the event queue survives a computer restart. Assuming that every Windows computer eventually gets restarted (at least still-supported ones on every second Tuesday), and that an admin noticing problems with logging may also decide to restart the computer, the question was: would queued events get lost?
And the answer was, they do not get lost. Apparently the event queue, presumably in memory, gets stored to disk when the system is gracefully shut down or restarted, and re-read upon startup. Once the Event Log service is running again, the queue is emptied into appropriate logs, with correct time stamps nonetheless.
What about a non-graceful system shutdown or restart? If the attacker manages to cause a blue screen on the computer where events are being stored in the event queue, these events will actually be irrecoverably lost. So there’s an unexpected bonus value in ping of death vulnerabilities.
The final question was, can Windows firewall or access permissions stop this attack? After all, event-collecting apps such as Sumo Logic require enabling remote event log management-related firewall rules (disabled by default) and adding the remote user to the Event Log Readers group (empty by default). Nope, even though such apps do not work and connecting to a remote Event Log with Event Viewer does not work without such firewall and permissions adjustments, the attack at hand works by default. In fact, the attack takes place over a named pipe (i.e., SMB protocol), and unless you can afford to completely disable SMB – no network shares, no printers, no many other things – we don’t believe you can configure Windows to prevent this attack from an attacker in your network.
So far we’ve discovered that a low-privileged attacker can crash the Event Log service both on the local machine and on any other Windows computer in the network they can authenticate to. In a Windows domain, this means all domain computers including domain controllers.
During the service downtime, any detection mechanisms ingesting Windows logs will be blind, allowing the attacker to take time for further attacks – password brute-forcing, exploiting remote services with unreliable exploits that often crash them, or running every attacker’s favorite whoami – without being noticed.
Knowing that the “dark times” can soon end when some admin decides to restart machines or start the Event Log service, a clever attacker could simply run the POC in a never-ending loop to make sure that as soon as the Event Log service is back up, it gets crashed again. It would be really difficult for an admin to even know that it was an attacker crashing the service, as we all know computer things often stop working unexpectedly even without malicious assistance.
Keeping the service down long enough could, after some time, reach the point of saturating the event queue to its limit – at least we assume there’s a limit or there wouldn’t have been a need for Event 4612(S). Having reached this point, attacker’s activities would from there on be irrecoverably un-logged.
The Flaw
As Florian noted in the POC document, “the crash occurs in wevtsvc!VerifyUnicodeString when an attacker sends a malformed UNICODE_STRING object to the ElfrRegisterEventSourceW method exposed by the RPC-based EventLog Remoting Protocol.”
Indeed, the POC causes the wevtsvc!VerifyUnicodeString function inside the Event Log service to reference a null pointer, which causes an unhandled access violation. This function received a single argument, a pointer to a UNICODE_STRING structure, whereby for some reason, the Buffer element of the structure, which should point to the actual buffer, points to 0. The function doesn’t expect that, at least not in the first part of the code, and crashes as shown on the image below. Also on the image, you can see that later in the code there is a check for the pointer being 0 – but too late.
 |
| Vulnerable function wevtsvc!VerifyUnicodeString |
Our immediate goal was to provide a patch to our users as quickly as possible, so we haven’t investigated further how the UNCODE_STRING structure was created with a null pointer. We plan to do that later, as it may reveal other similar flaws.
Our Micropatch
Our patch is simple: we just added a test for null pointer where such test was missing in the original code. The patch therefore consists of just two instructions: a compare operation and a conditional jump. The image below shows our patch (green code blocks) inserted in the original code (white blocks and the blue “Trampoline” block).
 |
| Our patch inserted in the original code |
The following video shows both the POC and our patch in action. On the left side is the target computer, a fully updated Windows Server 2019 acting as domain controller. The firewall rules are in their default configuration, with all three Remote Event Log Management rules disabled, to show that the firewall does not stop the attack. The Event Log service is running and 0patch Agent is initially disabled.
On the right side is the attacker’s Windows workstation, whereby the attacker is a regular Domain Users member. The attacker launches the POC against the domain controller and immediately crashes the Event Log service.
The same test is then repeated with 0patch Agent enabled, which applies our in-memory micropatch to the Event Log service process (of course without restarting the computer). This time, the POC fails to crash the service because our patch detects the presence of a null pointer and makes sure it does not cause a memory access violation.
Micropatch Availability
Since
this is a “0day” vulnerability with no official vendor fix available,
we are providing our micropatches for free until such fix becomes
available.
Micropatches were written for:
- Windows 11 v22H2, v23H2 – fully updated
- Windows 11 v21H2 – fully updated
- Windows 10 v22H2 – fully updated
- Windows 10 v21H2 – fully updated
- Windows 10 v21H1 – fully updated
- Windows 10 v20H2 – fully updated
- Windows 10 v2004 – fully updated
- Windows 10 v1909 – fully updated
- Windows 10 v1809 – fully updated
- Windows 10 v1803 – fully updated
- Windows 7 – no ESU, ESU1, ESU2, ESU3
- Windows Server 2022 – fully updated
- Windows Server 2019 – fully updated
- Windows Server 2016 – fully updated
- Windows Server 2012 – no ESU, ESU1
- Windows Server 2012 R2 – no ESU, ESU1
- Windows Server 2008 R2 – no ESU, ESU1, ESU2, ESU3, ESU4
These
micropatches have already been distributed to all
online 0patch Agents. If you’re new to 0patch, create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboot will be needed.
To learn more about 0patch, please visit our Help Center.
We’d like to thank Florian for
sharing vulnerability details, which allowed us to reproduce it and
create a micropatch. We also
encourage all security researchers who want to see their vulnerabilities patched to privately share them with us.
Frequently Asked Questions
Q: Which Windows versions are affected?
A: Currently, ALL Windows versions are affected, from Windows 7 up to the latest Windows 11 and from Server 2008 R2 to Server 2022
Q: What level of access does the attacker need to exploit this?
A: The attacker needs network connectivity to the target computer, and be able to authenticate to said computer as any kind of user (even a low-privileged one). Therefore, the attacker can always crash the Event Log service on the local machine, and can crash Event Log service on all Windows computers in the same Windows domain, including on domain controllers.
Q: Can this be exploited remotely by an attacker via the Internet?
A:No, the attacker must be able to send SMB requests to the target computer. Internet-facing Windows computers are unlikely to have SMB connectivity open to the Internet, and Windows computers in local networks even less so. The attacker must therefore already be in the local network.
Q: Is there any way to mitigate this attack with Windows configuration?
A: Short of denying SMB connectivity to the target computer (which would disable file and printer sharing, and various RPC-based mechanisms), we’re not aware of any way to mitigate the attack.
Q: Doesn’t Windows Firewall block this attack? After all, there are three pre-defined firewall rules for allowing Remote Event Log Management, which need to be manually enabled to allow remote event log management.
A: While these firewall rules indeed need to be enabled to allow remote event log management, this attack works regardless. Again, it works in the default Windows Firewall configuration.
Q: Does this vulnerability affect our IDS/SIEM?
A: It does if your IDS/SIEM is collecting Windows event logs. If the attacker crashes the Event Log service on a computer, that computer won’t be able to forward events to such IDS/SIEM. Any alerts that may be triggered based on Windows events will not be triggered during this time.
Q: Are events occurring during the Event Log service downtime irrecoverably lost?
A: Events generated by sources that don’t use event queuing are irrecoverably lost – this includes Application logs (including events about Event Log service crashing). Security and System events are queued in memory and can get stored to the event log later when Event Log service becomes available again. Queued events can get irrecoverably lost in case the computer ungracefully shots down (e.g., due to a blue screen or power-off), or if the queue gets full. Unfortunately we don’t know how many events the queue can hold.
Q: What should we do if we suspect someone crashed the Event Log service on one of our computers?
A: We recommend trying to salvage any potentially queued Security and System events by first disconnecting the computer from the network (if possible, to prevent further attacks) and manually starting the Windows Event Log service. As the service remains running, it will collect queued log events and store them to files so that even an ungraceful shutdown will not delete them. You can observe these events coming in with Event Viewer. When queued events are collected, reconnect the computer to the network to allow IDS/SIEM to collect them as well. If the Event Log service keeps getting stopped/crashed when you start it, it may be under constant attack so you will have to disconnect the computer from the network to keep it running. In this case, you can also inspect network traffic (incoming SMB connections to pipeeventlog to see where the attack is coming from.
Q: What do we have to do to use your micropatch for this vulnerability?
A: Create a free account
in 0patch Central, then install and register 0patch Agent from 0patch.com.
Our micropatch will be downloaded and applied automatically. For
information about central management, multi-user role-based support, and
other enterprise features, please contact sales@0patch.com.
Q: If we use your micropatch, what will happen if/when Microsoft provides their own patch for this issue?
A: 0patch co-exists nicely with official vendor updates because our patches are only applied in memory without changing original executable files. When Microsoft provides their own patch, they will replace various DLLs and EXEs, including the one in which our micropatch is getting applied. This will automatically ensure that our micropatch stops getting applied. In other words, you won’t have to do anything in addition to installing Windows Updates to stop using our micropatch and start using Microsoft’s patch.
Q: Is 0patch providing any other security patches?
A: Of course! We provide many “legacy Windows” patches and “0day patches” like this one. The former help our users keep unsupported Windows machines from Windows 7 to Windows 11 and from Server 2008 R2 to Server 2012 running securely, and the latter help in cases like this where the vendor doesn’t have an official patch available yet, or has decided not to provide patches anymore (e.g. for NTLM hash disclosure issues). To learn more about 0patch, please visit our Help Center or contact sales@0patch.com for a trial or demo.
Leave a Reply