T1111: Two Factor Interception, RSA SecurID Software Tokens

Introduction

During Red Team Operations, it is not uncommon to find systems or applications related to the engagement objectives being protected by Two Factor Authentication. One of the solutions that we frequently encounter is RSA SecurID Software Tokens. Strategies to circumvent or intercept tokens when faced with such deployments are therefore always desirable; this technique is described in MITRE ATT&CK T1111.

In this blog post, we will outline several potential approaches for intercepting RSA SecurID Software Tokens, including the approach that we opted for during our own operations. During the outlined scenarios, we assume access to the victim’s endpoint has already been achieved.

Extraction using Screenshots

Taking a screenshot is perhaps the straightforward option for token interception and is likely the first idea that would come to anyone’s mind.

However, there are a couple of downfalls. Firstly, we are assuming that the software is running and is visible on the client desktop. The second potential problem is that the user may have different configured tokens as can be seen in the image below:

As such, if we need to gain access to an account that is not presently visible on the screen, we need to interactively select the token. This approach is unlikely to be viable during a Red Team scenario.

Hooking Functions

Another potential approach would have been hooking the SetClipboardData function or the one responsible for drawing the token value on the screen. A potential risk with this method is that we need to inject into the current process, a technique that we try to avoid as much as possible.

This approach also isn’t as reliable as you might expect, with research showing that a lot of unrelated junk is present on the GUI functions and the SetClipBoardData function would only work if the user pressed the Copy button.

For these reasons, we decided to perform further research on how to extract the tokens in a more OpSec friendly strategy.

Analysing the Application

When reversing the RSA SecureID process in IDA it quickly becomes clear that the application functionality is relatively limited and only several functions were available.

After some analysis of the application, the following function was discovered:

The program was performing Signature Verification on the desktopclient.dll and then loading the library using the QLibrary::Load function as can be seen on the image above:

Since the main executable had limited functions, the focus switched on the desktopclient.dll library.

Loading desktopclient.dll in IDA, it was noted that it was making several calls to ole32.dll APIs. At this point it was highly likely that the communication was being achieved using COM.

Using OLEView .NET, we can see that two classes are available:

• RsaTokenService
• Token

OLEView .Net allows you to view a COM object type library (which is a binary file that stores information about object properties and methods).

The following interfaces were discovered:

[Guid("13a78cfa-ff65-4157-a90d-05afdb16f3c6")]
interface IRsaTokenService
{
   /* Methods */
   string getCurrentCode(string serial, string pin, [Out] Int32& timeleft);
   string getNextCode(string serial, string pin, [Out] Int32& timeleft);
   void displayHelpTopic(string topic);
   string getCurrentTokencode();
   string getNextTokencode();
   /* Properties */
   string Serials { get; }
}

[Guid("84652502-e607-4467-a216-be093824e90d")]
interface IToken
{
   /* Methods */
   void Init(string serial);
   bool IsPinValid(string pin);
   /* Properties */
   string serialNumber { get; }
   int otpInterval { get; }
   bool isPinRequired { get; }
   string url { get; }
   string userId { get; }
   string userFirstName { get; }
   string userLastName { get; }
   string label { get; }
   long deathDate { get; }
   bool shouldPrependPin { get; }
   string iconData { get; }
   int iconType { get; }
   int digits { get; }
   string extendedAttributes { get; }
}

Extracting the Tokens

On first glance, the methods described on this interfaces were quite promising and a test harness was created to call them to determine if they functioned as described.

To use this COM object, first add a reference of the rsatokenbroker Library:

After adding the reference, the following steps were followed for the token extraction:

• Create an Instance of the RSATokenService class
• Retrieve all the registered serial numbers of the tokens.
• Create an Instance of the Token class using the previously retrieved serial number
• Extract related information from the Token class properties like URL, UserId etc.
• Call getCurrentCode(string serial, string pin, [Out] Int32& timeleft);

RSA SecurID supports protecting the token by a PIN but in our implementation we didn’t have the opportunity to test this configuration further.

A simple C# program that extracts all the registered tokens and associated information can be found on GitHub.

Conclusions

Using the COM object provided us with an interface to extract the tokens in an OpSec safe way, avoiding injecting any process and calling any suspicious APIs. Having a software token, on the same device where the users’ credentials can be compromised is generally a bad idea and counteracts the benefits that many Multi Factor solutions provide. To mitigate against this type of “attack” we would recommend relying on hardware tokens, or using separate hardware (such as a mobile phone) for generating the software tokens.

This blog post was written by Rio Sherri.