#110 – Thomas J. Raef on the Shift in How Hackers Attack, and How to Protect Your Site

[00:00:00] Nathan Wrigley: Welcome to the jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case how your session cookies are being used to attack WordPress websites.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice. Or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to WPTavern.com forward slash contact forward slash jukebox, and use the form there.

So on the podcast today, we have Thomas J Raef.

Thomas is the founder of We Watch Your Website, a company that has been removing malware from websites since 2007. During that time, he’s seen many changes in the methods hackers use to take over our website, and that’s the focus of the podcast today.

With hackers becoming increasingly agile in their tactics, targeting everything from plugins to session cookies, Thomas brings to the table data he’s gathered from 2023, that puts the spotlight on the evolving digital threat landscape.

He explains how the system that he runs is able to gather a very large data set about WordPress websites in real time. Recording data directly from the server, he’s devised systems, which makes sense of this data. He’s able to turn back the clock and trace the stack of circumstances which led to a website being compromised.

We’re all used to hearing that plugins themes, and sometimes the WordPress core, are the most likely culprits when something goes wrong. The story goes that out of date code, or a zero day is discovered and leveraged. Whilst Thomas does not doubt that this is true, he’s here to paint a somewhat different picture. A picture which puts the focus upon stolen session cookies as the most important factor in website attacks last year.

Thomas explains what session cookies are, and why they unlock so much potential for a hacker. He tells us about the ways that session cookies are harvested, and the ways that you can mitigate the problem.

If you’ve ever been concerned about the security of your WordPress site, or intrigued by the intricacies of cyber security, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Thomas J. Rafe.

I am joined on the podcast today by Thomas Raef. Hello, Thomas.

[00:03:29] Thomas J. Raef: Hello, Nathan. How are you?

[00:03:30] Nathan Wrigley: Yeah. Good thank you. Firstly, dear listener, I have to extend my sincerest thanks to Thomas. For reasons that I won’t go into, Thomas and I have had to cancel a podcast appointment on multiple occasions, and by multiple, I really truly do mean multiple.

So I just want to extend my thanks to Thomas for sticking with me. Coming back on many occasions only to find that a, I wasn’t there, or b, I wasn’t able to do the interview. So apologies for all that, Thomas, and thank you for staying the course. Really appreciate it.

[00:04:00] Thomas J. Raef: Not a problem at all.

[00:04:01] Nathan Wrigley: So Thomas is joining us today and we’re going to have a fairly in-depth conversation about security.

I know this is a topic that you’ve probably heard little bits and pieces about before, I think unless you’ve read the article that we’re going to delve into, I think it’s quite likely that you won’t have heard what Thomas has got to say. Now because we’re delving into security and security is a very technical thing and getting the right intuitions about security requires knowledge.

I think Thomas, it would be great if you could just paint a little bit of a picture. Give us your potted bio if you like, about who you are, what the company is that you founded and so on. Just so that we have some inclination that you know what it is that you are talking about.

[00:04:44] Thomas J. Raef: Okay, sure. Yeah. I started, I’ve been in the IT industry since, as I tell people, IBM has one month more experience in the PC market than I do.

They started, originally released the IBM PC in September of 81. And, I started working with PCs in October of 81. So in 2007, 2006, I’m sorry, I was working more toward security. More and more people were getting hacked. This was well after the I Love You virus and all the, popular ones. And I was just really inquisitive.

So got started in 2007 with the company that I founded, We Watch Your Website. Nobody ever asked me what does your company do? But, I started that company, it was to address the need for malware remediation on websites. That’s it.

People ask about, oh, my computer’s infected. Can you help me? I can, but it’s not, that’s not what we do. So at any rate, we started that. I started We Watch Your Website. Belonged to a website called Badware Busters, which was started by Max Weinstein, who I believe now is with Sophos.

He’s a Harvard grad. Google would send people to badwarebusters.org with their infected websites, get help for free. Daniel Sid, who founded Sucuri. And so I learned a lot, and started applying that to helping people with infected websites.

Got a call from Bluehost one day, helped out, Matt Heaton, the founder with his personal website, and they’re like, hey, how would you like if we sent you some business? And I was like, oh, okay. And for the longest time I was their default to go to for infected websites, so that I learned a lot.

