Session Hijacking, Stolen Cookies, and the Blind Spot in WordPress Security | Robert Abela

Thank you for coming. A quick raise of hands. Who likes cookies? Here. Nice. Nice. Here. Some more. Um, they have milk and nuts. So, if you have an allergies, be careful. Thank you very much for coming. Uh, let's set up this scenario right away. Imagine an attacker has access to your WordPress website and they have never guessed your password. broke your 2FA or bypassed your firewall. How is this possible? Basically, uh attackers, malicious users like you, they crave cookies because by stealing your cookies, they can hijack your session. They can impersonate you. There are many techniques that they can use and all of those are derived basically from user mistakes and exploiting vulnerabilities in software. this happened. Uh this is not just me saying it or exaggerating or scaremongering. These are some numbers from some reports from this year and last year. This year in Spy Cloud 2026 identity exposure report they captured roughly 8.6 billion stolen session cookies in 2025. recorded future identity threat landscape report they identified 276 million credentials with active session cookies usable to bypass MFA and from this year's Red Canary report they claimed that identity threats accounted for 53% of the total detection volume in 2025 which is up from 20 20% in 2024. So we are seeing a huge rise in these type of session hijacking and identity theft. This happens because cookies are credentials. So when you log in to your WordPress website, it generates a number of cookies. These are stored in your browser and basically that is that's how WordPress recognizes you and your session. In fact, most probably you've heard that WordPress is a stateless application. It is actually a stateful application. Stateless means that there's nothing common between the client and the server, the web application. However, when it comes to WordPress sessions, you have the session ID stored in the WordPress database and the cookies stored in your browser. And that is something in common and that is your session. And basically, whoever has those cookies can impersonate you or can trick your browser to do something with those cookies. WordPress the idea of sessions and cookies. It's not just it's not a WordPress problem. It's the the concept of sessions and cookies is used is how web applications sus online services work. Uh but the reason why I wanted to do this talk is because there is lack of control and visibility in post login security in WordPress and that is a blind spot in security. a quick overview of what we're going to cover in this presentation. We're going to see how WordPress authentication works, how sessions are stored and how they work in WordPress and what the risks are. We're going to see a few examples of high how sessions are hijacked and what we can do to protect these sessions and improve visibility. Let's start right away with authentication. Once you log into WordPress, so you go to the login page, you enter the username, password, and hopefully a FA code. WordPress creates a session token and it stores it in the database and it creates a number of cookies, session and authentication cookies and it sends them to your browser. These are the cookies. We have WordPress WordPress security. The first two are the authentication cookies. We have two for backward compatibility reasons for legacy reasons for when we used to access the internet over HTTP and we used to access the back end over HTTPS. In fact, one of them is basically an admin context HTTPS check. So we can work with one but of course because of all the websites we maintain both. The WordPress logged in basically is the session cookie for the front end. So when you are logged into a website and you browse the homepage and you see that admin bar at the top that's basically you can see that one because WordPress recognizes the session cookie and in each of these cookies you can find the username the expiration time of the session the session ID and the hmac this is an example of a cookie uh that's the cookie name you have the WordPress logged in and the hash the hash is a MD5 check sum of the website URL it's basically an identifier for the cookie. Then we have let me see here. Yeah, this is the username. You can see the username, the expiration time, it's in Unix time stamp. The session token, it's uh WordPress doesn't store the session ID as a as clear text in the database. It uh it hashes it in SHA 256 just uh just in case the database is leaked basically. And we have the HMAS signature which is basically hashbased message authentication code. It's a signature and it's generated basically from the username. Just a second. Sorry for that. Is generated from the username, a fragment from your password, the expiration time, the session ID and the WordPress s. And we use that one. So if any of those change basically that cookie is no longer valid and this session is terminated. It's a sort of security check. In fact it's very common uh if it's one of the best practices if you suspect you have any issues with some sessions maybe some some one session was hijacked or you're not sure if you change the WordPress results in the WP config file it basically invalidates all the cookies and all logged in sessions are no longer valid. The session tokens are stored in the WordPress database and they are stored in the user meta and you get one session token for every user session. So if a user logs in the same user logs in from multiple devices it gets multiple session ids and basically this is how it's stored in the WordPress database. It's a PHP serialized array and if we un serialize it that's how it looks. You have the hash session token ID SHA256, the expiration time in Unix of the session, the IP address of the client, the user agent of the browser and the login time. And basically whenever you are logged into WordPress and you click somewhere, the browser as you can see send the cookies with that s with with that request and that is how WordPress identifies who you are and that you are logged in. Here's a quick summary of what we discussed. So you log into your WordPress website. The user logs in. Just move those here. There username, password, and to FA for example. WordPress authenticates the user, confirms the password to FA code. It creates the session token. It stores it in the database. It creates the cookies and it sends them to to your browser. The browser stores these cookies and with every request sent to your website basically it includes those cookies so WordPress can identify you with every request WordPress validates the cookies check the session token and if all those match then the user is it means the user is authenticated. Now uh these are some properties about the WordPress sessions. So first of all the same user can have multiple sessions at the same time. This means a user can have 10 20 30 sessions. Uh so if the username is shared between a number of people this happens quite often and also sessions expire after by default after 48 hours or when the user logs out. Now from my experience most people don't log out. They just close the browser window and when you close the browser window the session is not terminated. So let's say you have logged into your website, you've done four hours of work, you close your browser window, that session and those cookies are still valid for 44 hours. It can also there's the option of having the cookies expire after 14 days. So when you go to your WordPress login page and there's that option remember me, if you take that one, then the cookies and the session are valid for 14 days. There are number of pros and cons to this approach. Uh however of course the advantage is users have to login less often. However this one the session duration and the fact that users can have multiple sessions also has introduces a lot of security risks. So basically every session is an authenticated identity an access point and unfortunately a possible entry point to malicious users. the the more sessions you have and the longer they are, the larger is the attack surface of your website and the more difficult it is for you as a website owner or for someone who manages website to track or spot suspicious activities. But that also means it's easier for the attackers because they have more time to do their job, try to hijack a session and to hide their activity. So roughly that's how the WordPress authentications works. And now we're going to see how attackers can steal and compromise sessions. Uh what I'm going to mention a few things. Not all of the things I'm going to mention lead directly to hijack to a hijack session. However, all of these together of course they uh they grow the attack surface for the attackers and they can lead to a lot of issues with with session hijacking. We start with the most common one shared accounts. Unfortunately, it's very common. You see it a lot of at agencies for example or bigger companies where 10, 20, 30 people in the same team use the same username and password to login to the website or agencies using the same username and password to access all of their client websites. That's one of the issues we have lack of security hygiene basically uh people not using password managers unlocked laptops. I travel to a few conferences. Even just yesterday, I was at the contributor day. I was surprised that you always see quite a few unlocked laptops and then attended on tables. It's just a perfect recipe for someone to take over your session. Uh logging in public computers or other devices. This might sound something old like from the internet cafe days, but it's not. Uh nowadays, especially people are traveling more uh and they need to log into the website. They forgot to charge their mobile. they forgot the laptop at at home or in the hotel room. So they ask a colleague or someone they know at a conference to login from their laptop to check their website or do something. And all of these basically is just a recipe. You are creating more sessions and you are growing your attack service. This goes hand inhand with what I just mentioned like you have infected computers with malware, malicious browsers, key loggers that steal data from computers. So the more you log in, the more sessions you have, the more devices you use, etc., the bigger is the attack surfaces and the bigger the chance of your sessions being hijacked. You also have issues like browser browser profile theft and also stolen devices, physical stolen devices. Uh with stolen devices, it's important to point out sessions work with cookies and Chrome and other browsers actually encrypt the cookies, which is a good security uh technique. So basically however it encrypts the cookies when at rest which means when the machine is switched off the cookies which are actually text file on your hard disk they are encrypted. So if someone steals your laptop and tries to re the hard disk at least the cookies are encrypted. So we have some sort of protection there. Other dangers public Wi-Fi and networks packet sniffing man in the middle attacks. It's also becoming very common for evil twin Wi-Fi hotspot. So basically this means someone sets up a Wi-Fi hotspot that looks legitimate. So let's assume you go to hotel X, their Wi-Fi is called Hotel X and the malicious user set also sets up a Wi-Fi called Hotel X and they can capture your traffic. Now nowadays we browse the internet over HTTPS. So your traffic is encrypted. However, there are many ways, tips, tricks that attackers can use to trick your browser to either communicate over HTTP or to use a less secure uh encryption protocol like SSL. These are called SSL stripping, HTTPS downgrade tech, etc. Are there things that leads to session hijacking, fishing get tech? We have the good old fishing text just stealing credentials. However, there's also a rise in adversary in the middle fishing attacks. These type of attacks basically work like the first one, the old fishing attacks where they credentials. Nowadays, if you are using tofa or some sort of MFA, they don't work. However, the adversary in the middle, they also work with MFA. The idea is the attacker sets up FA login page between your browser and the website and it's a reverse proxy. So it it receives the information from you. It forwards them to the website and it captures your session details. Here's an example. So let's wait here. There. So this is your browser. Someone sends you an email to log into your website. Uh it looks exactly like your login page. This is the attackers reverse proxy. Basically you submit your credentials and the reverse proxy forwards those credentials to your actual website to the legitimate website. If the credentials are correct and you are using TOFFA or some sort of MFA, the website responds with the prompt back the attackers proxy responds to your browser and you're going to see the 2FA prompt. So for you everything looks legitimate. You fill in the 2FA code. It goes to the attackers reverse proxy. It forwards it to the website. Now WordPress has seen everything is legitimate. It received the login credentials. It received the 2FA code. So it authenticates the user. It generates the cookies and the session ID and it sends the cookies to the reverse proxy. The attacker keeps a copy and forwards you the cookies as well. You are redirected to your website. So to you everything is transparent. You just log into your website. However, the attacker has a copy of your cookies which means from no one they can basically impersonate you. The said reality about these things is you don't need to be uh you don't need to be some security experts. The we have nowadays commodity toolings. There are also SUS online services for these things that allow um attackers to set up these attacks. All you need is just a conferencing email and the link. You can buy actually you can download software for free or you can buy software for a few hundred to launch these type of attacks within just a few hours. Other issues that lead to session hijacking outdated and exploitable software as we all know plugins themes WordPress any software quite frankly there's no 100% secure software every software has or can have vulnerabilities uh but unfortunately even though vendors keep their software up to date whenever there are issues users take time to update their their software uh we look at our plugins for example it's very when we release an update, uh, only around 20% update their plug-in within the first 24 hours. Within one to two weeks, it's around 40%. The rest, it can take unfortunately months and even years sometimes. So to exploit a vulnerability, you don't need to find some zero day exploit. Most people run old software. So yeah, you just need to find a vulnerab a vulnerable version of a plug-in that is just two or three versions old. That's all. Also on top of this one, uh people use null plugins and null software, correct software. And whenever you use this type of software, you have no idea what type of backd doorors it has or what type of other malicious code is running on it. And we're also of course a lot of people are using AI to build their own plugins and software. Now there's nothing wrong with AI. We use it as well. However, if you don't have certain level of experience and you know how software works, the chances of you developing something that is actually opening security doors on your website rather than closing is is very high. So all these basically lead to a lot of issues on websites. Talking about exploiting vulnerabilities, I'm sure most probably heard this one that by exploiting across scripting vulnerability attackers can steal your cookies. In the case of WordPress, this is not exactly correct. Uh kudos to WordPress because WordPress sets the HTTP only flag on the authentication cookies. What this flag does basically it tells the browser that client side scripts cannot access these cookies. So regardless if it's if you if you access a website and there are client side scripts regardless if that script is legitimate or not these the authentication cookies of WordPress do not show in the document.cookie so they can never be stolen. So that's again another security uh hardening that we have in browsers that we have that in cookies that helps kind of like mitigating these type of attacks. However, this doesn't protect from cookies being sent and this is where CSRF or session writing comes in. CSRF stands for cross- site request forgering and what it does basically if a plug-in or a software is vulnerable to CSRF. The attacker basically can trick your browser. can trick you to brow to access a website and that website tricks your browser to send a request to your WordPress website to do something malicious. So for example, let's assume uh a malicious user knows you are running a vulnerable plug-in, a plug-in that is vulnerable to CSRF. They send you a link to a page where there's an image or some text. But this page on it there's a hidden form that creates that when triggered this form creates a new user on a WordPress website. Um so basically uh and it automatically this form is automatically triggered when you load this page. So if someone if you are logged into your website someone sends you an email and you click on this page for example let's say of an image or something this is how it works. uh you click on the link, you access the malicious website. There's maybe on it there's content that that you want to see, some text or an image. However, as soon as you click on it, this website loads and triggers also the hidden form. That hidden form tricks your browser. Let's say the form creates a new user on WordPress, tricks your browser to send that request to your WordPress website. Now because you already logged in to your WordPress website, the browser is going to include the cookies with the request. So to WordPress, everything is legitimate. It received the request from your browser with the correct cookies. You are logged in. So it's going to do what the form is telling it to create a new user. And at this stage, basically the attacker can access has has uh created a new user on the website and can log into your website using these type using that account. It doesn't of course it's not it doesn't depend only on one security issue. So it's very common as well there are a lot of attacks where attackers use a number of security issues to achieve what they need to achieve most actually especially when it comes to bigger attacks it's not just about a cross-ite scripting or an SQL injection it's adding them together to achieve something bigger basically um in fact that is why we need to take a more holistic approach towards WordPress security for example we've mentioned HTTP only for the cookies which protects them from being uh stolen during a cross-ite scripting attack. Chrome encrypts cookies. We have firewalls to have we have a lot of things when it comes to hardening and type of security protection. However, each of these things they block only one thing. They they they have a purpose. There is no solution that blocks everything. In fact, security is not a switch that you flip. It's an ongoing process and it's usually using a collection. you need to use as a a collection of tools because it's about layers. Similar example, if you look at old classes, usually they are built on a hill. If they are not on a hill, they have a moat around them, but there's also the bridge. They have several layers of security. They have the bastions, several layers of walls, the towers, etc. So, and security is the same. There's no one solution that is going to stop every type of attack. And all of these, we've seen all of these issues that can lead to session hijacking. Um, however, all of these depend on one thing. They depend on the weakest link, which is as humans, they depend on a human clicking something, accessing an uh downloading an attachment, executing a file, accessing a web page, etc. Um, so this has to be solved as well. And the targets, the reason why the targets aren't only um administrators. Actually, attackers can still achieve, especially by exploiting a chain of of of vulnerabilities, can still achieve a lot by uh hijacking even non-admin accounts as we're going to see later. By the way, I've see I see it a lot like PE when I'm talking to people like, "Hey, we're a small team. We're five, six developers. We know not to click. No one everyone knows not to click on a weird link. That is not control. That is hope. Unfortunately, that that that doesn't work. Um it happens to the best of us. Uh these type of issues happen to support teams at Twitter, Microsoft, Facebook, um Troy Hunt, a very popular security researcher, the owner of Have I Been Pond? Funnily enough, last year was a victim of a fishing tech and had his mailchimp list stolen. The reason why we're seeing these type of attacks basically is we are getting better at hardening like fire was technology to have fus keys. Things are getting better. We're still not there yet but there's more adoption of these things and it's no longer worth it for the attackers to try to find some security hole in a firewall. um the the they are targeting the weakest link which is humans and AI is making it even much easier because with AI um it's making it easier to build attacks to build very credible attacks and which are very hard to identify. In fact there I've even heard jokes I was at cloud festival earlier on this year and there was a security expert joking that nowadays uh fishing emails are actually more realistic than the actually legitimate emails. Um and you can by because of AI you can build your own scripts very easily and this software software to launch any type of fishing getex and scanners etc has become commodity software and also because of AI it's working against us because we are getting we are no longer troubleshooting things we are no longer challenging our minds so our our um cognitive abilities are being lowered so the chances of us be becoming victim of these type of effects are much higher. Now, if someone hijacks an admin session, it's basically game over because they have full control to the website. Um, and very often what they do in this case is create another account or install a back door which is not even part of WordPress, a PHP application, an independent web application and they retain access. And the idea is whenever someone hijacks a session, they don't want to interrupt the current session. Otherwise, they you will notice they just leave that session and they want to operate in the background. Um, however, it's not just admin accounts. Even if they hack a non-admin account, there are a lot of things that attack the attackers can do. So, for example, if you look at an e-commerce solution, if they hack an a customer account, they can do a lot of things. Now I know of course the hardening of an admin account should be much more than that of a customer account. However, it's very important to keep visibility on everything on the website because let's assume someone manages to hijack a customer account on an e-commerce website. They can do reconnaissance which means basically it allows them to learn about your business, how your team operates, what systems you're using, how your team responds to certain things etc. And that basically makes it much easier to uh learn about internal visibility about your team, what what vulnerabilities you have on your website, maybe you are running an outdated version of some software. But also it makes it also easier for social engineering at text because if you or your team you have an e-commerce website for example or a membership website, if you receive this random fishing email, most probably recognize it. However, if you receive an email that mentions the customer name, the order details, etc. because they have hijacked that session. So, they know what that customer is doing, it's more credible. So, the chances of you falling for these type of attacks are much higher. There's also vulnerability chaining something that we mentioned before. So, if if they know of a certain issue, they can use a number of issues together and the social engineering get tech to achieve what they want to achieve. This happened in the past. I remember this particular case um on apach.org. The the Apach is one of the world's most popular web servers where malicious users identified this happened a few years ago but identified that they are using a vulnerable web- based bug tracking system. It was a bit outdated. It had a cross-ite scripting vulnerability. So someone posted a ticket, a support ticket pretending they're a client. They had some problem. The support people clicked on the link, their sessions got hijacked and within a few hours the attackers by accessing the support account uh the account of the support people I through that they identified other vulnerabilities on the the system they use a number of social engineering get tax and within a few hours they managed to gain root access to the main apach to the main apach.org servers. So that's why it's very important to make sure every account, everything that's happening on your website, you need to be aware of what's happening. Um, and hijack accounts, especially on WordPress, they go unnoticed because there are no login alerts, there's no visibility of live sessions, no logs, there are no controls and checks and sessions remain valid for very long. Uh, this is not just a a problem with WordPress. It's it's very common. You hear even of big brands where they identify a hack and they find out that they've been hacked for six months or for a year for example. It happens to everyone. I was just talking to Franchesco Carluchi. He's a bug bount hunter uh in WordPress and who was telling me how one of his customers they were doing this SEO test on their website using AI and AI identified some weird links basically and they asked Franchesco to look into it. Uh and he logged in and based on what he saw in the logs this website has been hacked for more than a year. And the reason why he knows that because the the website only had logs for about a year and even from the beginning of the logs this website was already hacked. So most probably the attackers have had access to this website for quite a few months. And the reason this happens is we focus a lot on hardening which is very important. There's nothing wrong with hardening you know credentials hygiene pass keys brute force protection firewalls keeping patch management that's all very important. However, there's yeah there's a blind spot when it comes to post login security. We focus a lot on what happens until the user logs in until the login page. But after that, we are ignoring it. We don't know what active sessions there are from where users are logging in, what devices they are using, etc. Now, I'm going to mention a few best practices and things we can do on WordPress. All of these you can achieve with a number of different plugins, free and premium. Uh let's start. um activity logs. So basically activity logs allow you to keep an eye on what's happening. They also allow you to do forensic work in an unfortunate event of course. But most plugins they also have notifications which allow you to set up notifications which is very important. So basically with activity logs you can actually build an ID intrusion detection system for your website which means a system that alerts you whenever something unusual happens. A lot of people ask me usually like what type of notifications should I set up on my website. It's very hard to answer because every business is different. You can have a business with 10 people who log in from the same location from Monday to Friday 9 to5 from the same office. But you can also have the same business 10 people but they all work remotely from different continents. So you have people logging in at different times. So if you are responsible for the security of a website, it's up to you to learn about the business, how the website is being used, etc. to to configure the notifications that you need. It's very important because if you configure a lot of notifications and you get a lot of false positives that will lead to to a cribal situation. It happens. It happened to me in the past. We used preg Google era. I used to work for a big software company. We used to manage the web servers and we had this monitoring server uh that used to send us an SMS whenever a server is down. Unfortunately the connection of the server wasn't very good. So we used to receive these SMSs quite often and after a few times we started ignoring these SMSs. One day the server one of the servers went down 40 and we found out from the management which wasn't a good idea. So um other things we can do session management. There are plugins and tools that allow you to see who is logged in in real time to your website. We can also limit concurrent user sessions. As I said before like users can login as many times as they want. Like if you have a user called Robert, it can be used as many times as they want. There's no point in that. Maybe you can allow two three concurrent sessions. Maybe someone has a laptop and a mobile and maybe a tablet. But there's no point in having more sessions. If you have a user account that is used by multiple people, every person should have their own user account. This is not just about security. It's also about accountability and compliance and many other things. You can also implement use tools to implement inactivity timeout. So basically there are tools and plugins that when you log in and that user does something on the website but then doesn't do anything else after an hour or two, there are plugins which terminate those sessions. And of course, it's highly recommended to shorten the default session duration. By default, as we said, it's 48 hours. There's no point. No one is going to work 48 hours straight. I would say best practice is to set it. A normal day of work is 8 to 10 hours. Set the session duration to 10 hours. It's not considering the tradeoffs. It's not a big ask to ask a user to login once a day. It's okay. Other things we can do uh user account management, delete active users. This is a very big problem especially on bigger membership websites, e-commerce websites and similar websites. Um it's also very common. Most of us I'm sure we've been through it. You needed to give access to a third party marketeteer developer designer on your website. You create a username for them and then you forget it. uh these these accounts are never deleted and unfortunately especially on membership websites and e-commerce websites most of these accounts are using the same email and password that that people use the same on on their Gmail on their Facebook and everything. So if any of these are ever leaked then you the chances of your website being hacked through these accounts is even much higher. So there are plugins which allow you to delete accounts that have never logged in for example since the last for the last 12 months for example. And if you need to give temporary access to someone you can also there are plugins which allow you to create a temporary link and you can specify when this link expires or how often this link can be used. Uh because creating users is very often as we said um you don't delete them. So by creating a temporary link someone can use this link they log in they do their job and then the the link is it expires after a certain period of time. You can also add security questions and to have FA to sensitive actions. For example, if someone wants to reset their password, uh if someone if an administrator is trying to change a user role, this like kind of like the same concept of sudo on Unix basically. Are there other things we can do with user accounts? Restrict user login times especially most people normally work they have a routine. They work from Monday to Friday 9 to 5. Um, so you can actually use plugins to allow users to login between, let's say, 8 am and 7 p.m. and then the rest they not allowed to login. As you're seeing, these are all different types of layers we're adding up to make it always harder for for the attackers. And last but not least, use custom roles and apply the principle of lease privileges. Uh, admin users with admin role. Of course, everything works. However, um, admin rights are not human rights basically. Um um so yeah so use the principle of lease privileges whenever you create a user whenever someone joins your team it takes a bit more time but work with them create a custom role for them and work with them to make sure they have access only to what they need to again similar to other things this is not just about security this is also about best practices about compliance about accountability and many other things and what we're doing here especially by using delete privileges, you are limiting the blast radius because if an attacker hacks an account at least he he he can only access what that user can access. Now as we have seen of course attackers can do much more even with non-admin accounts but the more layers we are adding the more difficult we are making it to attackers um and also basically by making it more difficult the the longer it will take them to achieve something. So the chances of you identifying any suspicious activities is much higher. Other things we can do device recognition there are again like other plugins which allow you to limit for example IP address uh and machine combinations. These are very common like especially if you use Google, Facebook and any of these services. If someone logs in for example from a new device you receive an an email like was this did you did you log in from this IP? was this and there are plugins actually which you can use which add trusted devices. So if there's another login from a different machine the user is notified. Um there's other other type of notifications we can do for example um if there are multiple simultaneous multiple simultaneous sessions etc. The more we notify the users I mean users are part of the whole they're part of the whole chain of your WordPress security. So the more the users are notified, the more the users are aware of what's happening, the the better it is for the the security of your website. Um whatever I've mentioned are technical fixes um which are very important. However, these technical fixes will only work if the human layer discovered as I was just saying. So it's very important to train your team uh train your team to recognize possible attacks. They don't need to be the next Kevin Mitnik or Adrien Lammo, but at least they need to know what's a fishing attack. What type of attacks your business can can can be victim of, what's a social engineering attack. They need to have basic understanding of what these type of attacks are. It's also important to encourage a reporting culture. We are all humans. We all make mistakes and we all have pride. So most of what everyone usually is afraid to admit they made a mistake. Um, however, if your team is afraid to admit they made a mistake, most probably you will find out from the attackers or from the news rather from them. And it's always better to find out from your team. This is very important, especially in bigger companies. I've worked in bigger companies and what happens is people spot things, but they don't know where to report them. So, they just ignore them and then it might be too late. So it's very important to train your team to know where to report certain issues if they spot issues and that it's safe to report something because everyone makes mistakes. And it's very important to also simulate fishing and other type of attacks. These type of simulations they should be like fire drills. Um they shouldn't be like I got you moment because people will make mistakes. You I everyone will make mistakes. The point is when you make these type of tests, everyone should learn from them. And the more you do these type of tests, the more your users will become aware of what's around them and what's their responsibility. This sounds a bit apocalyptic. Uh it sounds a bit extreme. However, unfortunately, this is the reality of having access to an online presence, having access to a website. It's it's every user is part of the whole security chain of your website. And last but not least, of course, follow best practices, credentials hygiene, lock your laptop, use password managers, use VPN services. Not sometimes. Use them always, unless you're in the office or at home. Always use VPN services. Um, only use assigned devices. Very important as well. Don't share devices. Don't log in from unknown devices or from some other people devices. And keep everything up to date. To recap, user sessions are an attack surface. So visibility is very critical. As we've seen, there's a lot of things we can do from the website point of view. Session management, website user accounts, device recognition, notifying the users, keeping them informed about their accounts and what's happening. And last but not least, education goes a very long way because as we've seen, all of these type of attacks basically depend on one human making a mistake, clicking something that they were not supposed to click. If you scan this QR codes, you can download the slides. There are links to the studies I have mentioned and the reports. There are also links to a number of other articles about authentication, cookies, WordPress sessions, how they work, etc. And there's also a list of premium and free plugins that you can use. There's a selection of plugins that you can use to achieve everything that we've mentioned. Thank you very much for listening. I'm Robert Abella and I'm the CEO and founder of Malapress. Yeah, if there's Yeah, there's there three minutes left. So, any questions? I've got a question. So, I talked about Claude and I'm thinking about AI in WordPress and people wanting to connect AI to their WordPress so that they can work in Claude on their desktop and have Claude do things in their WordPress account. And that requires some sort of authentication, right? Because the Claude agent needs to be able to do stuff in WordPress. And that means that there needs to be some credential there that is stored somewhere in a presumably secure way. I would love to hear you talk about what your thoughts are about how AI opens up this problem to a whole new realm of exciting uh security vulnerabilities and threats. >> Yes, most probably it will be my presentation next next year. But good point. Um yes first of all if you are connecting via rest API of course use application passwords it's very important there is the AI connector I was talking yesterday and even at work with David I think a core committer about AI because at the moment people are just putting the API key and let it run and that is basically a website a WordPress website with an API key to claude to whatever that's a gold mine um at the moment there are no limits but we were talking fact about possible solutions there's still a lot of unknown in terms of AI Okay, the only the most common thing is again the rest API using AI to connect by the rest API is make sure you use at least application passwords and and or use a dedicated account as well. Don't share the application password of your admin account for AI. The more you can segregate again permissions, the more you can split, the better it is. Thanks Chris. >> Hi, I'm Michelle. I had a question. So you were talking about if you change the salt in the WP config, it logs everybody out. >> Yes. >> What if you did that as a routine like at 2 in the morning every day? >> Uh I think there are plugins which reset it like at least once a month. I mean you can do it. The problem is there are especially if you are using application password and some accounts for some activity that takes much longer. you are logging out those users as well. Also, there are plugins like tof plugins which use those uh salts to create their own encryption keys for their users. So, whenever you're changing those you are resetting the configuration of the users. So, I I wouldn't I wouldn't recommend it actually. It's not like especially every day it's not a good idea. I mean if you suspect something is wrong of course do it but yeah whenever you're doing it you're you literally every session is terminated. >> I was just curious. >> Yeah, that's a good question. Yeah, >> thank you. >> Another one or >> Oh, we're done. Okay. Sorry. I mean, I I'll be I'll be around today tomorrow, etc. So you can find me around in the