Didier Stevens

Monday 26 April 2021

Quickpost: Decrypting Cobalt Strike Traffic

Filed under: Encryption,Malware,My Software,Quickpost — Didier Stevens @ 0:00

I have been looking at several samples of Cobalt Strike beacons used in malware attacks. Although work is still ongoing, I already want to share my findings.

Cobalt Strike beacons communicating over HTTP encrypt their data with AES (unless a trial version is used). I found code to decrypt/encrypt such data in the PyBeacon and Geacon Github repositories.

This code works if you know the AES key: which is not a problem in the use cases of the code above, as it is developed to simulate a beacon. Beacons generate their own AES key, and thus these beacon simulations also generate their own AES key.

But what if you’re analyzing real beacons used in malware attacks? How do you obtain the AES key?

I found a way to extract the keys (AES and HMAC) from process memory of a running beacon.

I use the following procdump command to prepare process memory dumps:

procdump -mp -w -s 1 -n 5 malware.exe

Then I start the beacon malware.exe in a malware analysis virtual machine while capturing traffic with Wireshark.

My new tool cs-extract-key.py looks in the dumped process memory for the unencrypted (RSA encryption) metadata that a beacon sends to the C2. This metadata contains the AES en HMAC keys.

Example:

This method does not always work: the metadata is overwritten after some time, so the process dump needs to be taken quickly after the beacon is started. And there are also cases were this metadata can not be found (I suspect this is version bound).

For those cases, my tool has another way of obtaining the keys. I extract the encrypted data of the first post of the beacon to the C2 (this is called a callback in the PyBeacon code):

And then I provide this to my tool, together with the process dump. My tool will then proceed with a dictionary attack: extract all possible AES and HMAC keys from the process dump, and try do authenticate and decrypt the callback. If this works, the keys have been found:

And once I have obtained the keys, I can pass them to my traffic decoding program that I have updated to include decryption (and that I have renamed to cs-parse-http-traffic.py):


Quickpost info


Sunday 25 April 2021

isodump.py

Filed under: My Software,video — Didier Stevens @ 10:13

This is a new tool (beta) to analyze ISO files. I made this for a webinar I presented: a demo on how to use my templates to create your own tools.

isodump.py is in my Github beta repository.

The complete webinar is here, if you want to jump directly to the demo where I explain how to make a tool like isodump.py, go here.

Monday 19 April 2021

Lua CSV Wireshark Dissector

Filed under: My Software,Networking,Wireshark — Didier Stevens @ 0:00

In December 2020 I provided online Wireshark training to one of our NVISO clients. During the second day, when we cover the development of custom dissectors written in Lua, a question about CSV data came up. When the data exchanged over TCP, for example, has the CSV format (fields separated by a separator), how can I write a dissector for that?

While answering the question, I realized that this is a case that could be solved with a generic dissector. And the same night, I developed the first version.

Say you have a packet capture with a TCP connection. And the data exchanged over TCP consists of different fields, separated by a separator character.

Like this example:

Because Wireshark does not recognize the protocol used in this TCP connection, the content is just displayed as data.

With Lua dissector csv-dissector.lua, the data is dissected into different fields:

The separator character (pipe character | in this example) is something that can be configured:

Other changes can be made, but these have to be made in the code of the dissector itself:

  • Changing the port
  • Changing the number of fields
  • Change the name of the fields

 

Download:

csv_dissector_V0_0_2.zip (https)

MD5: E8CCE089FB0574775AB39DADED3B7AA2

SHA256: 5C8DC0F2BB97AA660E2576B23379B6F12FB88126F0EFC7A2F69E76EBA8E782BD

Sunday 18 April 2021

metatool.py

Filed under: Announcement,My Software — Didier Stevens @ 17:56

metatool.py is a tool to help with the analysis of Metasploit or Cobalt Strike URLs.

More info can be found in my SANS Internet Storm Center diary entry “Finding Metasploit & Cobalt Strike URLs“.

It is still in my Github beta repository here.

Thursday 1 April 2021

Overview of Content Published in March

Filed under: Announcement — Didier Stevens @ 0:00

Here is an overview of content I published in March:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

Saturday 27 March 2021

