Connect with us

Hi, what are you looking for?

SecurityWeekSecurityWeek

Incident Response

Why Hackers Love Logs

Log tampering is an almost inevitable part of a compromise. Why and how do cybercriminals target logs, and what can be done to protect them?

How hackers use log files

Computer log tampering is an almost inevitable part of a system compromise. Why and how do cybercriminals target logs, and what can be done to protect them?

A computer log file is a record of actions taken on or by an application within a computer. They are important to see what is happening within the system, whether it be a design malfunction or malicious activity. Initially, these logs were manually (and inefficiently) analyzed. Today the process is automated by other applications, especially security software watching for anomalous activity that might indicate an attack commencing or in progress.

While important to the operation of enterprise IT, logs are not directly relevant to the business of the enterprise. As a result, their value is often overlooked. They are not automatically considered part of the company’s ‘crown jewels’ that must be protected, and are often simple read/write text files with little security.

This is a mistake since the totality of the logs contain – albeit in a fragmented manner – a complete record of the IT infrastructure and its use. This reality is not lost to criminal attackers.

Content and attraction

Log file content may contain numerous attractions or capabilities for attackers, including: an aid to reconnaissance, PII and other regulated data, a means to stealth and covering tracks, and a method for disruption and extortion.

Reconnaissance. Logs contain data on everything happening within the infrastructure, which in turn could reveal behaviors, defenses, and the use of products that have known vulnerabilities. They can provide information on both infrastructure and software configurations, the presence of default passwords, user credentials and potential approaches to privilege escalation. In short, logs can help map and facilitate the attackers’ route to prized corporate content.

Rob Gurzeev, CEO and co-founder at CyCognito
Rob Gurzeev, CEO and co-founder at CyCognito.

PII. Logs are not naturally considered to be repositories of sensitive information. “In reality,” comments Rob Gurzeev, CEO and co-founder at CyCognito, “they contain a lot of PII and other sensitive data. They know who an executive is meeting, who the executive might be developing a partnership with, the phone numbers and other PII of other executives and people they do business with… They may contain sensitive information about big deals and M&As that big organizations might be working on. So, it’s a piece of the organization that not many people maybe take seriously or consider as the classic point of attack – but if you get access to the logs, the content is incredibly valuable to an attacker.”

Stealth and covering tracks. Logs are the window to the system. But logs are not intelligent. They record what is happening without knowing why it is happening. We use separate automated and increasingly AI-assisted software – such as advanced SIEMs – to interpret the activities that get recorded in the logs. More specifically, this automation seeks to differentiate between expected and unexpected activity; the latter potentially indicating malicious activity. The logs are a fundamental part of our visibility and subsequent defense, provided they are accurate.

“Attackers go after logs to cover their tracks,” says Tom Corn, CPO at Ontinue, “That’s key to persistence. In a Living off the Land attack, you want the longest dwell time possible. That means, low and slow, and cover your tracks. Many logs are not read only; therefore, attackers find the logs and change them.”

Advertisement. Scroll to continue reading.

If you can tamper with the logs, you can limit or prevent defenders’ visibility. “You not only hide yourself from the automated alarms that are in place, but you also hide how you’re conducting an attack,” explains Chris Cooney, developer advocate at Coralogix. “This is important. As a member of the blue team, you need to know what vectors and what vulnerabilities attackers are trying to exploit, so you can block them. If you can’t even see that, things get really scary for the security team, because you really need that visibility to be able to secure your perimeter and your system.” So, log tampering can be used for stealth during an attack. 

Chris Cooney, developer advocate at Coralogix.

It can also be used for stealth after the attack. It is possible to cause such a mess in the logs that visibility is lost for weeks. 

“An attacker can buy weeks before the victim, while it’s trying to fix the mess, even knows it was attacked. By the time the victim gets things working – and that’s a painful operation because the data is lost, and the ledger is in serious trouble – the attack is complete, and the attacker is long gone.” In this instance, log tampering can support stealth doing the attack, and help cover tracks after the attack.

Disruption and extortion. Logs are attractive to both primary categories of aggressor: criminals with a financial motive and nation-states with a political motive. For the latter, control of the logs helps reconnaissance and stealth for longer dwell times and better positioning for potential disruption. It similarly helps criminal gangs, but also provides an additional more direct route for extortion. 

