I'm curious as to just how secure the Windows event log is, and exactly what security measures it uses.

Does it include any defenses against tampering - for example, does it use digital signatures or hash chaining?

2 Answers 2


While ACLs are indeed the main way that the event log is secured, it does implement some other security features.

When the event log is cleared from the event viewer, a new event is added which contains the username of the user that cleared it.

event log 'clear event'

Windows also keeps event log files open while the operating system is running, locking the files in such a way that they can only be written to by the event log process[1]. It is however possible for tools to inject malicious code into the event log process to circumvent this. One such tool is WinZapper, though you do need Administrator access, and I haven't played with this since Windows XP - so no idea if it still works on Windows 7.

It is sensible to ship your logs to a remote, hardened server. A number of free tools, such as Snare, support forwarding Windows logs to a syslog server. Most SIM/SIEM tools also support this either by using locally installed agents to push logs to the remote server, or by the remote server pulling logs from source systems over WMI (less scalable way). You can also use the Windows Event Collector.

  • Thank you for answering the question! I get that if a machine is compromised that all bets are off, but I am rather surprised that it doesn't do more to secure the logs locally.
    – MurrayA
    Commented May 29, 2013 at 10:18
  • 1
    If a machine is compromised there is no way to solve the problem locally. "If your machine can do it, then the malware can do it too". The only way to solve the the problems is store the logs in a way that the machine that is creating the log entry can not edit the log itself. That may be by using WORM media or by using a 2nd machine and doing log shipping. Now if the 2nd machine gets infected too all bets are off again as the malware can just edit the logs again. Commented May 29, 2013 at 21:21

Windows' Event Log is only as secure as the system it is running on. Because accounts on the system read, write and modify the events, anyone compromising the machine, or anyone with admin privileges, can modify the events. Technically, only LSASS is supposed to be able to write, but history can tell you how Sasser and other worms rendered this useless.

Personally, the only possible defense I can think of against tampering would be to use remote logging, e.g. eventlog-to-syslog. This allows ANY and ALL entries to be stored remotely. The only method someone can use to bypass anything would be AFTER the fact. Meaning, there would ALWAYS be the initial instance of a log that can never be changed. If an attacker DID manager to start tampering with logs, they would have to do some heavy duty programming to intercept system calls prior to it being written (via LSASS) to hide their tracks.

Even so (managing to tamper with logs), the only mechanism they'd (the attacker(s)) would be able to do, to go BACK and hide/modify their entries, would be to also compromise the syslog server

EDITED at 3:42PM EST for clarity on my initial answer...

From the onset, you have to look at how Windows is storing anything with regards to EventLog. It is done at the application, session, presentation, transport layers. This is ALL done on the machine itself. Every single instance is written locally. THIS is the problem period. For ANYONE who would have access to reading, writing, opening, they'd have the capability (not ability unless they're an admin) to read and write files.

Think about that for a moment. If I am on a machine with these privileges, there is little to stop me from modifying. Even if you tried to log what I am doing, I can modify these logs. In fact timestomp (counterforensics program) does just that mangles MACE times. The ONLY mechanism to prohibit this, would be to send the logs OFF the machine. There is no mechanism I know of that will STOP someone local on the machine from gaining the ABILITY to modify eventlog data. This is because reads, and writes are done on the machine itself. There is the possibility that a) an update can break things b) a user with escalated privileges can delete, and or modify data.

Remote logging makes more sense because the logs (events) aren't stored, written, modified locally. Someone would have to get into the logging machine to manipulate (modify, erase) entries. The only other mechanism (local checksumming, etc) will ALWAYS get trumped because there always needs to be a superuser (admin, root, etc). Malware authors, virus writers, malicious attackers tend to modify event entries most of the times. This should be evident that not much can be done on a local level.

As for "tamper proof," Manage Engine claims they can do this. However, they do are doing it remotely.

  • 1
    I agree it's only as secure as the system it's running on - but I'd still like to know what security or tamper-resistance mechanisms the Windows Event Log implements
    – MurrayA
    Commented May 28, 2013 at 18:46
  • @MurrayA Essentially, the answer breaks down to file permissions. That's really all that stands between anyone and the ability to edit or delete the event logs. As munkeyoto says, getting the logs sent to another system in real-time will help mitigate this.
    – Iszi
    Commented May 28, 2013 at 20:24
  • I believe Manage Engine's tamper-proof claim relates to all logs stored in their own archive format (which can come from more than just Windows event logs), and is not specific to Windows event logs. Their website indicated they include encryption, hashing and timestamping of archived files as security measures (any SIM/SIEM will do these, of course)
    – MurrayA
    Commented May 29, 2013 at 7:35
  • 2
    I understand about how permissions and such come into play, and that remotely shipping the logs is sensible - but I still want to know what security or tamper-resistance mechanisms the Windows Event Log implements itself
    – MurrayA
    Commented May 29, 2013 at 7:39
  • Iszi told you already. Windows file permissions on the %SystemRoot%\System32\Winevt\Logs\ directory is the only security measure that is implemented out of the box. There is no tamper-resistance mechanisms in place other than permission restrictions. However Windows has made it easy to do log shipping as that is the "recommended" way of providing tamper-resistance. Commented May 29, 2013 at 8:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .