We’re here to talk about an important issue in WordPress security. Some people believe that stolen session cookies cause most website hacks—up to 60% of them. This simply isn’t true, and believing it can lead to bad security choices. 

Misconceptions can cause people to use the wrong fixes, ignoring real security issues. We’re in a good spot to clear things up. We’ve got lots of experience with website security and a wide range of data, more than just visit records. So, we can give you a clear and full understanding of how to really keep your WordPress site safe.

Where analyses in articles have gone wrong: access logs cannot pinpoint attack vectors

The biggest problem with the current crop of security articles, trying to debunk long established security knowledge and practices, is their data. 

Today, we need to talk about how access logs cannot be used to analyse attack vectors—and why. 

1. Access logs do not contain sufficient information to understand how a site is hacked. This is the biggest flaw of using access logs for this kind of analysis.

Access logs contain the following data: time, path, user-agent, resp-code, req-method and IP address. It lacks header and POST data.

For example, Essential Addons for Elementor was found to have a password reset vulnerability in May 2023.

The way the vulnerability was architected, hackers could have used any path to exploit it. The only way an analyst could identify an attack was through a parameter in the POST data of the path. Since the POST data is not visible in access logs, these attacks would not show up as suspicious in access logs.  

2. Different attack vectors can look identical in access logs.

Hackers exploit vulnerabilities on sites to gain access to them. Once they have accomplished this, their next goal is to retain that access for as long as possible. So hackers will then create backdoors to the hacked site.

The most effective backdoor is to crack an admin account, so getting an admin password becomes a primary target. So they will try to capture passwords the next time an admin logs into the site. The reason a hacker needs to do this is because passwords are well protected by WordPress. They cannot just read the passwords stored in the site’s database.

While there are many ways to steal passwords, here we have two examples of password-stealing scripts:

In the access logs, these scripts will not show up as special requests—which would raise flags. The access logs will show a user logging in normally. There will be no signs of a brute force attack, where hundreds of login attempts are clearly visible in the logs.

On the surface, it is easy to attribute the password theft to a user device being compromised. Whereas the reality is that the password theft was successful because hackers had exploited a vulnerability on the site.

Ultimately, access log data is too superficial to really understand how a site has been hacked.

3. Instances that are not attacks can look like attacks in access logs, and mistakenly give rise to inflated numbers.

For example, a single session can span multiple IP addresses. If a user logs in from different geographic locations, the access logs will show different IP addresses for the same user. And, in the barest of terms, this can look like a stolen session.

However, there are real situations where one person could legitimately log into a site from different locations. People who work in a hybrid remote and office model, for example. Or alternatively, even a travelling salesperson will trigger alarms, if the multiple IP addresses for a single user was a sign of hacker access.

On top of this, access logs do not have session information, so they cannot link a request to a particular user. And as illustrated above, only using IP addresses to do so is incorrect correlation.

4. Some attacks will not ever show up in access logs.

While it is rare, there are times where access logs will show that hackers have magically gotten access to sites. And since nothing is ever magical in cybersecurity, it means that we need to dig deeper for the real cause.

We recently assisted a customer who had 100s of hacked sites all at once. When we looked at the access logs, it looked like the hacker had gotten access magically. We could have also come to the same incorrect conclusion, however we always choose to dig deeper.

We found that the underlying server had been hacked. There are many vectors for attacks on servers, such as cPanel vulnerabilities or poorly managed servers. We have even seen servers poorly configured by experts or even web hosts, leading to all the sites on the server getting hacked with malware.

None of these vectors leave a footprint in access logs. Access logs do not capture this level of information, and building analysis on incomplete information will always lead to erroneous conclusions. 

5. The same IPs can access multiple sites. This is not just illicit hacker behaviour. How do we know? There are people who manage 3000 sites and more using WP Remote. They access all their managed sites from the same IP.

Therefore, a simple quantitative analysis of access logs cannot be used to draw any conclusions about attacks.

Session cookie theft is NOT a major cause of hacks on WordPress sites 

Now that we have established that access logs are not a good foundation for attack vector analysis, let us break down the conclusion that was drawn from it. 

Is session hijacking responsible for 60% of hacks on WordPress sites?  No, it is not. 

There are 3 major issues with the analysis, which we will talk about in more detail: 

