NetScaler – Session Hijack Protection with Responder

Reading Time: 2 minutes


Quick Post about what is the hijacking of an authenticated NetScaler user session and how to protect yourself from it. This feature starts with 13.1 Build 53.17 and 14.1 Build 25.53

There are two cookies responsible for a User Session, depends on your usage of NSGW / AAA. They get issued after a successful authentication.

NSC_TMAS = AAA protected Webserver

NSC_AAAC = NetScaler Gateway

How’s the process of the cookie hijack looking? An example for NetScaler Gateway:

On Client1, browse to your NetScaler Gateway URL and authenticate. Go to Devtools and copy the Name of the cookie NSC_AAAC and the corresponding Value.

On Client2, browse to your NetScaler Gateway URL and do not authenticate. Go to Devtools, create a new cookie with the Name NSC_AAAC and paste the corresponding Value. Refresh the Page and you’re authenticated. That’s it.


What’s new in these Firmware to protect from that? NetScaler now maps every authenticated Session to Source-IP, so there’s a new expression called AAA.USER.SOURCEIP which can be used in Responder (which works on every license edition)

The config is quite simple, here’s an example for creating a short blocked page when someone is trying to hijack a User’s session.

add responder action RespAct_SessionHijack respondwith "\"This IP address (\"+ CLIENT.IP.SRC +\") is blocked to connect to this service.\""
add responder policy RespPol_SessionHijack "AAA.USER.NAME.LENGTH.NE(0)&&AAA.USER.SOURCEIP.NE(CLIENT.IP.SRC)" RespAct_SessionHijack

bind vpn vserver YourNSGW -policy RespPol_SessionHijack -priority 10 -gotoPriorityExpression END -type REQUEST
bind authentication vserver YourAAA -policy RespPol_SessionHijack -priority 10 -gotoPriorityExpression END -type AAA_REQUEST

Bind the policy to your NSGW / AAA vServer:

Bound Responder Policy to NSGW

Now when I try to copy the NSC_AAAC cookie of an authenticated User session on Client2, I’m getting the following page:


As this feature works on Source-IP, there are the following limitations based on the architecture:

  • NetScaler needs access to the public Source-IP of the User Session
  • Protection will fail if the Attacker and the Victim are both on the same network or rather accessing from the same Source-IP


With that short Responder policy, you’re able to gain a lot more safety for your NSGW / AAA environment. A must have!


  1. Thanks for this, it is a pretty scary exploit if I am able to do it.

    One thing we did was instead of popping a message, is instead do a redirect to the https://Gateway/cgi/logout page.

    We did this so that people that might sleep their laptops and then move from network to network wouldn’t get blocked and have to find and clear cookies. It also keeps any hackers from knowing that we have your remediation in place and keep trying to find other ways in.

Leave a Reply

Your email address will not be published. Required fields are marked *