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


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


Friday 12 February 2021

Quickpost: oledump.py plugin_biff.py: Remove Sheet Protection From Spreadsheets

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

My new version of plugin_biff.py has a new option: –hexrecord.

Here I’ll show how I use this to remove the sheet protection from malicious spreadsheets.

If you want to open a malicious spreadsheet (for example with Excel 4 macros) in a sandbox, to inspect its content with Excel, chances are that it is protected.

I’m not talking about encryption (this is something that can be handled with my tool msoffcrypto-crack.py), but about sheet protection.

Enabling sheet protection can be done in Excel as follows:

Although you have to provide a password, that password is not used to derive an encryption key. An .xls file with sheet protection is not encrypted.

If you use my tool oledump.py together with plugin_biff.py, you can select all BIFF records that have the string “protect” in their name or description (-O protect). This will give you different records that govern sheet protection.

First, let’s take a look at an empty, unprotected (and unencrypted) .xls spreadsheet. With option -O protect I select the appropriate records, and with option -a I get an hex/ascii dump of the record data:

We can see that there are several records, and that their data is all NULL (0x00) bytes.

When we do the same for a spreadsheet with sheet protection, we get a different view:

First of all we have 4 extra records, and their data isn’t zero: the flags are set to 1 (01 00 little-endian) and the Protection Password data is AB94. That is the hash of the password (P@ssw0rd) we typed to create this sheet.

To remove this sheet protection, we just need to set all data to 0x00. This is something that can be done with an hex editor.

First use option -R instead of option -a:

This will give you the complete records (type, length and data) in hexadecimal. Next you can search for each record using this hexadecimal data with an hex editor and set the data bytes to 0x00.

Searching for the first record 120002000100:

Setting the data to 0x00: 0100 -> 0000

Do this for the 4 records, and then save the spreadsheet under a different name (keep the original intact).

Now you can open the spreadsheet, and the sheet protection is gone. You can now unhide hidden sheets for example.


Quickpost info


Monday 7 December 2020

Quickpost: finger.exe

Filed under: Hacking,Networking,Quickpost — Didier Stevens @ 0:00

Windows 10 comes with the finger command, an ancient computer network tool.

You can still use it to lookup weather information, for example 🙂

It establishes a TCP connection to the hostname/IP address after the @ character, using destination port 79. And then it sends the text before the @ characters in ASCII, terminated with carriage return & line feed.

After that, it reads the reply, displays it, and closes the TCP connection.

finger.exe is not proxy-aware.

Port 79 is not hardcoded as an integer in finger.exe: the port is identified by service name “finger” (UNICODE), which is defined in the services list (%SystemRoot%\system32\drivers\etc\services). GetAddrInfo uses this list.

If you replace “finger” with “http\x00\x00” (UNICODE) in finger.exe (via binary patching, a shim, …), the finger command will connect to port 80:

As noted by many, finger.exe can be (ab)used to exchange information and files. Here I had my own go at it with finger.exe & Excel:

 


Quickpost info


Monday 2 November 2020

Quickpost: Portable Power

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I did some tests to generate electricity (230V AC) with a portable 12V battery (well, it’s 10 Kg).

I have a 12V VRLA battery with a capacity of 35,000 mAh. That’s 12V times 35 Ah = 420 Wh. Or equivalent to a 116,667 mAh (420,000 mWh / 3.6 V) USB powerbank.

Charging this 12V battery with a 12V battery charger connected to a 230V power outlet takes almost 7 hours (6:57) and requires 0.49 kWh. That is measured with a plug-in electricity meter with a .00 kWh precision. And I’m working under the assumption that the power requirement of the electricity meter is so small that it can be neglected.

Then I use this fully charged battery to power a 230V 150W halogen lamp via a 12V DC to 230V AC power inverter (modified sine wave).

It runs for 2 hours (2 tests: 2:01 and 2:03) and consumes 0.30 kWh.

Of the 0.49 kWh energy I put into my system, I get 0.30 kWh out of the system. That’s 61%, or a bit better than half of the energy I put into the system.

The main phases where I expect the energy losses are occurring, is in 230V AC to 12V DC conversion and electrical to chemical energy conversion (charging); and chemical to electrical conversion and 12V DC to 230V AC conversion (discharging). I believe the highest energy loss to occur in the power inverter.