Had to automate a lot because they were sending me so many sites, so much business. So I had to automate our procedures a lot, but people also wanted to know how their sites were infected. So it got me down the avenue of reading, log files, and how could I record things and, infections in the database and so on, so forth.

So we’ve been doing this now since 2007. As of now, the day of this recording, we are now watching over 12 and a half million websites. Gives us a lot of data.

[00:07:06] Nathan Wrigley: Yeah, a very large amount of data. We’ll get into that. So first of all, dear listener, I think it’s probably a good idea if you are listening to this, to perhaps pause the recording and go and read an article, which is on the We Watch Your Website blog.

Now, had we been able to record this podcast episode at the first opportunity. We probably wouldn’t have been so far away in time because this article was written on the 3rd of January, 2024. So it’s not the newest one, but the information, I presume is still up to date and you are sticking by the conclusions that you made there.

And the article is called The Real Attack Vector Responsible for 60% of Hacked WordPress Sites. And we’ll get into what that 60% is, and potentially how it differs from what most people, I would imagine think is the cause of problems on WordPress websites throughout the world. But first of all, wanted to dive into the sort of technical details of how it is that your system works.

So you mentioned that you’ve automated a lot of things. You mentioned that there are gigantic amounts of log files being created all the time. But I wonder if you would tell us how your system differs from what typically most WordPress users will do, which is install some plugin. Your service is not that. So tell us what it is that you do, and how it differs from what a plugin can do.

[00:08:34] Thomas J. Raef: Yeah. One of the problems with the security plugins, not all, is that it only operates at the application layer. So it can only see things, its way. On a VPS or a dedicated server or a cloud server like Digital Ocean, Vultr, et cetera.

We can actually install some agents on there that give us information at the network layer. Like for instance, one of the problems with a lot of security plugins that we’ve seen is they’ll see an attack from an IP address, but that IP address has been spoofed by the hackers because of the way the security plugin was written.

So our information is the raw IP address, like we’re seeing it at the network level of the server. Doesn’t matter if it’s WordPress or anything else, we’re seeing the raw IP address. So that gives us an advantage there. So, the information that we collect, on a live basis on a server based account is we grab the access logs live.

We’re also monitoring the database for changes live. We’re monitoring the files, they call it the file integrity monitoring is the term that they, they like to use. So we’re watching for any file changes on your website. And then we’re also watching the processes.

The processes run in memory on your server. There’s certain elements in the processes that can tip us off to an infection, or an attack. And for all these logs, like I said we’re, right now we’re monitoring 12 and a half million websites.

We have seven clusters that collect this data, and each of these clusters can collect 20 million log entries per second. And then it correlates all this information. So you log into a WordPress site, there’s an entry in the database, it only stays in there until you log out. Now if you don’t log out the information stays in there, but we want to capture it as it happens. So that’s why we’re monitoring the database live.

So yeah, you log into a WordPress site, there’s activity in the access log, where you came from, your user agent, things like that. You know what point you went to. Changes in the database. So we capture that as well. And our system has been designed to be smart enough so it knows a failed attempt versus, a session cookie. If you just close your browser and then you open it back up again and you’re still logged in, that’s because your session cookie is still active.

So we can tell that type of login versus you’re logging in with a username and password. We can see attacks, sometimes we see attacks before they’ve been announced. Other times, we’re just seeing them like everybody else is. So that’s the information that we’re gathering, and how we’re gathering it.

[00:11:39] Nathan Wrigley: I’m imagining a WordPress website. This may be a terrible analogy, but I’m imagining a WordPress website, a bit like a layered cake. And the front end of the website, I’m imagining is the icing on the top. So that’s the very top, and you can go down, and you get into the plugin space and you get into the admin space, and eventually you get into the sort of base layers of the cake. And at this point we’re onto the hardware and the software that the WordPress site is running on. So we’re thinking about the operating system that your host is using.

And from what you’ve said, and forgive me if I get this technically wrong, but it sounds like your system is able to access the lower down levels of that cake, the base layer if you like. Things approaching root access to the OS, things like that. So from that, it sounds like you can gather a different set of data than a plugin may be able to, and I guess your contention would be that because you are able to gather that different set of data, and it probably doesn’t have the capacity to be modified.

