Session Hijacking

What is Session Hijacking?

Session hijacking is an attack technique in which an attacker takes over an already authenticated session of a user or device by stealing, guessing or hijacking its session token (cookie, token or connection), so that they act with the victim’s privileges without logging in themselves. Because the attacker steps in after authentication, strong passwords and even MFA no longer help at that point. The victim usually notices nothing: the session simply keeps working.

In OT networks, a hijacked session can lead to unauthorised control of installations, altered setpoints or manipulated SCADA visualisations, with physical consequences.

🧠 How does session hijacking work?

Every session, whether a web application, an RDP connection or a TCP connection to a controller, relies on a secret that proves “this user has already logged in”. Whoever holds that secret is that user as far as the system is concerned. An attack typically runs as follows:

1. Legitimate session - an operator or engineer logs in to an HMI, a web portal, an engineering station or via remote access.
2. Obtaining the session token - the attacker intercepts, steals or guesses the session ID, token or connection parameters.
3. Takeover - the attacker reuses the token from their own system, or takes over the connection directly from a man-in-the-middle position.
4. Abuse - the attacker acts as the original user, without a new login and often without conspicuous log entries.

The difference from a replay attack is subtle: in a replay a recorded message is sent again, whereas in session hijacking the attacker takes over an entire running session and issues new commands of their own.

🔄 What variants of session hijacking exist?

The Firefox extension Firesheep made sidejacking on open Wi-Fi a one-click affair in 2010. In the years that followed, large sites made HTTPS the default for every page: Twitter in 2012 and Facebook in 2013.

MITRE ATT&CK describes these techniques as, among others, Remote Service Session Hijacking (T1563, with the sub-techniques SSH Hijacking and RDP Hijacking), Steal Web Session Cookie (T1539) and Browser Session Hijacking (T1185). In the latter, malware abuses the victim’s own logged-in browser session to reach internal web applications. With T1563 the attacker mainly uses the hijacked session for lateral movement towards critical systems.

🏭 Why is session hijacking especially dangerous in OT?

In OT environments the weak spots come together:

• Protocols without session security - Modbus TCP and classic S7 communication have no authentication or integrity checking. Anyone in the network path can inject commands into an existing connection; the PLC cannot tell the difference.
• Long-lived sessions - operator stations and HMIs often stay logged in for days under a shared account, so there is always an active session to take over.
• Unencrypted management connections - VNC, Telnet and HTTP are still common on older equipment.
• Remote maintenance - vendors work via VPN or RDP; a hijacked vendor session is a direct route into the process network.

🔐 How do you protect sessions against takeover?

For OT protocols without built-in security, add network segmentation, Dynamic ARP Inspection on switches and, where possible, secured protocol variants such as S7CommPlus or OPC UA with signing and encryption.

🔧 Which values and requirements apply in practice?

Concrete numbers help when configuring HMI portals, web interfaces and remote access:

In OT a short timeout is not always desirable: a control room that is logged out in the middle of an upset is a safety risk in itself. A common approach is therefore:

1. Split by function - short timeouts for engineering and administration sessions, longer ones for read-only operator screens in a physically secured control room.
2. Use screen locking instead of logging out, so the process stays visible but operating it requires a new login.
3. Actively terminate remote sessions as soon as the maintenance window closes, and allow no more than one concurrent session per account.

IEC 62443-3-3 covers exactly these points with system requirements such as SR 2.5 (Session lock), SR 2.6 (Remote session termination), SR 2.7 (Concurrent session control) and SR 3.8 (Session integrity). In the Netherlands, many OT operators have fallen under the Cybersecurity Act since 15 August 2026, which requires appropriate measures for, among other things, access control and secured communication. Session security is a concrete part of that.

🔍 How do you detect a hijacked session?

Combine logging in a SIEM with an OT IDS or anomaly detection that passively monitors industrial traffic. Also record which sessions are normal, so deviations stand out.

❓ Frequently asked questions

Does MFA protect against session hijacking?

MFA protects the moment of login, but session hijacking happens after login, so a stolen session cookie bypasses ordinary MFA. Phishing proxies such as Evilginx capture the cookie precisely after the user has completed the MFA step. Only phishing-resistant MFA such as FIDO2, combined with short session lifetimes and device binding, substantially reduces this risk.

What is the difference between session hijacking and a man-in-the-middle attack?

A man-in-the-middle attack is a position: the attacker sits between two parties and can read or alter traffic. Session hijacking is the goal: taking over an existing session. A man-in-the-middle is one way to hijack a session; cookie theft via malware is another that requires no network position at all.

What is session fixation?

Session fixation is a variant of session hijacking in which the attacker forces a session ID they already know on the victim. If the victim then logs in and the application does not renew the ID, the attacker shares the authenticated session. Issuing a new session ID after every login and privilege change prevents this.

Can PLC connections be hijacked?

Yes, PLC connections over protocols without authentication, such as Modbus TCP and classic S7comm, are vulnerable to session hijacking at the TCP level. An attacker in a man-in-the-middle position can inject commands into a live connection, which the PLC then executes as legitimate. Segmentation, ARP protection and secured protocol variants limit this risk.

What session timeout is sensible for an HMI?

For administration and engineering sessions on an HMI, an idle timeout of a few minutes is sensible, in line with the 2–5 minutes OWASP recommends for high-value applications. For operator screens in a closed control room, screen locking often works better than logging out, so the process view stays visible. Record the chosen values per role in the security policy.

How do you recognise RDP hijacking?

RDP hijacking can be recognised by a session that changes user without a matching logon, often carried out with the Windows tool tscon running with SYSTEM privileges. Monitor for use of tscon, for processes starting in another user’s session and for RDP traffic between network zones. Timeouts for active and disconnected sessions reduce the chance that a session is lying ready to be taken over.

📌 In summary

Session hijacking is a silent attack in which an attacker steps into a session that is already authenticated, so passwords and ordinary MFA no longer offer protection.

In OT the risk is high because of protocols without session security, long-running HMI sessions and remote maintenance by third parties. Protect sessions with encryption, strong and short-lived session IDs, phishing-resistant MFA, managed remote access and segmentation, and detect takeovers with logging and network monitoring. Related topics are Man-In-The-Middle, Replay Attack and Phishing.