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.
[snip]
-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
storage)
---------------------------------
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.
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.
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.
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
[snip]
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/RTCNOnce 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
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5e:6d:dc:87:37:50:82:84:58:14:f4:42:d1:d8:2a:25
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
Validity
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):
00:b5:6c:5e:03:88:79:57:9a:4f:ce:02:30:b9:05:
1f:06:13:7a:57:17:4e:ee:59:d6:b0:20:d0:7c:e9:
17:32:bb:03:e8:13:45:1a:3e:22:57:4c:b4:bc:b3:
c5:3d:32:62:e8:a9:6c:f2:03:d1:72:ee:1e:f2:65:
ce:dd:df:0f:6e:77:08:a7:b2:13:92:db:30:f3:d8:
8e:b9:53:46:d5:08:16:4f:6d:92:a5:f2:74:5e:d9:
42:d2:89:50:92:53:0a:e6:ff:67:3f:14:59:fe:0d:
af:e0:97:8e:1f:f0:eb:6f:c6:e1:93:3e:5e:50:a6:
26:65:69:21:84:32:be:a3:27
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature
X509v3 CRL Distribution Points:
URI:http://CSC3-2004-crl.verisign.com/CSC3-2004.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.113733.1.7.23.3
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:
keyid:08:F5:51:E8:FB:FE:3D:3D:64:36:7C:68:CF:5B:78:A8:DF:B9:C5:37
Netscape Cert Type:
Object Signing
1.3.6.1.4.1.311.2.1.27:
0.......
Signature Algorithm: sha1WithRSAEncryption
bd:ba:23:02:36:e9:76:e9:cb:22:7a:ef:53:7b:3f:66:43:92:
01:43:e7:90:94:b4:52:d7:2c:89:82:24:39:fe:3f:7b:24:65:
d0:c2:72:56:18:a4:f6:0b:d3:9b:75:f1:63:62:89:5b:5d:2e:
9e:f8:1a:51:48:6b:b8:e6:cd:96:b7:f1:32:31:b2:a1:cd:e3:
bd:d9:04:7b:28:a9:5c:bf:be:3e:f3:e6:03:52:2c:75:88:5a:
1a:ca:99:de:b9:3f:99:77:10:db:63:ed:68:b4:09:fb:ee:8d:
c3:6a:c3:82:ec:12:e8:1a:22:61:28:8a:f6:4e:5d:1a:c3:50:
97:3b:22:da:99:ab:3f:38:9b:4d:d1:da:01:e3:40:14:aa:a5:
9d:13:1c:71:ea:cb:99:99:52:65:f5:94:af:d7:d0:ca:c7:04:
20:eb:b7:41:4b:82:cc:07:84:de:6f:2a:51:8f:7b:0a:25:db:
f0:1d:09:56:cc:30:5b:a2:55:5b:6d:da:8e:d6:a7:dd:1d:c6:
ff:3d:74:f8:ff:e2:60:35:66:1f:a8:66:72:c1:fb:76:46:ca:
df:24:ac:1a:66:fa:11:41:b7:f4:51:89:dc:da:49:99:3c:3d:
d5:77:2d:b3:d3:d3:64:50:18:f4:95:f4:dd:9f:8d:76:41:60:
25:b4:70:8b
-----BEGIN CERTIFICATE-----
MIIFBjCCA+6gAwIBAgIQXm3chzdQgoRYFPRC0dgqJTANBgkqhkiG9w0BAQUFADCB
tDELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNDEuMCwGA1UEAxMl
VmVyaVNpZ24gQ2xhc3MgMyBDb2RlIFNpZ25pbmcgMjAwNCBDQTAeFw0wNzAzMTUw
MDAwMDBaFw0xMDA2MTEyMzU5NTlaMIHJMQswCQYDVQQGEwJUVzEPMA0GA1UECBMG
VGFpd2FuMRAwDgYDVQQHEwdIc2luY2h1MSMwIQYDVQQKFBpSZWFsdGVrIFNlbWlj
b25kdWN0b3IgQ29ycDE+MDwGA1UECxM1RGlnaXRhbCBJRCBDbGFzcyAzIC0gTWlj
cm9zb2Z0IFNvZnR3YXJlIFZhbGlkYXRpb24gdjIxDTALBgNVBAsUBFJUQ04xIzAh
BgNVBAMUGlJlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDb3JwMIGfMA0GCSqGSIb3DQEB
AQUAA4GNADCBiQKBgQC1bF4DiHlXmk/OAjC5BR8GE3pXF07uWdawINB86RcyuwPo
E0UaPiJXTLS8s8U9MmLoqWzyA9Fy7h7yZc7d3w9udwinshOS2zDz2I65U0bVCBZP
bZKl8nRe2ULSiVCSUwrm/2c/FFn+Da/gl44f8OtvxuGTPl5QpiZlaSGEMr6jJwID
AQABo4IBfzCCAXswCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCB4AwQAYDVR0fBDkw
NzA1oDOgMYYvaHR0cDovL0NTQzMtMjAwNC1jcmwudmVyaXNpZ24uY29tL0NTQzMt
MjAwNC5jcmwwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIB
FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMBMGA1UdJQQMMAoGCCsGAQUF
BwMDMHUGCCsGAQUFBwEBBGkwZzAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy
aXNpZ24uY29tMD8GCCsGAQUFBzAChjNodHRwOi8vQ1NDMy0yMDA0LWFpYS52ZXJp
c2lnbi5jb20vQ1NDMy0yMDA0LWFpYS5jZXIwHwYDVR0jBBgwFoAUCPVR6Pv+PT1k
Nnxoz1t4qN+5xTcwEQYJYIZIAYb4QgEBBAQDAgQQMBYGCisGAQQBgjcCARsECDAG
AQEAAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQC9uiMCNul26csieu9Tez9mQ5IBQ+eQ
lLRS1yyJgiQ5/j97JGXQwnJWGKT2C9ObdfFjYolbXS6e+BpRSGu45s2Wt/EyMbKh
zeO92QR7KKlcv74+8+YDUix1iFoaypneuT+ZdxDbY+1otAn77o3DasOC7BLoGiJh
KIr2Tl0aw1CXOyLamas/OJtN0doB40AUqqWdExxx6suZmVJl9ZSv19DKxwQg67dB
S4LMB4TebypRj3sKJdvwHQlWzDBbolVbbdqO1qfdHcb/PXT4/+JgNWYfqGZywft2
RsrfJKwaZvoRQbf0UYnc2kmZPD3Vdy2z09NkUBj0lfTdn412QWAltHCL
-----END CERTIFICATE-----
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.
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/RTCNConclusion
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