Once you’ve gathered that data in real time, you can then spend time looking back at that data in the days, weeks, months after. Patterns may have been discovered. You discover patterns and you can figure out what’s happened. So does that layer description work fairly well, with WordPress at the top, and the OS, the computer that it’s running on at the bottom, and you are injecting yourself as close to the bottom as you can?

[00:13:07] Thomas J. Raef: Yes. Perfect analogy. You summed it up nicely. Yeah, we’re working at the, at a range, and typically at a root level, where the username that’s running the WordPress site doesn’t have access to the stuff, as you described, at the lower layers that can’t get, that user doesn’t have access, doesn’t have permissions, authentication, to access the stuff at the lower levels of the cake. And that’s where we operate. We can’t be tampered with unless you have root access, and hacker has root access that’s game over.

[00:13:42] Nathan Wrigley: Okay. So that’s the first thing to notice. You are able to gather a different type of data than a plugin would do, simply because the plugin cannot typically, there may be scenarios where it can, I don’t know, but typically it can’t get outside of WordPress, so it can’t necessarily get to the operating system which is running WordPress. That might be Linux or whatever it is, but your system can.

If that’s the case, I’m presuming that if you want to use your service. It’s not a WordPress plugin. You are in some way getting access to the server. If I was to sign up as a client of yours, what would that process look like? Do you ask for SSH details from me and things like that?

[00:14:28] Thomas J. Raef: Yeah, basically. We typically provide our public key for SSH and you can install it, we can install it. And then that gives us the access, the accessibility that we need to implement our system onto your server. We watch all the sites on that server. It is just something with me from years and years ago, I couldn’t see why if I have access to all of your sites, why I should charge you per site. It never made sense, and that’s just me. I’m not saying my way is right. That’s just me. Yeah, we cover every site on that server and it’s just easier that way.

[00:15:03] Nathan Wrigley: So you are collecting data at this root level, in many cases I would imagine, in real time. And you said that could run on seven clusters of servers that you yourself have got. So it’s everything that’s happening on the server is reporting things in real time to you. And I think you mentioned the slightly jaw dropping number of 20 million. Log files could be written per second.

That sounds to me like a fairly unmanageable amount of data to look at. I’m imagining a spreadsheet with an additional 20 million rows added per second. And, I’m quickly realizing that no human can actually take any meaningful glance at that and get any data out.

So you talked about automation. Do you just want to get into that a little bit? What are you doing there? Because my immediate intuition here is that you are looking backwards in time to find problems that have occurred. So maybe somebody’s come to you and, something quirky is going on with my website.

Please, can you look back and see if there’s something that has happened? So is that what you are doing? Are you looking back in time to spot patterns? Or are you also looking for things happening in real time to prevent known let’s call it attacks for now?

[00:16:19] Thomas J. Raef: Both. For the report that we’re talking about today, obviously we went back in time. So we have a huge ScyllaDB database, that’s pretty much spread around the world. And so all this information is gathered and put into that database.

And then from there we can run our queries for these reports. Yeah, we can look back in time. But also, in real time, our system is watching for these patterns. Yes, in creating this report we did spot a number of new patterns along the way.

You dig in further there into your data, because you have all the data, and you can see that these patterns had started a year ago or so. And were repeating with different sites around the world. So, to answer your question, yeah, we do analyze things in real time, so we can see when a hacker or someone from a Digital Ocean server, let’s say. I don’t want to pick on Digital Ocean, but let’s say one of their servers was logging into your WordPress site. Now there’s a obviously a couple things that could be happening there.

Somebody could be using like a management console, like a MainWP, ManageWP, some of those, WP Umbrella. Some of those types of management systems. And that’s something you install on your own server and then it connects to your website. But, we know about those. Typically a server, or let’s say a GoDaddy server. Why would a GoDaddy server want to be logging into your WordPress site over and over again? And it has an outdated user agent. There’s a couple of red flags there. Those types of things we block, we filter in real time and block.

[00:18:05] Nathan Wrigley: Okay, so you’re spotting patterns for things that have happened and you are doing that after the fact. But you’re also gaining, I guess useful information from those patterns to create rules which can prevent things from happening. Because you can see this pattern is recurring. Okay, it’s now cropping up over here. Let’s block that traffic, because we know that is very likely to be malicious. The user agent is five years out of date, and it’s coming from a server that has no business logging in at all. It’s not an end user. There’s something quite strange here. And so in that way, you are preventing things.