“You could spray private personal information all over someone’s logs, and suddenly they’re in violation of any number of regulatory requirements,” explains Cooney. “The financial damage could be enormous, and that’s just by falsifying the log entries. You do this to one or two companies, and then you go to a third and say, ‘Hey, I’m about to make you extremely non-compliant with some of the most expensive regulatory frameworks in the world.’ It can be very difficult to stop this and very difficult to clean up the logs – so if it were to happen, the ransomware element is very real.”

Tampering methods

The most common method of tampering with log files is to corrupt the content by injecting false or misleading actions. However, the framework that manages the files can also be attacked, the files could be stolen, or they could be left exposed to the internet.

Log4j

Log4j is a widely used open source logging framework. Log4Shell was a critical vulnerability (CVE-2021-44228) in Log4j version 2. The vulnerability involved abuse of the Java Naming and Directory Interface API, a facility designed to allow developers to retrieve external objects or resources. JNDI was enabled by default in L4J version 2.

“Log4j v2 monitored the logs looking for a JNDI lookup instruction,” explains Cooney. “This is a useful feature in complex dynamic applications that can include different modules for different users on the fly.” It is not, however, vital for logs – and its presence in the code, never mind that it was enabled – would be unknown to many log developers.

Here’s how it was exploited. “The exploit was simple,” continues Cooney: “a remote code execution attack that would be automatic if the attacker could inject a JNDI lookup into the logs. This could be done by attempting to log into a system with a false username ‘JNDI, brackets, blah blah’ that contained an external location containing malicious code.” The login would fail, but the attempt would be logged, and the JNDI lookup invoked from inside the logs. 

“All an attacker would need to do would be to get the JNDI lookup pattern into the logs, and L4J would respond by fetching and executing random Java code from a random IP address because that is what it was designed to do.”

The Apache Software Foundation rapidly produced a fix, within about four days of learning about the flaw. But by then it had been an easily exploitable zero-day vulnerability for at least a fortnight. And it remained an n-day vulnerability until companies patched it. This has not been easy because of the sheer pervasiveness of L4J. 

In a May 15, 2024 blog, CyCognito reported, “Even though CVE-2021-44228 was first identified in 2021, some organizations still haven’t patched this remote code execution (RCE) vulnerability. CyCognito found that 2% of organizations still have assets vulnerable to Log4J.”

The threat from unpatched Log4J remains; the danger that something similar may reoccur in open source software is ever-present.

Internet exposed and stolen logs

When Gurzeev’s company onboarded a Fortune 100 payments company as a client, it discovered a Bash log exposed to the internet. 

“I believe that Bash history file contains dozens of MySQL credentials of the company concerned and many other companies,” he explains. “If attackers got access to it, and maybe they had already done so before we found it, every one of these could have resulted in a breach.”

The danger of this scenario is that the attacker holds all the cards. “If I get, say, 40 credentials from the bash history file to MySQL databases in this and other companies, I can now immediately launch attacks against the databases and steal information. Or I could simply connect as the admin of the databases. I could do this right now or I could do it gradually. I could wait a few weeks and do it at 4:00 am over a weekend.”

Exposing a log on the internet is giving its content to the attacker on a platter. But logs can be relatively easily exfiltrated and stolen since they are not often adequately defended. 

Log exfiltration is uncommon for two reasons. Firstly, an attacker able to steal a log would already be inside the network and would be more likely to tamper with rather than steal it. Secondly, the value to an attacker is log data is current. Once stolen, the snapshot becomes ‘history’ and data such as credentials may have been rotated. 

“The logs are valuable – extremely valuable. So, yes, it can happen,” says Cooney. “But to be honest, if I was an attacker and I’d got to the point where I could lift arbitrary files off the server, I would be going straight for access keys and passwords and usernames and scanning ports to look for other servers and whatever else. I’d try and get my claws into as many servers as possible at that point.”

But this doesn’t mean exfiltration cannot be done – and the content could still be of value to underworld access brokers. Chris Morgan, senior cyber threat intelligence analyst at ReliaQuest notes that his firm “has observed log sources being advertised with great frequency on cybercriminal locations like automated vending carts (AVC), which in essence act as an eBay for cybercriminality.”

By manipulation

“Logs are usually not well protected because they need to be open for writing from several sources,” comments Pieter Arntz, malware analyst at Malwarebytes. “Furthermore, they are often in plaintext with no encryption in play.”

This leaves them open to malicious manipulation. “Attackers typically target logs by exploiting vulnerabilities, using stolen credentials, or compromising accounts with access to log files,” explains Gareth Lindahl-Wise, CISO at Ontinue. “They might inject false entries, delete specific logs to erase traces, or modify details like timestamps and IP addresses. Sometimes, they go as far as disabling logging services to stop any activity from being recorded.”

