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).

References:

https://developer-docs.citrix.com/index.html
https://docs.citrix.com/en-us/storefront/1912-ltsr/configure-authentication-and-delegation/configure-authentication-service.html
https://docs.citrix.com/en-us/citrix-virtual-apps-desktops-standard-azure/users.html
https://github.com/citrix/storefront-sdk/blob/master/docs/requests.md
https://www.citrix.com/blogs/2019/04/16/configuring-domain-pass-through-as-your-default-authentication-method/
https://docs.citrix.com/en-us/citrix-endpoint-management/rest-apis.html
https://support.citrix.com/article/CTX368624


Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more

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

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more