Okay. I think we’ve got a vague handle on what it is that you gather, and why you gather it, and how you gather it. Obviously, if you want to reach out to Tom and talk about this, you can do, I’m sure by the end of the podcast we’ll have dropped an email or a contact form or something like that.

But I’m going to link back now to the article. Once again, it’ll be linked in the show notes, and I’ll give you the title again. The Real Attack Vector Responsible for 60% of Hacked WordPress Sites in the Year 2023. So we’re looking back at the previous year.

Now, I think that if I was to ask more or less, let’s say I had a thousand WordPress users in a room, and I was to ask them, what is responsible for the majority of problems with WordPress websites in terms of let’s say being hacked. I know that you didn’t want to use that word, but let’s just use it.

I think the intuition would be, it’ll be problems with themes, plugins and possibly, but not very often, Core. But plugins and themes. I think most people’s intuitions will be out of date or vulnerable, zero day problems with plugins from and themes. And you are saying no to that. You’re not saying that doesn’t exist, but what you are saying is that there is a much bigger attack surface, which I genuinely didn’t even know about until I read this article.

But you’ve got three types of attacks. Let’s just list those out quickly. We’ve got the first one is compromise username and password credentials. I don’t think we need to go into that too much. Obviously if you’re distributing your username and password everywhere, or it’s been part of the LastPass breach, we know that anybody can log in as you right.

Plugins and themes. We’ve just touched on that.

But you are saying that there’s this other thing, stolen session cookies, and your contention is that the majority, not just a small slice of the cake, the majority of problems, compromise problems with WordPress websites is to do with this.

So firstly, can we lay out the groundwork? What is a session cookie and how can it be stolen, and how impactful can the stealing of a session cookie be?

[00:21:01] Thomas J. Raef: A session cookie is required with http, https. It maintains your session basically, so that, if you’re on, let’s say you’re on an e-comm website, and you add some stuff to your shopping cart, and then you browse around the site, and then you come back to your shopping cart. And you say, oh, okay, yeah, I’m going to, order this stuff.

The session cookie is required so that it knows you from somebody else visiting the site at the exact same time, putting stuff in their cart. It keeps your session separate.

In the case of WordPress and our research in particular, a session cookie keeps you logged in, or shows WordPress that you are logged in with valid credentials.

So you go to your WordPress website, log into WP admin, enter your username and password. Hopefully it’s using some form of 2FA or MFA, to help you be more secure. But now you’re in, and as you’re bouncing around different pages, WordPress needs to know that, okay, yes, you are authenticated to go to this page and to do this activity.

And that’s all, that’s what the session cookie does. It’s a little piece of code on your local computer, on your local device, that your browser saves that tells the website that yes, you are authenticated to do these activities as an administrator on that WordPress site.

[00:22:33] Nathan Wrigley: Can I just pause you there and can we just delve into that a little bit more deeply? Because I, I know that there’s going to be a bunch of people listening to this who are very technically proficient and they’ll probably be thinking, Nathan, this is all very straightforward. But equally, I think there’ll be a bunch of people who, what you just described is not entirely obvious. So let’s just drill down on that.

So if I go to wptavern.com and I go to the login page and I enter my username and password and 2FA or what have you, and I’m now logged in. The WordPress website has then provided something to my browser. It is unique for that session.

So if I then go to another page or leave the browser window open and come back, let’s say in 24 hours, when I am browsing around, every time I try to do something new, go to a new page, add a new post, or what have you, that cookie is being requested and there’s a check going on to say, is this person allowed?

Do we have authentication to say that this person in the recent past logged in and we know them. And that’s happening all the time, right? Until we log out. And if we log out, that cookie is expunged, it’s deleted. And that’s the reason that if we go to, let’s say I’m in Chrome and I’m logged in successfully to WordPress, and then I open up Firefox and try to use my WordPress website, it won’t allow it. Because that cookie has not been lodged in the browser.

