Didier Stevens

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

Monday 1 March 2021

Overview of Content Published in February

Filed under: Announcement — Didier Stevens @ 0:00

Here is an overview of content I published in February:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

Sunday 28 February 2021

Update: oledump.py Version 0.0.60

Filed under: My Software,Update — Didier Stevens @ 23:08

This new version of oledump.py brings an update to plugin plugin_biff to help with the recovery of protection passwords.

oledump_V0_0_60.zip (https)
MD5: BC7631059077294223BB225D16FB7186
SHA256: D847E499CB84B034E08BCDDC61ADDADA39B90A5FA2E1ABA0756A05039C0D8BA2

Monday 22 February 2021

re-search.py And Custom Validations

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

My tool re-search.py is a tool that uses regular expressions to search through files. You can use regular expressions from a small builtin library, or provide your own regular expressions.

And these regular expressions can be augmented with extra conditions, like validation with a custom Python function.

I’m going to illustrate this here with a regular expression to match credit card numbers. Credit card numbers have a check digit (calculated with the Luhn algorithm) and I’m going to augment the regular expression to validate the check digit.

I’m using the following regular expression to match credit card numbers (I’m limiting myself to credit card numbers of 16 digits): \b(\d{4}( ?)\d{4}\2\d{4}\2\d{4})\b

This regular expression consist of 4 expressions to match 4 digits “\d{4}”. Each block of 4 digits could be separated with a space character ” ?”.

I’m putting this in a capture group “( ?)” so that I can refer back to this matched group with backreference \2 (it’s the second capture group, because the complete credit card number is also put in a capture group, e.g. the first capture group).

The reason I’m using a backreference to match the first optional space character, is because I want to match the next 2 separating space characters if and only if a first space character was matched. So I want to match (1111222233334444 and 1111 2222 3333 4444, but not 11112222 3333 4444 for example). Either all 4 groups are separated, or none are separated.

Finally, I put this expression in a capture group, and enclose it with a boundary check “\b”. This is to avoid matching credit card numbers that are immediately preceded or followed by letters or digits.

So I can use this regular expression with re-search.py on a test file:

You can see that the first 2 test credit card numbers are identical, except for the last digit: the check digit. So at most one of these 2 can be a valid credit card number.

This can be checked with the Luhn algorithm.

Here is a small Python script to calculate this Luhn check digit:


# 2020/02/06
# https://stackoverflow.com/questions/21079439/implementation-of-luhn-formula

import string

def luhn_checksum(card_number):
    def digits_of(n):
        return [int(d) for d in str(n)]
    digits = digits_of(card_number)
    odd_digits = digits[-1::-2]
    even_digits = digits[-2::-2]
    checksum = 0
    checksum += sum(odd_digits)
    for d in even_digits:
        checksum += sum(digits_of(d*2))
    return checksum % 10

def is_luhn_valid(card_number):
    return luhn_checksum(card_number) == 0

def CCNValidate(ccn):
    return is_luhn_valid(''.join(digit for digit in ccn if digit in string.digits))

Python function luhn_checksum calculates the check digit for an input of digits, and Python function is_luhn_valid return True when the calculate Luhn number matches the check digit.

To use this last function with the regular expression I created, I need another Python function: CCNValidate. This function receives the string matched by the regulator expression, extracts the digits and checks the Luhn check digit.

To let my tool re-search.py call this function CCNValidate when a credit card number is matched by the regular expression, I precede the regular expression with a comment, like this:

(?#extra=P:CCNValidate)\b(\d{4}( ?)\d{4}\2\d{4}\2\d{4})\b

(?#…) is a comment in the regular expression syntax. It is ignored by the parser (i.e. not used for matching). … is the comment itself, which can be anything.

re-search.py interprets this comment: when the comment starts with “extra=”, re-search is dealing with an augmented regular expression. P indicates that a Python function has to be called when the regular expression matches, and CCNValidate is the name of the Python functon to call when the regular expression matches.

All this combined gives me the following command:

You can see that the first credit card number that was matched in the first example, no longer matches: that’s because 6 is not the correct Luhn number for this credit card number.

Besides providing re-search.py with this augmented regular expression, I also need to provide the Python script containing the validation functions: I do this with option –script CCNValidate.py

 


	

Sunday 21 February 2021

Update: re-search.py Version 0.0.16

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

This new version of re-search.py, my tool to search files with a builtin library of regular expressions, brings an update to the url and url-domain regexes to match hostnames with underscores (_) and a Python 3 fix.

re-search_V0_0_16.zip (https)
MD5: 21A7096116F50CCA051A152066B2DB50
SHA256: 4A3AC1B1BED68660316011F14EFC84B344BE3FF7E335CDFA8F1AAA2C0D2D06B0

Next Page »

Blog at WordPress.com.