Learn the basics

Everyone says: learn the basics! But how do you use them afterward?

For example, like this 👇

1. Base64 — an encoding algorithm that can encode any data as a sequence of English letters, digits, and a couple of special characters. It is often used to transmit binary data where only text is supported. Or for “obfuscation.”

It is also a legitimate way in PowerShell to pass code for execution via the command line (very convenient if you don’t want to struggle with escaping special characters).

2. Certificate Signing Request (CSR) — usually a file containing the user’s public key and some additional information describing the key owner.

A certificate signing request might look something like this:

   ----BEGIN NEW CERTIFICATE REQUEST-----
   something here encoded in Base64
   -----END NEW CERTIFICATE REQUEST-----
Code language: plaintext (plaintext)

Certificates, keys, and other similar data look similar. The header variants are described in RFC 7468.

3. The size of a file containing a public key certificate, private key, or certificate signing request mainly depends on the key length.

The current recommendation for key length is a minimum of 2048 bits. Keys of 3072 and 4096 bits are also encountered. One can imagine that an 8192-bit key might be used somewhere as well. And this is true for the RSA algorithm. For the ECDSA algorithm, which is being used more and more often, key lengths are an order of magnitude smaller; a length of just 384 bits is considered acceptable.

And now, when you’ve recalled the basics, you can easily and simply understand that a file which at first glance contains a certificate signing request but has a size of about 7 megabytes 😱 cannot help but raise suspicion.

For example, recently another suspicious email landed in our SOC. And we immediately realized that the CSR file lurking inside was not at all what it was trying to appear to be 👇

$ file notarealname.csr
notarealname.csr: RFC1421 Security Certificate Signing Request, ASCII text, with CRLF, CR line terminators
$ ls -lh notarealname.csr
-rwxrwxrwx 1 user user 7.3M Sep 26 17:35 notarealname.csr
Code language: YAML (yaml)

And when we looked inside the contents of this file, we immediately noticed that among the seemingly chaotic jumble of letters, here and there were identical strings of IDAw, and there were a lot of them (screenshot 1).

It seems the Universe is giving us some kind of sign 😀.

So what’s the deal here?

The answer is simple: it turns out the hackers decided to hide, under the guise of a certificate request, not just a binary with malware, but its HEX dump. And since the HEX dump of an executable file contains many spaces and zeros, the encoded form also produces a large number of IDAw sequences (screenshot 2).

Conclusions:

1. Learn and apply the basics.
2. Pay attention to signs.
3. Automate detection based on known indicators if you can 👇

P.S.

An idea for a YARA rule that can help detect such suspicious “certificate signing requests”:

rule SuspCertificateRequest {
strings:
$begin_1 = "-----BEGIN NEW CERTIFICATE REQUEST-----"
$end_1 = "-----END NEW CERTIFICATE REQUEST-----"
$begin_2 = "-----BEGIN CERTIFICATE REQUEST-----"
$end_2 = "-----END CERTIFICATE REQUEST-----"

condition:
(@end_1[1]-@begin_1[1] > 10240) or (@end_2[1]-@begin_2[1] > 10240)
}
Code language: PowerShell (powershell)

P.P.S

You can read about other ways to detect cases where hackers disguise malicious files as certificates in the NVISO blog.

#tips #yara #phishing
@ptescalator