And if I was to open up a private or incognito window, the same thing. It’s a different silo. I can’t interact until I’ve logged in again. So this cookie, if you like, is the gatekeeper for my access until I log out. So the possession of that exact cookie proves who I am, and it’s the only thing, it’s the only thing which entitles me to use the website. So if I can somehow get hold of that cookie, and it’s not my cookie, let’s say I’m logged into your website. If I can get hold of Thomas’s cookie for his WordPress website, I can impersonate you a hundred percent you. No caveats, no ifs, no buts. I am you. Have I got that right?

[00:24:43] Thomas J. Raef: Yep, exactly. It is the key to the kingdom.

[00:24:46] Nathan Wrigley: So if that could be taken from me, all bets are off. As far as any machine in the world is concerned, any computer that I’m using at that moment, if I can get that cookie, I can be you. In the case of a WordPress website, I can then delete every piece of content that has ever been written on that website. I can deface the website in any way I see fit. If I happen to steal the session cookie for your Amazon website, obviously I have the credentials to go and use your credit cards and buy and, whatever it is that I wish. So this cookie really is, it is the gatekeeper for everything, and you are saying it’s being stolen.

[00:25:27] Thomas J. Raef: Yes, big time.

[00:25:28] Nathan Wrigley: It’s not trivial. It sounds like, stolen session cookie, it’s a, it’s a stolen session cookie. It sounds benign, but it really is unlocking complete access to whatever it is that user in WordPress is entitled to do. And obviously if it’s an administrator role, that’s a problem.

Okay, so the next thing I have to ask is, how on earth do I get your cookie? How is it possible that cookies can escape the confines of my browser? How can that be achieved?

[00:25:56] Thomas J. Raef: There’s a number of ways, and big thing if you really want to go down the rabbit hole, as Oliver from Patchstack likes to call things, you can Google the term info stealer, and you can see how big a market that is in the underground. Info stealers bypass antivirus programs, they bypass almost everything and they have access to your computer.

Let’s say, in our scenario here, you log into a WordPress site, you don’t log out, you just close the browser window, or you leave it open, whatever. You go to another website, your computer gets infected with an info stealer, first thing it, it does is grab all the information at can.

So it’s grabbing your bank information. Information about your computer, your browser, all sorts of information. But it’s also grabbing session cookies because those are, they’re easy to use. And, as you said the gatekeeper to so many things.

So it records all that information, and the info stealers start to use it in whatever way they can. And I was just reading a report yesterday where they said that within 10 seconds after an info stealer has infected somebody’s computer, it steals all the information that it needs, then it’s gone.

So it could delete itself so there’s no trace. So you, don’t think, oh geez, my antivirus just found this info stealer on my computer after I ran a full system scan. I should contact my bank. No, they don’t want you to think about all that. They want to be able to sell your information or use it themselves. So, 10 seconds, bam, they’re gone. They’ve taken everything they need.

[00:27:38] Nathan Wrigley: This then is an attack which is perpetrated typically onto the computer that you are using. So I’m sitting in front of my Mac, could be Windows, could be Linux. So it’s a vulnerability that somebody has discovered in the OS that I’m using. So Mac, Linux, Windows, what have you. We know how this works. There’s so many routes into this, but one might be that you accidentally click on a malicious link in an email and it takes you somewhere and you may be on a website, which looks like a legitimate website, but is actually downloading a payload and opening it up.

We don’t need to get into that, but have I got that right? This is something which is installed on your local computer. One of its primary things will be to consume bank details and all that, but also to just what browsers are there. Can we please have all the session cookies? We extract those, remove the offending software, and it’s like nothing ever happened. Again, have I parsed that about right now?

[00:28:33] Thomas J. Raef: Yep, perfectly.

[00:28:34] Nathan Wrigley: Okay. So I guess all the caveats around not clicking links in emails and keeping your operating system up to date, and the general hygiene of being a custodian of a computer. But you are saying though, that it will go into the browser, suck out all of the cookies, and from that moment on, if I, and we’ll just stick to WordPress from now on, if I haven’t logged out of my WordPress website.

And obviously if I’m a manager of a hundred WordPress websites, oh boy, then you could have a hundred WordPress website cookies in there. How long do I have for the attacker to go and do their dastardly work? I know that if I leave my WordPress website and I don’t click logout, at some point it logs me out. But I don’t entirely know what that length of time is. I have this intuition. It’s two days or 14 days or something. like that.

