Finding uses of cryptographic functions and the data encrypted by an application

How to find cryptography implemented by an application in a esReven trace? Let’s explore two ways of doing so!

Looking for known symbol calls

esReven provides several features related to symbol calls:

• The symbol search feature allows you to look throughout the entire trace to find calls to a specific binary’s symbol. binary.
• The ltrace script displays all the calls to symbols from external binaries.

For example, Windows proposes the Cryptography API: Next Generation (CNG) for cryptography. We could look for calls to the bcrypt.dll!BCryptGenerateKeyPair function, that creates an empty public/private key pair for asymetric cryptography.

Using the Axion GUI, we looked for this function in a scenario where we recorded an HTTPS connection to Duck Duck Go, and sure enough:

Going to the first call, we can see that we are in the middle of what appears to be a system call. Let’s go back in our backtrace to retrace that system call.

Sure enough, we can go back to the TLS Handshake: see the call to the ProcessHandshakeCommon method.

Running the esReven ltrace script on the ncryptprov.dll binary:

we can get the following (filtered for brevity) interesting lines of output:

In this sequence of calls, we can follow what happens to the key with handle 0x2245ebaf4c0, from its allocation at #223512674 in BCryptGenerateKeyPair to its destruction at #228751171 in BCryptDestroyKey (we made sure that we had the correct BCryptGenerateKeyPair by looking at the memory pointed by phKey at the end of that call, using the GUI).

With both of the symbol search or the ltrace methods, if you already know the symbols corresponding to some cryptography implementation, then you can look for them in the trace.

But what about the cases where you don’t know the function names for crypto? This can happen while looking at unknown software, for instance.

In such cases, you can look for cryptographic constants in the trace!

Looking for cryptographic constants

A means of detecting the use of cryptography in a esReven trace is to search for well-known cryptographic constants.

For example, most symetric crypto algorithms use S-boxes to perform substitutions, and these are generally part of the algorithms, meaning that we should find trace of these giant constants in memory.

For example, AES uses the Rijdael S-box, which starts with the following bytes: “63 7c 77 7b f2 6b 6f c5 …”

As esReven allows to search for any pattern in memory in the whole trace, let’s turn to the esReven Python API and look for S-boxes in our recording of the BlueKeep vulnerability:

Running this script on the 1,484,521,602 transitions of our execution trace returns the following relevant transition numbers in around 10 minutes:

Let’s display the backtrace and current process for each of the detected transitions:

(output shortened for brevity)

We can find that most of these are calls to the key expansion routine of AES (the match at #1172460273 is a page handler that accesses the S-Box).

Closing words

What to do after finding evidence of cryptography in a trace? Well, depending on the context, just knowing some program performs cryptography and which algorithms are used can be invaluable information. From these points of interest, you can use the other features of esReven such as memory history or data tainting to find out what message was encrypted or decrypted, where it came from or went to (network, file, …), or look for some encryption keys.

For an example of extracting all the decrypted messages sent by a malware, you can take a look at the “Tracing network data back to encryption” article, that does that on PocoDown malware (in particular look around the 3:30 timestamp in the video).

Bonus

While preparing for this article, I had actually forgotten which of my scenarios had BCryptGenerateKeyPair calls in it, so I used the reven2.preview.project_manager API in esReven Enterprise edition to look for such calls in all of my scenarios. The quickly written code below allowed me to find the correct scenario.

Here’s a sample output:

The scenario of interest was called ddg_query.