And they might turn logging back on once the malicious activity has been completed, adds Tim Callan, chief experience officer at Sectigo. The appearance that nothing has happened doesn’t prove that nothing has happened.

Casey Ellis, founder and chief strategy officer at Bugcrowd
Casey Ellis, founder and chief strategy officer at Bugcrowd.

The approach to log-tampering will vary depending on the target, its logging process, and the TTPs of the attacker. “It can be as coarse as deleting a bash history file on a Linux system or using PowerShell to remove System Events in a Windows system,” comments Casey Ellis, founder and chief strategy officer at Bugcrowd. “In more complicated environments, it can involve identifying and attempting to compromise a dedicated logging system (and then removing that evidence as well).”

Defending logs

Prevent internet exposure. “You need a process to ensure that no log files are inadvertently exposed to the internet,” says Gurzeev. “They are not fundamentally different to a database or any other file. Attackers must not be allowed to simply access and/or download them.”

Penetration testing and patching. “Make sure your penetration testing, application security testing, and vulnerability management program covers all of your assets; and you have a process that makes sure that you’re at least fully aware of what you are not covering because that is where you are most likely to be attacked and exploited,” continues Gurzeev. “The reason that 2% of the Log4J systems were still vulnerable when we did our recent research was because most of these machines are not properly tested at all, or only once every few years. The coverage and cadence aspects of application security testing and vulnerability management pentesting is incredibly important.”

Protect the integrity of the logs. “To prevent log tampering,” suggests Morgan, “organizations can implement measures such as using write-once media or secure log servers that only allow append operations. Additionally, using cryptographic techniques to sign logs can ensure their integrity, allowing any tampering to be detected through verification of the cryptographic signatures. It’s crucial to regularly monitor and audit logs for any signs of unauthorized access or modifications.”

Jason Soroko, senior VP of product at Sectigo, suggests treating each log record as a transaction within a hashed data structure. “For example,” he says, “certificate transparency logs are based on a Merkle Tree data structure – meaning that the transactions can only be entered, never modified, never deleted. Any attempt to change data after it is entered results in knowledge that the log has been altered.”

Gareth Lindahl-Wise, CISO at Ontinue
Gareth Lindahl-Wise, CISO at Ontinue.

Lionel Litty, chief security architect at Menlo Security, suggests using a reverse proxy in the logging process. “There should be a log entry on the client side and on the server side. Sometimes, a server may not provide adequate logging. In these situations, logging should be provided by a middleman that cannot be tampered with, such as a reverse proxy.”

Lindahl-Wise summarizes the various options. “To defend against log tampering,” he says, “organizations should use centralized logging solutions that store logs in a secure, tamper-evident way. Implementing strict access controls ensures only authorized personnel can access and manage logs. Using immutable logs, which cannot be altered once written, is another key strategy. Encrypting log data, both at rest and in transit, conducting regular audits, and maintaining backups are also essential practices. Real-time monitoring and tamper detection mechanisms, like hash chains or digital signatures, can alert security teams to unauthorized changes. Finally, separating duties in log management helps reduce the risk of insider threats, ensuring the integrity of logs and the effectiveness of security monitoring.”

The first step must be recognition that although logs may not be the corporate crown jewels, they will almost always contain a map and keys to those crown jewels – and must be adequately protected.

Related: Cisco Duo Says Hack at Telephony Supplier Exposed MFA SMS Logs

Related: Microsoft Bows to Pressure to Free Up Cloud Security Logs

Related: Kaspersky Warns of Fileless Malware Hidden in Windows Event Logs

Related: Adobe Open Sources Tool for Sanitizing Logs, Detecting Exposed Credentials

Written By

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Click to comment

Trending

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Join the session as we discuss the challenges and best practices for cybersecurity leaders managing cloud identities.

Register

The AI Risk Summit brings together security and risk management executives, AI researchers, policy makers, software developers and influential business and government stakeholders.

Register

People on the Move

Retired U.S. Army General and former NSA Director Paul M. Nakasone has joined the Board of Directors at OpenAI.

Jill Passalacqua has been appointed Chief Legal Officer at autonomous security solutions provider Horizon3.ai.

Cisco has appointed Sean Duca as CISO and Practice Leader for the APJC region.

More People On The Move

Expert Insights