Hunting for Citrix Netscaler API Abuse: Reconnaissance, SSO and Session Manipulation

I worked a case recently where unauthenticated threat actors were able to access and perform reconnaissance and session manipulation in Citrix via API requests. These threat actors proceeded to abuse single-sign-on (SSO) for access. As such, I wrote this blog post to highlight some of the things to be aware of when hunting through Citrix logs that can hopefully help some security analysts when they're performing their threat hunts / investigations. Please note, how and whether this works depends on your clients Citrix configuration and settings.

The reason why this is interesting to someone in a blue team is because an unauthenticated attacker could potentially (depending on the Citrix configuration) do the following:

  • Enumerate resources available to a user i.e. what hosts they have access to and what method
  • Force sessions to last longer without signing the attacker out
  • Detect what methods of authentication are utilised (5 documented) and if SSO is enabled
  • Abuse SSO for access to resources 

Reconnaissance of Citrix as an Outsider

Non-authenticated users are able to send GET and POST requests to /Home/Configuration to fetch configuration settings for Citrix. In the response that the server sends back, the attacker is able to fetch some interesting pieces of information such as various APIs that can also be called to show further information. A snippet of a successful response is shown in in the screenshot below. As you can see, it has revealed information such as the various APIs that can be called when interacting with Citrix.

Of interest, are the APIs "Home/KeepAlive", "Authentication/GetAuthMethods" "Resources/List" (more on Resources/List and GetAuthMethods later on in the blog).

In the "Home/KeepAlive" an attacker is able to force sessions to be extended without being authenticated. This way, the attack flow works like this:

1. An attacker will query the /Home/Configuration Citrix API to attain information around what commands / APIs can be issued

2. The attacker will issue a command to Home/KeepAlive before authentication occurs to ensure that the attacker session can stay "X" amount of time. 

3. The server returns a 200 response code.

Hunting for API Authentication Events

Now, the attacker is ready to figure out how they want to authenticate to Citrix. To do this they need to send a POST request to the API /Resources/List and then send another API request to "Authentication/GetAuthMethods". This can be called from an unauthenticated user. This method will basically return all the authentication methods that are possible for the user prior to initiating the authentication event. 

The "resources/List" API will return all the resources that are available to a particular user. An authenticated session is not always required for this to return information. This will give an attacker an understanding of what resources are available to a user i.e. what hosts they can RDP / access. It will also provide the attacker further understanding of the URLs, method of access and other interesting information that can help an attacker further down the attack path. 

Here is where it gets very interesting, in the actual response that the server sends back - forced 2FA will only show the following two results. But if you get more than these two results, then things will become way more juicy for an attacker.

There are actually 5 methods of authentication documented by Citrix. And based on what method of authentication is allowed, they will show up in the response that the server gives to the request. These methods are as follows:

  • Certificate - Client certificate authentication using the API "SmartcardAuth/Login"

  • ExplicitForms - Explicit 2FA login only using the API "ExplicitAuth/Login"

  • IntegratedWindows - Pass through authentication (PTA) using the API "DomainPassThroughAuth/Login"

  • CitrixAGBasic - Automatic authentication via SSO - in most cases, no 2FA required using the API "GatewayAuth/Login"

  • PostCredentials - Posting user credentials to the proxy (2FA may not be required, this is not tested) - achieved through the API "PostCredentialsAuth/Login"

Hunting the Logs

These are just some of the APIs that can be abused. I am sure there are several other ones that can be abused and can elicit more information. But to share something that might help a blue team, I have included some cleaned logs that can show the authentication chain that occurred which allowed an attacker to bypass 2FA. Keep in mind that this is just abusing the SSO method and there are 5 methods in total that can be used. 

Below is a snippet of the attack flow and some of the things to hunt for in the logs:

  • POST /Citrix/<NameHere>/Home/Configuration - -
  • POST /Citrix/<NameHere>/Resources/List
  • POST /Citrix/<NameHere>/Authentication/GetAuthMethods
  • POST /Citrix/<NameHere>/GatewayAuth/Login
  • POST /Citrix/<NameHere>/Authentication/GetUserName
  • POST /Citrix/<NameHere>/Resources/GetLaunchStatus/<Resource-ID-Here>
  • POST /Citrix/<nameHere>/Sessions/ListAvailable
  • POST /Citrix/<NameHere>/Authentication/GetUserName
As you can see from above, there are APIs that have been called that I haven't fully touched on in this blog, but just to give you an idea - GetLaunchStatus tells you the launch status of a resource. The "Resources" path for the API as mentioned above, allows you to enumerate and understand the various resources that are available. The "Sessions/ListAvailable" lists out the available sessions (as self explanatory in the name).



Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?