Most methods for session hijacking have been mostly mitigated. The only real way to hijack sessions is through infected devices, which is rare and very hard to accomplish. 

If a user’s device was infected with malware, then all their accounts would be compromised, including bank accounts, credit cards, and email accounts. WordPress sites would also be compromised, but would not be high on the list of the hacker’s priorities. 

In access logs, many attack vectors look like stolen sessions. A very common attack vector, password theft, also looks like a stolen session. Therefore concluding that an attack is because of a stolen session is a superficial conclusion based on flawed analysis.

1. It is not easy to hijack sessions

As established in this article, and many others like it, it is extremely difficult to steal session data. Most of the methods used to steal session cookies have long been invalidated by improvements in WordPress and in browsers: using HTTPS exclusively, long session IDs, the Secure tag, the HTTPOnly tag, and so on. 

This leaves only one viable method by which session data can be stolen: malware present on user devices. 

Malware on devices is very serious, as the user and their data is completely compromised. And it is precisely for this reason that there have been many developments in technology that prevent transmission of malware, detect malware effectively, and educate users about the dangers of malware on their devices. 

The result is that devices are rarely infected by malware; and this is a good thing. 

Most cases that appear like stolen sessions are actually because of other attacks, like password theft. In turn, password theft can almost always be traced back to other attacks, like social engineering or data breaches.
This is not conjecture, and has been statistically proven time and time again. According to experts, 95% of cyberattacks are caused by human error or negligence. In fact, 46% of hackers distribute malware via email in phishing attacks, which in turn accounts for 91% of cybersecurity threats.

2. WordPress sites would not be top priority with infected devices

Another important aspect to consider is hacker motivation. 

Assuming a hacker was able to infect a WordPress admin’s device, then yes, then their site would be compromised.

However, a hacker will always go for the high value targets first. Chances are the hacked device is also used to access email or a bank account. If a hacker has gained access to a user’s device, WordPress sites would be very low on the list of targets.

We are not saying that WordPress sites are not valuable: they absolutely are. However, they are not more valuable than bank accounts.

If it were the case that 60% of WordPress sites are being hacked because of stolen session data, and the method used to do that is malware on devices, we would be in the middle of a major global cybersecurity crisis. 

As web developers, we have all dealt with hacked sites. In how many of these cases, did we see our Gmail accounts getting hacked? Or our bank accounts getting emptied out? The answer is none of us—thankfully—because computers getting compromised is no longer the issue it was in the 90s.

3. A lot of things look like stolen session data

Access logs do not contain a lot of information; certainly not enough to definitely attribute the source of a hack. In access logs, a lot of problems look like stolen session data, whereas the culprit is usually something else entirely. 

We have seen this phenomenon often enough at the doctor’s office. Does a stomach ache mean indigestion, a kidney stone, or pancreatic cancer? We can all agree that antacids will not work in all three cases.

A common culprit is password theft. Passwords can get compromised in multiple ways; even the strongest of passwords. Most commonly, we have seen data breaches from key services, like password managers. 

LastPass has become a notorious example for data breaches, seeing breaches in 2015, twice in 2022, and finally in 2023. In other years, security researchers also found high-severity vulnerabilities in LastPass, which could have led to further data leakage. 

Brute force attacks are far less successful than people imagine. There are well known mechanisms, like captcha plugins or 2FA, that further reduce the likelihood. 

However, regardless of whether a site implements a captcha or enforces 2FA, firewalls are the best defence—which is a good thing, because very few sites actually use 2FA. 

A good firewall is indispensable for a WordPress site.

Another culprit is an exploit on the server. Although it is much rarer, we have seen self-managed servers get compromised as well. Sometimes it is due to poor cPanel maintenance or even poor configuration. In this case hackers exploited the underlying operating system infrastructure and infected hundreds of sites with malware. In access logs, this looked like stolen session data as well, but certainly wasn’t.

Therefore, it is very difficult to trace the source of a hack. You cannot draw a conclusive answer, unless forensic analysis is run on every component of the information chain: devices, servers, sites, network links, and so on. 

Session hijacking is rarely the first exploit

Exploits are often chained together to take over sites. This means a hacker will exploit the first vulnerability to gain a certain level of access, and then another to increase their access, and so on. The goal is to gain full access to a site. 