FileZilla Uses PuTTY’s Registry Fingerprint Cache

Filed under: Encryption,Forensics,Networking — Didier Stevens @ 10:01

Today I figured out that FileZilla uses PuTTY‘s registry key (HKCU\SOFTWARE\SimonTatham\PuTTY\SshHostKeys) to cache SSH fingerprints.

This morning, I connected to my server over SFTP with FileZilla, and got this prompt:

That’s unusual. I logged in over SSH, and my SSH client did not show a warning. I checked the fingerprint on my server, and it matched the one presented by FileZilla.

What’s going on here? I started to search through FileZilla configuration files (XML files) looking for the cached fingerprints, and found nothing. Then I went to the registry, but there’s no FileZilla entry under my HKCU Software key.

Then I’m taking a look with ProcMon to figure out where FileZilla caches its fingerprints. After some searching, I found the answer:

FileZilla uses PuTTY’s registry keys!

And indeed, when I start FileZilla again and allow it to cache the key, it appears in PuTTY’s registry keys.

One last check: I modified the registry entry and started FileZilla again:

And now FileZilla warns me that the key is different. That confirms that FileZilla reads and writes PuTTY’s registry fingerprint cache.

So that answered my question: “Why did FileZilla warn me this morning?” “Because the key was not cached”.

But then I was left with another question: “Why is the key no longer cached, because it was cached?”

Well, I started to remember that some days ago today, I had been experimenting with PuTTY’s registry keys. I most likely deleted that key (PuTTY is not my default SSH client). I verified the last-write timestamp for PuTTY’s registry key, and indeed, 4 days ago it was last written to.

Update:

Thanks to Nicolas for pointing out that fzsftp is based on PuTTY:

Friday 12 March 2021

Quickpost: “ProxyLogon PoC” Capture File

Filed under: Forensics,Networking,Quickpost,Vulnerabilities — Didier Stevens @ 18:43

I was able to get the “ProxyLogon PoC” Python script running against a vulnerable Exchange server in a VM. It required some tweaks to the code, and also a change in Exchange permissions, as explained in this tweet by @irsdl.

I created a capture file:

More details will follow.

Update: I added a second capture file (proxylogon-poc-capture-with-keys-and-webshell.pcapng), this one includes a request to the webshell that was installed.

proxylogon-poc-capture-with-keys_V2.zip (https)
MD5: A005AC9CCE0F833C99B5113E79005C7D
SHA256: AA092E099141F8A09F62C3529D8B27624CD11FF348738F78CA9A1E657F999755


Quickpost info


Monday 8 March 2021

Update: 1768.py Version 0.0.5

Filed under: My Software,Update — Didier Stevens @ 0:00

I updated the analysis logic in this new version of my tool 1768.py to analyze Cobalt Strike beacons.

There’s a new option -c (–csv) to output the config values in CSV format.

And now with option -r (–raw), identical configs are de-duplicated.

1768_v0_0_5.zip (https)
MD5: 83D7A867B93FAC13BA24F17DDA994A9A
SHA256: CBCB84B9C4D8C1ED05983C2A211E3EA6029E69782FDDD6E15181EE4F47383EB5

Sunday 7 March 2021

Update pecheck.py Version 0.7.13

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version of pecheck.py, my tool to analyze PE files, outputs the hash of the embedded Authenticode signature.

pecheck-v0_7_13.zip (https)
MD5: 5B5179FFBE7530AA60C7182B830B54AB
SHA256: 4CFAF98CC8F3B06E3BBD7D6F37040B47641C38E49BD2975165FB328D50D3F08C

Saturday 6 March 2021

Update: nsrl.py Version 0.0.3

Filed under: My Software,Update — Didier Stevens @ 13:28

I use my tool nsrl.py to match a list of hashes with the Reference Data Set of the National Software Reference Library.

This is a Python 3 update and small change to support a change in RDS ZIP file structure.

nsrl_V0_0_3.zip (https)
MD5: A86E3EB076B467C64A520256556EDADA
SHA256: 8760B20A918CD135B7D79F7567C240AEF4840325BE9656D684BFD119A017E86F

« Previous PageNext Page »

Blog at WordPress.com.