Tuesday, May 21, 2013

MoVP II - 2.1 - RSA Private Keys and Certificates

Those of you who downloaded the Volatility Cheat Sheet v2.3 may have noticed a plugin named dumpcerts, which is a relatively new addition to the plugin scene for Windows. Its based on the work by Tobias Klein called Extracting RSA private keys and certificates from process memory. In short, you can find RSA private keys (PKCS #8) and SSL certificates (x509) by scanning for header and version constants found in the ASN.1 representations. The dumpcerts plugin for Volatility uses this scanning approach to find, extract, and parse these keys and certificates from physical memory (useful for determining which ones were found in unallocated/freed memory) or virtual memory (useful for attributing the key/cert to a specific process that was using it).

Here are a few reasons why you may use the dumpcerts plugin:
  • You have a memory dump from a system infected with malware that's using public key cryptography - and you need copies for evidence and/or decryption efforts. 
  • You need help proving or disproving that a private key was stolen from a victim machine (or used on a suspect's machine)
  • You want to scan for the presence of expired, revoked, or self-signed certificates in your memory dump 
  • You're looking for malware that uses stolen private keys to sign trojans (or to load kernel drivers on x64 systems)
Stuxnet is an example of malware that fits the criteria in the last bullet. It included two drivers that were signed with keys stolen from JMicron Technology Corp and Realtek Semiconductor Corp.  There's already a copy of an Stuxnet-infected memory image available from our wiki, so you can follow along if you like. 

To see the usage, call the plugin with the standard -h/--help option:

$ python vol.py -f stuxnet.vmem dumpcerts -h
Volatile Systems Volatility Framework 2.3_beta
Usage: Volatility - A memory forensics analysis platform.


  -D DUMP_DIR, --dump-dir=DUMP_DIR
                        Directory in which to dump executable files
  -s, --ssl             Use OpenSSL for certificate parsing
  -P, --physical        Scan across physical space (in deallocated/freed
Module DumpCerts
Dump RSA private and public SSL keys

The -D/--dump-dir=DIR argument is required - its the output directory for keys and certificates. If you have the openssl command-line utility installed, pass -s/--ssl to parse the extracted files with openssl (additional output will be displayed to stdout in this case). The -P/--physical parameter limits the scan to physical layers (i.e. the flat file, with no address translation or virtual memory analysis). Use this option when you suspect keys or certificates may exist in memory marked as deallocated or freed (which would typically not be accessed again by the OS before being re-allocated and overwritten). Sometimes the most volatile evidence can be found in physical space scans.

In the example below, we start off with scanning virtual memory and using openssl to parse the extracted keys and certificates. This tells you the name and pid of the process(es) in which the objects were found, the output file name, and the organization (O) and organizational unit (OU) field from the parsed certificate data. If you want to see other fields, such as the fingerprint, validity dates, or other details, that can easily be customized in the plugin.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl
Volatile Systems Volatility Framework 2.3_beta
Pid      Process          Address    Type                 Length   File                     Subject
-------- ---------------- ---------- -------------------- -------- ------------------------ -------
     624 winlogon.exe     0x010165d8 _X509_PUBLIC_CERT        1042 624-10165d8.crt          Microsoft Corporation
     668 services.exe     0x000b6b20 _X509_PUBLIC_CERT         576 668-b6b20.crt            VeriSign/VeriSign Commercial Software Publishers CA
     668 services.exe     0x000c8268 _X509_PUBLIC_CERT         665 668-c8268.crt            Fundacion FESTE
     668 services.exe     0x000decb0 _X509_PUBLIC_CERT         642 668-decb0.crt            Equifax Secure Inc.
     668 services.exe     0x000e3f90 _X509_PUBLIC_CERT         787 668-e3f90.crt            Thawte Consulting cc/Certification Services Division
     668 services.exe     0x000e49d8 _X509_PUBLIC_CERT         785 668-e49d8.crt            SecureNet CA Root
     668 services.exe     0x000e4cf8 _X509_PUBLIC_CERT         761 668-e4cf8.crt            FNMT/FNMT Clase 2 CA
     668 services.exe     0x000e5000 _X509_PUBLIC_CERT         780 668-e5000.crt            Unizeto Sp. z o.o.
     668 services.exe     0x000e77b8 _X509_PUBLIC_CERT         506 668-e77b8.crt            GTE Corporation

On the Stuxnet image, the plugin gathered a total of 11 private keys and 295 certificates out of memory. You can pipe the output to a file and analyze it later, or you can grep or filter stdout for potentially suspicious objects. In the case below, we're looking for any keys or certificates with the string "realtek" in the O or OU field. As you can see, we came up with three items - in the memory of services.exe, svchost.exe, and lsass.exe. If you read Stuxnet's Footprint in Memory with Volatility 2.0, you'll know Stuxnet performs code injection into all three of these processes, so it makes perfect sense.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl | grep -i realtek
Volatile Systems Volatility Framework 2.3_beta
     668 services.exe     0x015082e1 _X509_PUBLIC_CERT        1286 668-15082e1.crt          Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
     940 svchost.exe      0x00e182e1 _X509_PUBLIC_CERT        1286 940-e182e1.crt           Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
    1928 lsass.exe        0x009882e1 _X509_PUBLIC_CERT        1286 1928-9882e1.crt          Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN

Once again with openssl, you can get the full details of the suspect certificates. Below you can see the first one's serial number is 5e:6d:dc:87:37:50:82:84:58:14:f4:42:d1:d8:2a:25. You can verify the certificate with the openssl verify command or can query for the serial number in your threat intelligence feed, whatever that may be.

$ openssl x509 -inform der -in certs/668-15082e1.crt -text
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)04, CN=VeriSign Class 3 Code Signing 2004 CA
            Not Before: Mar 15 00:00:00 2007 GMT
            Not After : Jun 11 23:59:59 2010 GMT
        Subject: C=TW, ST=Taiwan, L=Hsinchu, O=Realtek Semiconductor Corp, OU=Digital ID Class 3 - Microsoft Software Validation v2, OU=RTCN, CN=Realtek Semiconductor Corp
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 CRL Distribution Points: 

            X509v3 Certificate Policies: 
                Policy: 2.16.840.1.113733.
                  CPS: https://www.verisign.com/rpa

            X509v3 Extended Key Usage: 
                Code Signing
            Authority Information Access: 
                OCSP - URI:http://ocsp.verisign.com
                CA Issuers - URI:http://CSC3-2004-aia.verisign.com/CSC3-2004-aia.cer

            X509v3 Authority Key Identifier: 

            Netscape Cert Type: 
                Object Signing
    Signature Algorithm: sha1WithRSAEncryption

The CCSS Forum has a searchable Digital Certificates Used by Malware portal, which you can use to get an initial perspective on whether your memory dumps are infected with certificate-stealing malware. The screen shot below shows the serial number of the certificate we extracted is registered in the portal as malicious.

The page also contains a link (if available) to the VirusTotal results for a particular sample. In this case, the certificate was associated with the MRXCLS.sys kernel driver - detected by 39 of 42 anti-virus engines (28 of them labeling it as "Stuxnet").

Now let's go back and use the -P/--physical switch which additionally scans deallocated/freed storage and see how the results differ. In this case, we found 4 certificates related to Realtek Semiconductor Corp, instead of the 3 we found when only scanning allocated and accessible process memory. This is quite useful because in the event that all 3 processes had terminated by the time our memory dump was acquired, there would still be one certificate still lingering around in RAM and available for recovery if you use the right scanning approach.

$ python vol.py -f stuxnet.vmem dumpcerts -D certs --ssl --physical | grep -i realtek
Volatile Systems Volatility Framework 2.3_beta
-        -                0x04efb2e1 _X509_PUBLIC_CERT        1286 phys.4efb2e1.crt         Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x0dd412e1 _X509_PUBLIC_CERT        1286 phys.dd412e1.crt         Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x161142e1 _X509_PUBLIC_CERT        1286 phys.161142e1.crt        Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN
-        -                0x1b4fbb2d _X509_PUBLIC_CERT        1286 phys.1b4fbb2d.crt        Realtek Semiconductor Corp/Digital ID Class 3 - Microsoft Software Validation v2/RTCN


There are a variety of reasons you may want scan for keys and certificates in memory. The dumpcerts plugin gives you the flexibility to perform simple extractions and/or filter results based on specific fields of the key or certificate. Perhaps most useful to investigators and analysts is you can also attribute the data to processes and carve them out of deallocated/freed space.

No comments:

Post a Comment