[00:29:29] Thomas J. Raef: You’re right on,both accounts. It typically, it’s 48 hours, from the time you logged in. But, if you click on the remember me, on your login page for a WordPress, the session cookie stays live for up to two weeks. Now, that’s only if you do not log out. If you log out, it instantly expires the session cookie. So it won’t matter if your session cookie’s stolen or not. It’s expired, so it can’t be reused, but so it’s 48 hours or two weeks.

[00:30:03] Nathan Wrigley: So that’s interesting. The one utterly mitigating factor here is that if you simply log out of any of these services, the WordPress website we’ll use again as the example. If I was to simply log out each time that I’d finished working, that cookie, even if it was stolen, it’s of no use.

They would be asked to log in again. So, okay, but, if I’ve clicked remember me, the attackers who stole the, let’s say I’m on the, website today. I log in today, I click remember me, and moments after I do that, by coincidence my computer is, all of that data is exfiltrated away from it. They’ve got 14 days to impersonate me, and presumably there’s the capacity for them to continue to pretend to be me beyond 14 days. Do they have the capacity to extend that 14 day window by, oh, I don’t know, going to a particular page which authenticates me again or something?

[00:31:01] Thomas J. Raef: No, originally that was my impression was that they could extend that time period. My friend Calvin quickly corrected me on that, on that little bit. So no, you can by going into the database. Once you have admin rights, you could go into the database and change things in the, in the database table, the user meta, and extend the life of the cookie. But, no. There isn’t any way that you can extend that. I recently, I corrected that in the article. You have up to two weeks.

[00:31:30] Nathan Wrigley: So how do you spot that this is happening?

[00:31:33] Thomas J. Raef: Obviously if you’re, If you’re logging in with username and password, you have to go to WP admin or WP login, and log in. With a stolen session cookie you don’t need to do that. The session cookie is active, non expired, however you want to call it. I could just go and access a URL of plugin install dot PHP, and give it the parameters that follow that, and it’ll install that plugin. I don’t have to authenticate.

And the thing about session cookies that I also want to mention right now is, session cookies are valuable because they bypass 2FA, because you’re already authenticated. It bypasses 2FA, MFA, everything. You’re in. So yeah, I could install a bogus plugin. I can install a bogus theme. Anything you can do in a query string, basically as an admin, you can do with a stolen session cookie.

[00:32:35] Nathan Wrigley: So in the logs that you are seeing then, is the way to see this that suddenly some entity on the internet just crops up and successfully requests a page that they shouldn’t have been able to access. So in this case, you were talking about installing a plugin.

The typical route to that would be to log in, but you don’t see any activity from that IP address, and what have you, going through the login process, and because that’s missing, you are then inferring from that, hang on. How can they have missed the login step? They must have used a stolen cookie in order to achieve this. Is that about right?

[00:33:18] Thomas J. Raef: Yeah. And being able to go back in time, as we mentioned before, gives us a lot of power because we can see, was there a login from this IP address? Now some people will say, IP addresses can change in the middle of a session, blah, blah, blah.

Yeah, but the way our system works is you’re not going to see a login, from Canada and then four hours, 4, 5, 6 hours late, whatever, have a login from Hong Kong. It’s virtually impossible. So what our system does is, it goes back and says, okay, when was the last valid login?

People say, you can’t tell that from a, from an access log. Again, access logs are not the only thing that we monitor. We also monitor the database so we can see who logged in, from where, with what user agent, so on, so forth. All that is recorded and kept.

So we can say, okay, John logged in from Canada on Monday, and we see that he used the username and login, and bam. So he logged in and now, a day later, somebody from wherever, Hong Kong, or from a server suddenly just went right to the WP admin slash plugin dash install dot PHP, with a long query string, telling it what plugin to install.

Plus you see in the database another access happening. So there’s a combination of things going on that when all correlated, paints a perfect picture of. Okay, this person, the person from Hong Kong, accessed with the session cookie, probably taken from John in Canada when he logged in the other day because it’s the same username, but now he’s in Hong Kong and they just installed a bogus plugin. So, it doesn’t take a rocket scientist to put all this together and say, yeah, okay, unequivocally, that was a stolen session cookie.

