Your Browser Already Logged Me In: My CyberHackCon 2026 Session in Baku
Reflections from my live session hijacking demonstration at CyberHackCon 2026 in Baku—and why browser session security matters after successful login and MFA.
Taking session security onto the stage in Baku
Presenting “Your Browser Already Logged Me In” at CyberHackCon 2026 in Baku was an opportunity to make an often abstract security problem visible. As a cybersecurity speaker, I wanted to move beyond describing session hijacking on a slide. I wanted to show the moment when a legitimate login becomes an authenticated browser session—and why protecting that session matters just as much as protecting the login itself.
A live demonstration changes the conversation. Instead of asking an audience to imagine what a stolen session might mean, you can follow the authenticated state through its lifecycle: creation, compromise, reuse, persistence and, importantly, termination. That was the focus of my session at this cybersecurity conference: connecting an offensive scenario to the defensive decisions that can stop it.
!Maria Mehwish presenting Your Browser Already Logged Me In at CyberHackCon 2026 in Baku.
Authentication gets you in. The session keeps you in.
We invest considerable effort in authentication: stronger passwords, MFA, passkeys and identity controls. Those protections are essential. But after authentication succeeds, the browser usually receives session material that represents the user's authenticated state.
The application then relies on that state to recognize subsequent requests. Depending on the design, possession of valid bearer session material can be enough to act as the authenticated user without entering their password or completing MFA again.
> “Authentication gets you in. The session keeps you in.”
That distinction was the foundation of the talk. Authentication is not the end of the security story. It is the point at which another important responsibility begins: managing the session securely throughout its lifetime.
A live session hijacking demonstration
The demonstration used a controlled lab application to make that responsibility tangible. The legitimate user logged in and successfully completed MFA. An authenticated session was then issued, visualized in the demonstration traffic, captured and replayed from a second browser. That second browser obtained authenticated access using the compromised session.
The sequence continued beyond the initial replay. I changed the password, then showed that the existing session remained active in the deliberately weak configuration. Finally, I explicitly revoked the sessions and demonstrated that the attacker's access was terminated.
Login → MFA → authenticated session created → session visualized in traffic → session captured → session replayed from a second browser → authenticated access → password changed → existing session remained active in the weak configuration → sessions revoked → attacker access terminated.
The supplied infographic summarizes the lab demonstration; its example screens and local addresses illustrate the session lifecycle rather than a production incident.
The attacker did not crack the password or defeat the MFA challenge. The legitimate user had already completed both. The session replay attack concerned what happened after those checks succeeded.
> “I don’t need your password. Your browser already logged me in.”
This was the point behind the session title—not a claim that MFA is useless, but a reminder that an authenticated session can become a valuable credential in its own right. Equally, password changes do not universally leave sessions active: that behavior depends on the application's invalidation policy. The weak configuration in this demonstration was intentional, not an unavoidable property of every website.
Where browser session security can fail
Session compromise can arise through compromised endpoints, information-stealing malware, malicious browser extensions, compromised browser profiles, or exposed and poorly protected session material. XSS may contribute depending on how an application stores and handles its credentials; adversary-in-the-middle phishing can also put authenticated sessions at risk.
These are different scenarios with different prerequisites. They should not be reduced to a suggestion that anyone sharing a network can simply read another user's session cookies. Properly implemented HTTPS prevents simple passive network sniffing from exposing encrypted session cookies. The lab's traffic visualization was not evidence that HTTPS encryption had been broken.
For cybersecurity awareness, this distinction matters. A credible explanation should make the risk understandable without making the attack seem magical or implying that sound transport security offers no protection.
Demonstrating the defense, not just the attack
I wanted the live cybersecurity demonstration to end with an effective defensive action, not simply with unauthorized access. Explicit revocation showed that the authenticated state could be invalidated—and that the application had to enforce that decision on subsequent requests.
The practical takeaways were:
- Manage sessions deliberately: use secure session management, rotate identifiers at authentication and privilege changes, and choose appropriate idle and absolute expiration.
- Protect cookies appropriately: use Secure, HttpOnly and suitable SameSite settings. These address different risks; none alone makes a stolen bearer session unreplayable. HttpOnly limits script access to cookies but does not eliminate every consequence of XSS.
- Reauthenticate for sensitive operations: consider the assurance needed for password changes, account recovery and other high-impact actions, with a clear policy for invalidating existing sessions.
- Make sessions visible and revocable: provide session/device visibility and explicit revocation that actually terminates server-side access.
- Monitor and protect the surrounding environment: investigate anomalous session reuse while strengthening endpoint and browser security.
MFA protects authentication. Session security protects what happens afterward. Both belong in a serious web application security strategy.
What I take away from Baku
For me, the value of presenting this topic live was showing offensive and defensive thinking together. The attack made the consequence visible; revocation made the response equally concrete. That balance is what I want people to take from my sessions, whether they build applications, investigate incidents or lead security programs.
The message I wanted to leave in Baku was simple:
> “Protect the session with the same seriousness as the login.”
If your conference or team would benefit from a practical conversation about identity, browser sessions and security, you can explore my speaking work or get in touch about speaking, cybersecurity training, research or professional collaboration.
More moments from CyberHackCon
!The CyberHackCon 2026 conference backdrop and sponsor display at the event in Baku.
!Maria Mehwish presenting on stage beside the authentication slides at CyberHackCon 2026.
!Maria Mehwish addressing the CyberHackCon audience during Your Browser Already Logged Me In in Baku.
