Introduction
CyberArk Labs recently identified what it believes to be a significant risk in the Microsoft Windows 10 Security Event log.
Once reserved for IT administrators to troubleshoot system problems, Windows Event log has evolved as an important component of enterprise security operations for conducting Windows audits and threat detection. According to Microsoft, the Event Viewer provides detailed information about system events including information such as the event type, the date and time that the event occurred, the source of the event, the category for the event, the Event ID, the user who was logged on when the event occurred, and the computer on which the event occurred.
Automated solutions and security experts collect and analyze these Event Logs to identify security-related risks such as OS changes made using privileged administrator account credentials. Security experts have become conditioned to fully trust the reliability of this log data, and due to the perceived high reliability of the Windows Event Log, it may serve as evidence in court. But what if an attacker gains control over an endpoint, compromises privileged accounts, and manipulates these records?
This blog will explore a serious condition that risks enabling an attacker to manipulate log data, address the impact on the veracity of Event Logs and security protocols, and offer advice to organizations to help mitigate risk.
Description of Risk
Our research discovered security risks relating to Windows Security Event Logs used to support Windows Audit processes. Attackers may be able to bypass security measures and alter Event Logs that automated algorithms and security experts rely on to mitigate the damage of an attack. By circumventing Microsoft security audits and falsifying Event Logs, attackers would be able cover their tracks, exploit privileged credentials without detection, freely move about the network and exfiltrate data or cause other damage to the infrastructure.
Automated services and security experts trust the information in Event Logs for several reasons, including that Log files are only accessible by the Event Log service, and the Security Event Log is only writable by the Local Security Authority Subsystem Service (LSASS) process. LSASS is a process in the Microsoft Windows operating system that enforces security policy by verifying users logging on to a Windows computer or server, manages password changes, and creates access tokens.
In Windows 10, new capabilities were added to LSASS to help identify attacks that steal credentials from the memory of a process. New Microsoft audit features not only track unwanted access to LSASS, but also privileged credential escalation and credential theft.
After reviewing new audit features, CyberArk Labs initiated research that found several risks associated with Windows Event Log, including:
- Security audit files are not encrypted on the machine
- These files are editable by attackers through multiple techniques
- These files can be modified if an attacker has the required skills
- Once modified, these files can be opened by Windows Event Viewer without any indication of compromise. Event Viewer is a tool that displays detailed information about significant events on your computer (for example, programs that don’t start as expected or updates that are downloaded automatically).
Exploitation
It is generally known that the security log (Security.evtx) file is only writeable by the LSASS process. According to Microsoft, “only the Local Security Authority (Lsass.exe) has write permission for the Security log. No other account can request this privilege.”
Our research team set out to investigate whether the data inside Windows Security Log could be manipulated. Our research is ongoing, but we decided it was important for security vendors and incident response teams to understand what we’ve learned so far.
During our research, the team has been able to accomplish several tasks that should raise concerns among customers. These tasks include the ability to stop the writing to the Security Event Log, alter records, replace the existing log, and resume the event log – all without being detected.
Our research proved that once the administrator privileges on the machine had been compromised, there are a number of ways to retrieve and edit the data, and then inject the modified data back into the log without detection. Specifically, the following screen shots illustrate the change of a single record in the security audit file, whose purpose it is to alert on access to the LSASS process. The actual event was triggered using Mimikatz.
After altering this field we can see that there are no traces to the actual incident (those trained on where to look will notice that no “Log Clear” record exists).
Figure 1 – Pre modification
Which is followed by:
Figure 2 – Post modification
As you can see, the event record that initially indicated Mimikatz performed a “read memory” action from LSASS now shows there is no threat to the enterprise.
Mitigation
There are a few mitigation techniques that organizations should consider. The first would be to ensure that audit records are immediately sent to their SIEM (log management) system. If a trusted copy of the audit record can be stored outside of the Microsoft audit log, any unauthorized changes to the log file will not impact the operation of their analytics system or centralized audit records.
However, our experience has shown that many organizations do not have a SIEM, may not collect logs from all of their systems or do not upload log entries in real-time, so this mitigation option may be of limited use. And of course, this step will have no mitigation value if an attacker disables the audit logging process for a period of time.
This attack can be avoided to begin with by adopting the least privilege principle – specifically denying administrative rights from endpoint users. Though the altering of data does not require administrative rights, the procedure enabling an attacker to actually replace the data inside the security event log does.
Additional mitigation techniques include monitoring access to these sensitive files; monitoring administrative actions in real-time and monitoring access to sensitive processes like the event log service.
Specifying further mitigation techniques is currently in process as research into this risk continues.
Disclosure Timeline
- April 12, 2016: Initial discovery by CyberArk Labs
- April 28, 2016: Risk reported to Microsoft Security Response Center
- April 28, 2016: Microsoft responded that they did not consider the submission a valid vulnerability due to the fact that a user would need to have administrator privileges on the machine to execute the attack.*
- May 19, 2016: Public disclosure
*According to Microsoft’s “Ten Immutable Laws of Security” if administrator privileges are required, then the system is already compromised.