[00:35:21] Nathan Wrigley: So if you go to the article, again, it’ll be linked in the show notes. You can see there are some log entries written out, or there’s a screenshot taken of this exact process. So you can see what’s going on, and what I’m inferring from this is if you were to just look at a handful of logs, just two or three log entries, pretty much everything would look benign.

Any single log entry is going to appear broadly legitimate. Obviously if you’ve got a Chrome user agent dating back to, 2006, there’s probably something weird going on there. But broadly speaking, any one of those logs in isolation could be legitimate. It’s the picture that you are building up over time. You know the we had somebody in Canada. Now we have somebody in Hong Kong. They’re coming, they’re doing things, which it looks like they ought to have had to log in order to do. And you’re just building up this tapestry, this mosaic of different things and inferring, different things from that.

Okay, so I think we’ve got a handle with that. Now we’re going to go towards the sort of middle of the article, and this is probably where we’ll round off this conversation because, you’ve summarized the findings from 2023 and you’ve got a couple of charts. One is a pie chart, which spells things out really easily. And this pie chart is called yearly distribution of hack root causes in 2023.

And again, my intuition would’ve been plugins, themes, core, would’ve been the big slice of that pie. And your data is telling you that makes almost 33%. So it’s almost exactly a third, and I would’ve expected that to be significantly bigger.

Compromised logins, so stolen through stealing the computer or just getting into a LastPass vault, or just asking somebody what their user name and password was, 7.2%.

Now that leaves us with a remaining almost exactly 60%, almost two thirds is this stolen session cookie. So the takeaway that you’ve got is the vast majority of infections, hacks, whatever we want to call it, is coming via this mechanism. That’s fairly surprising. Was that something you expected to see?

[00:37:39] Thomas J. Raef: Not at all. I fully expected to see more of the core, plugin, theme vulnerabilities. This was originally intended to, a, to see exactly where the numbers fall. But also I wanted to, with no request, but I wanted to share this information with Oliver from Patchstack.

He’s got some valid data, a large amount of data, to show that this is how hackers are hacking is through vulnerable plugins and themes. But, yeah, it didn’t turn out that way at all. I was shocked, and I ran through the numbers so many times. I had to delay this report so many times because I was just like, no, this can’t be

[00:38:20] Nathan Wrigley: Yeah, because it’s not the intuition that we have, it’s not the received wisdom. It’s not what we see being talked about online in blog posts and what have you.

Interesting addendum to that pie chart though, is another chart which sits beneath it, and it’s more akin to a bar chart. But what it shows is that, if you were to take this month by month. So it takes that entire year and it divides it up into month by month, and you can see the data. And it does show that in certain periods of the year 2023, that intuition of it’s going to be plugins, themes, and core. That was in fact the case.

For certain periods of time, plugins, themes, core was the dominant problem. And for example, your data is pointing that in April, 2023, plugins, themes, core was the major problem. And can you correlate that to some sort of zero day, or some widely used plugin, or some core update. Are you able to match that against a widely known problem with an external third party piece of software like a plugin?

[00:39:26] Thomas J. Raef: plugin? Yes, right around that time is when the essential add-ons for Elementor was hit. That was huge. That particular point in time was right when essential add-ons for Elementor had a zero day, and hackers went crazy.

[00:39:41] Nathan Wrigley: Okay, so what we’re learning from that is, or maybe I’ve got my intuitions wrong, but also I should say that the same sort of thing seems to have happened in July, and we could get into what was the problem there. But it seems that from your data, the hackers are agile in their approach to this.

So in other words, if their primary vector during the year 2023 was stealing session cookies and there’s no major problems, no zero day exploits amongst WordPress plugins and themes. They’ll concentrate on the session cookie, because if there’s no big problems with plugins and themes, this is going to be our best vector of attack.

Then they’ll drop that, and go to the plugin, theme attack at the moment where that looks like it’s going to offer the best, I really don’t mean to say the word best, but for them at least, it’s going to be more useful for them to flip over to attacking that particular zero day in a plugin or a theme or whatever it may be. And so they switch. So they’re not stupid.

[00:40:42] Thomas J. Raef: They’re not. I tell people this all the time. I hate to give hackers credit, but they’re some of the smartest people in the world. I’ve said for years that if hackers ever focused on a cure for cancer, there’d be no cancer. These people are smart.