And with energy loss, I mean energy that is converted into forms that are not directly useful to me, like heat.

Remark that the halogen lamp test stopped after 2 hours, because the power inverter stopped converting. The battery voltage was 11.5 V then, and I could still draw 1 A at 11.5 V for an hour (I stopped that test after 1 hour).

Next I’m going to try out a 12V to 5V adapter and power some USB devices.

Saturday 31 October 2020

Quickpost: VMware OS Version Snapshots

Filed under: Quickpost — Didier Stevens @ 0:00

Whenever I upgrade the operating system of my virtual machines, I take a snaphot right after the upgrade.

This gives me a tree of different OS versions:

I give each snapshot a small descriptive name, that starts with the date of the snapshot (YYYYMMDD).

This allows me to revert to older versions to experiment with patched vulnerabilities, like this one.


Quickpost info


Saturday 10 October 2020

Quickpost: 4 Bytes To Crash Excel

Filed under: Hacking,Quickpost,Reverse Engineering — Didier Stevens @ 0:00

A couple of years ago, while experimenting with SYLK files, I created a .slk file that caused Excel to crash.

When you create a text file with content “ID;;”, save it with extension .slk, then open it with Excel, Excel will crash.

Microsoft Security Response Center looked at my DoS PoC last year: the issue will not be fixed. It is a “Safe Crash”, Excel detects the invalid input and calls MsoForceAppExitIf to terminate the Excel process.

If you have Excel crashing with .slk files, then look at the first line. If you see something like “ID;;…”, know that the absence of characters between the semi-colons causes the crash. Add a letter, or remove a semi-colon, and that should fix the issue.


Quickpost info


Monday 28 September 2020

Quickpost: USB Passive Load

Filed under: Hardware,Quickpost — Didier Stevens @ 0:00

I just received a USB passive load. It’s basically 2 resistors connected to the USB power wires in parallel, each with a switch in series:

It can draw approximately 1, 2 or 3 amps (depending on switch positions) from a 5 volt USB source.

The resistors can dissipate 10 Watts, and will become very hot.

The resistor for 1 amp (4,7 ohms, tolerance 5%) maxed-out my FLIR One thermal camera (> 150 °C), but I could measure around 220°C (that’s close to 451°F) with another thermal imaging camera.

The second resistor (2 amps: 2,2 ohms, tolerance 5%) maxed-out that other thermal camera too: this one got hotter than 280°C.

I’m referring to 451°F, because presumably, that’s the temperature to ignite paper. Something I’ll have to test out in safe conditions.

I also measured the resistors, and they are well within tolerance:

Here is a short thermal imaging video of the first resistor heating up:


Quickpost info


Sunday 27 September 2020

Quickpost: Ext2explore

Filed under: Quickpost — Didier Stevens @ 17:17

I was looking for a solution to read my Wifi Pineapple’s recon.db file from the SD card (ext2 formatted) on my Windows 10 machine.

The solution I went with is Ext2explore, a tool that can access ext2 volumes.

 

You have to run it as administrator, otherwise the tool will not be able to get raw access to the ext2 volume:

 

When you run the tool as administrator, you see your volumes. Mine is an SD card:

I can then explore the content and save file recon.db to a folder on my Windows 10 machine:


Quickpost info


Thursday 10 September 2020

Quickpost: dig On Windows

Filed under: Quickpost — Didier Stevens @ 12:40

I found out there’s a dig command for Windows.

I group small tools like this inside a bin folder. But dig relies on a set of DLLs, that should also be in the PATH, so I put them in the same bin folder.

These are the DLLs dig.exe needs:

  • libbind9.dll
  • libcrypto-1_1-x64.dll
  • libdns.dll
  • libirs.dll
  • libisc.dll
  • libisccfg.dll
  • libuv.dll
  • libxml2.dll

I used procmon on my Win10 machine to figure out which DLLs are needed, as you get no error message (there’s probably a registry setting for that).

I do have a Windows 7 VM, that I can also use to figure out which DLLs are missing because it displays an error message:

And you might also need to install the Visual C redistribuable that is included with the downloaded ZIP:

And now I can run dig from my bin folder:


Quickpost info


Next Page »

Blog at WordPress.com.