There are rare cases where the first exploit could be session hijacking. However, it is more commonly due to mechanisms like fraudulent admin accounts. The ability to create fake admin accounts is a common vulnerability to begin with, and it is far easier to exploit this vulnerability compared to the effort needed to successfully hijack session data.

Session hijacking is usually a backdoor

In reality, session hijacking usually occurs after a site has already been hacked, and used as a backdoor. We have seen that malware scripts are used to steal session data to stay logged into a hacked site. 

And even under those circumstances, passwords and users are bigger, stronger targets compared to session data, as they are more permanent ways to retain access to a site.

Previously, certain vulnerabilities, like XSS, used to be exploited to steal session cookies. However these flaws have been addressed through the use of tags. Cookies now have the HTTPOnly tag to prevent client-side scripts from being able to access them, and the secure tag to ensure that they are transmitted over HTTPS only. 

The real problem lies here with malware scanners that rely on outdated and ineffective technology to detect malware. Just because a scanner is unable to detect malware on a site, does not automatically mean that malware doesn’t exist on the site. 

Every time we have seen cases of session theft, there has always been PHP or JS-based malware on the site as well.

Steps to prevent session hijacking being used as a backdoor

This is why we always recommend a post-hack checklist to users:  

Change passwords for all users

Force log out users

Changes WordPress security keys

These steps invalidate current sessions, and prevent them from being used to get access into the cleaned site again.

Vulnerabilities remain the biggest root cause of hacks

As we touched upon before, figuring out how a site has gotten hacked is not a simple endeavour. It requires forensic analysis of every touchpoint. 

As people detecting and cleaning hacked sites, we have seen multiple spikes whenever a major vulnerability is announced. Our firewall sees surges in malicious requests. And, finally, even Google trends show clear upticks in WordPress hack-related keywords during these times. 

At MalCare, we have access to several types of activity logs and lots of aggregated data from the 400,000+ sites we protect every day. In addition to access logs, server logs, plugin data, database changes, and more, we can see that vulnerabilities are undoubtedly the biggest attack vector for WordPress sites. In the near future, we will share this analysis in an article as well.

Stay safe by investing in the right places for WordPress security.

Security misinformation is very dangerous—and why debunking it is critical

Myths and misinformation are dangerous for WordPress sites because they shift focus. Site admin will install ineffective security plugins, believing that their sites are secure because of them. 

Let’s take login security for example. People strongly believed that WordPress logins were the weakest link. They focused on plugins that secured login pages, or did something similar, like 2FA or brute force protection. While these are good measures, they provide protection from about 5% of threats. 

Then there is bad information, like hiding the login page or changing the database prefix. These measures do little for site security, and cause other hassles for a site administrator. The reality is that this form of security—security via obscurity—is a myth.

Further, unethical providers will capitalise on these myths, and create products that also barely secure sites. It becomes a vicious cycle. 
The only winners in this scenario? The hackers. The ecosystem becomes the loser, and everyone complains that WordPress isn’t secure. Therefore, it is critical to course-correct misinformation before it spreads and becomes the de facto truth.

Glossary

What is a session? 

A session is a way for a website to remember a user as they move around the site. When someone logs into your WordPress site, the site gives their browser a unique identifier. This tells the site it’s still the same person on each new page they visit. It keeps them logged in and saves their choices until they log out or the session ends.

What is a cookie? 

A cookie is a small piece of data that a website stores on a user’s device. It saves information like a visitor’s session ID. Each time the visitor comes back, the browser sends the cookie back to the site. This lets the site remember visitor’s previous activity, like login details or preferences. This helps maintain a seamless experience across different visits, and to make the user’s experience more convenient.

How does WordPress use session cookies? 

WordPress uses session cookies to manage users’ login status. When someone logs in to your WordPress site, a cookie containing their authentication details is stored on their browser. This cookie verifies that they are logged in as they navigate through the site. Without these cookies, users would have to log in on every single page they visit on your WordPress site.

Why is it difficult to steal WordPress session cookies? 

It’s tough for a hacker to steal WordPress session cookies because they are protected in several ways. WordPress encrypts the data in these cookies, so even if hackers get them, they can’t easily read the information. Also, WordPress sets these cookies to HTTPOnly so that they can’t be reached by harmful scripts running in the browser, making it harder for hackers to grab them through common website attacks.

The post WordPress Security and Misinformation: Session Cookie Stealing is Not Responsible for 60% of Hacks appeared first on MalCare.