The people who write the code, there’s various levels of hackers and, they’re not all super smart, but the ones who write the code, they’re extremely smart and yeah, and agile. As you can see. Like I said, I’ve had other people ask me why do you think that they shifted so much to stolen session cookies? Because just Google info stealers, and you’ll see just a plethora of information. Entire company’s dedicated to tracking info stealers.

There’s a company in Israel that buys old computers from people, and they dissect these computers and find out that, how many info stealers are on these computers.

It’s a huge market. Some people say, oh no, it’s, that rarely happens. No, it happens a lot. And it’s not just my information, it’s information from many other security companies on how prevalent this is.

To me it lends credence to how effective something like a Patchstack is at preventing Infections through plugins and themes and core because, that’s what they do. That’s what they focus on. So to me hackers saw the writing on the wall. Okay more and more people are implementing processes and procedures to prevent us from hacking their core themes and, plugins.

So we have to shift our focus here, and okay, we got all these info stealers that are running rampant. We’ll just have them steal session cookies too. Because, when you think about the whole spectrum of computer security. How are most attacks carried out? Oh, through an infected website. Well, how do you get those? Oh, let’s steal session cookies. One just feeds on the other. So it’s a logical progression for hackers, and they need them for phishing, infected websites for majority of their attacks.

Steal session cookies. We don’t have to worry about 2FA. Seems like the whole world is starting to shift towards 2FA. Stolen session cookies bypasses 2FA. We get access to website. It’s like a perfect scenario for them.

[00:42:59] Nathan Wrigley: So we’re used to the mantra of update plugins, update themes, keep WordPress core up to date. And nowadays inside a reasonably up-to-date WordPress website, there’s the option to automate all of that. And there are, you mentioned things like MainWP and ManageWP and what have you.

There are these services which will assist you in that. But now we have this new problem of session cookies. Are there any bits of advice that you could give for remediating this problem? We touched on logging out as a really credible way of doing it, but is there anything else that you would advise a typical user of WordPress that they can do to, mitigate this? Because it does sound as if, if your session cookie is stolen, you really are putting your feet to the fire a little bit. So what can we do?

[00:43:47] Thomas J. Raef: Other than logging out, you have two good options. The first one is Fortress by Calvin. He controls, the whole Fortress, is a, like a login system, if you will. That’s putting it lightly.

But, it controls session cookies in a way that keeps them very short term, and forces auto log out and so forth.

The other option is SolidWP. Nice thing about SolidWP is they tie the IP address into the session cookie. So guess what? Somebody steals your session cookie, they’re going to go use it from Hong Kong, they can’t. It’s a separate, it’s a different IP address. Case closed.

[00:44:32] Nathan Wrigley: So there go. Three bits of advice. You’ve got a couple of services that you can use there, but also just log out. It’s a fairly surprising set of results that you came up with in 2023, and I guess on some level it is also, it’s kind of misery making in a way, isn’t it? Because it just demonstrates that the hackers are serious about this and they’re credible at what they do. And I guess it’s a process of just listening to advice from people like you and trying to stay one step ahead.

I guess you’ll be doing this again in 2024, and we’ll see if the, ground has moved. Let’s hope it has, and that slice of the pie that 66% has in some way gone down.

Thomas, if somebody wants to reach out to you and have a chat about this, talk about what it is that you do and what have you, where are the best places that they can find you?

[00:45:22] Thomas J. Raef: They can email me. It’s traef, traef@wewatchyourwebsite.com. They can find me on Skype, We Watch Your Website.

I’m on Facebook, as Thomas J Raef. You can ping me on Messenger. Like I said, I’m active in a lot of the Facebook WordPress groups, the admin bar, places like that.

Pretty easy to find. I always like talking. Ping me, look me up. Get a hold of me. We’ll talk.

[00:45:51] Nathan Wrigley: Thank you. Well, the ones that you mentioned, I will make sure to put into the show notes, but thank you so much for giving us that interesting information from the data that you gathered over the year 2023. Really fascinating. And Thomas, I appreciate you coming on the podcast and chatting to me today. Thank you so much.

[00:46:08] Thomas J. Raef: Thank you, Nathan. It’s always a pleasure chatting with you. Be well my friend.