Detecting Session Hijacking with LogRhythm’s Advanced Intelligence Engine

When a client authenticates with a Web application, a session is established. Usually a unique, pseudo-random session ID is generated and passed from the client to the Web application with each HTTP request that is made. This session ID might be passed as a request header, as part of the URL, or in the request body itself. 

In some cases, this session ID can be compromised by various means, and a different client can use it to hijack the session. OWASP does a good job explaining the attack: https://www.owasp.org/index.php/Session_hijacking_attack

How can LogRhythm detect when this happens? First, it’s important to ensure the session ID is being logged by your Web server. If it’s being passed as a request header (whether as a cookie or any other header), for both IIS and Apache there are options to log header values with each request. 

If the session ID is being passed in the URL, it should already be logged by default. Next, if you’re using LogRhythm, you’ll need to make sure that an MPERule is in place that properly parses out this session ID value into the field. 

Please contact us if you’d like LogRhythm Labs to help! The final piece is to construct an AI Engine rule that will detect if a single session ID is being used by two different clients. 

Create a rule with a Unique Values Observed rule block, group by , select “IP Address (Origin)” as the Unique Values Field, and 2 as the Occurrences. Set realistic time limits, and you should have a simple working rule. 

Please feel free to contact me if you’d like some tuning advice (there are some considerations in certain cases outside the scope of the blog post). While this certainly won’t catch session hijacking in every situation, it’s definitely a nice rule to have in your detection arsenal.