So this is a quick post with hopefully the goal of saving somebody else some time. Just for the record, I could have missed something totally trivial and I will hopefully get corrected :)

When working with the registry_persistence module, it turns out that one of the registry entries turns into garbage. At first I blamed myself of course, but it turned out that this could probably be a bug in the meterpreter code of which I’m not sure if it really is a bug or if there is a new API call which I haven’t found yet. So when executing the module the registry looks like this:

registry_garbled

Like you can see that’s not exactly how it really should look like, since what we are expecting is something more human readable and an actual powershell command.

The quick work around is to generate the correct string with the correct encoding and for me it was easier to do this with python:

a = "%COMSPEC% /b /c start /b /min powershell -nop -w hidden -c \"sleep 1; iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((Get-Item 'HKCU:myregkey_name').GetValue('myregkey_value'))))\""
b = '\\x'.join("{:02x}".format(ord(c)) for c in a.encode('UTF-16LE'))
print '\\x' + b

You can then just hard code the output string into the module (replace the original ‘cmd=’ string with your hex encoded one like cmd=”\x25\x00″ etc) and it should appear correctly in your registry. Following screenshot shows before and after:

registry_fixed

If you are curious how you could debug similar bugs yourself, keep on reading for a short tour of the problem solving part. If you are wondering why I don’t submit a PR to metasploit, that’s cause unicode scares the **** out of me. My usual experience is I generate more problems when dealing with unicode than I intended to fix.

Read the rest of this entry »

So after a period of ‘lesser technical times’ I finally  got a chance to play around with bits, bytes and other subjects of the information security world.  A while back I got involved in a forensic investigation and participated with the team to answer the investigative questions.  This was an interesting journey since a lot of things peeked my interest or ended up on one of my todo lists.

One of the reasons that my interest was peeked is that yes, you can use a lot of pre-made tools to process the disk images and after that processing is done you can start your investigation. However, there are still a lot of questions you could answer much quicker if you had a subset of that data available ‘instantly’. The other reason is that not all the tools understand all the filesystems out there, which means that if you encounter an exotic file system your options are heavily reduced. One of the tools I like and which inspired me for these quick & dirty scripts is ‘mac-robber‘ (be aware that it changes file times if the destination is not mounted read-only) since it’s able to process any file system as long as it’s mounted on an operating system on which mac-robber is able to run. An example of running mac-robber:

sudo mac-robber mnt/ | head
class|host|start_time
body|devm|1471229762
MD5|name|inode|mode_as_string|UID|GID|size|atime|mtime|ctime|crtime
0|mnt/.disk|0|dr-xr-xr-x|0|0|2048|1461191363|1461191353|1461191353|0
0|mnt/.disk/base_installable|0|-r–r–r–|0|0|0|1461191363|1461191316|1461191316|0
0|mnt/.disk/casper-uuid-generic|0|-r–r–r–|0|0|37|1461191363|1461191353|1461191353|0

You can even timeline the output if you want with mactime:

sudo mac-robber mnt/ | mactime -d | head
Date,Size,Type,Mode,UID,GID,Meta,File Name
Thu Jan 01 1970 01:00:00,2048,…b,dr-xr-xr-x,0,0,0,”mnt/.disk”
Thu Jan 01 1970 01:00:00,0,…b,-r–r–r–,0,0,0,”mnt/.disk/base_installable”
Thu Jan 01 1970 01:00:00,37,…b,-r–r–r–,0,0,0,”mnt/.disk/casper-uuid-generic”
Thu Jan 01 1970 01:00:00,15,…b,-r–r–r–,0,0,0,”mnt/.disk/cd_type”
Thu Jan 01 1970 01:00:00,60,…b,-r–r–r–,0,0,0,”mnt/.disk/info”

Now that’s pretty useful and quick! One of the things I missed however was the ability to quickly extend the tools as well as focus on just files. From a penetration testing perspective I find files much more interesting in an forensic investigation than directories and their meta-data. This is of course tied to the type of investigation you are doing, the goal of the investigation and the questions you need answered.

I decided to write a mac-robber(ish) python version to aid me in future investigations as well as learning a thing or two along the way. Before you continue reading please be aware that:

  1. The scripts have not gone through extensive testing
  2. Thus should not be blindly trusted to produce forensically sound output
  3. The regular ‘professional’ tools are not perfect either and still contain bugs ;)

That being said, let’s have a look at the type of questions you can answer with a limited set of data and how that could be done with custom written tools. If you don’t care about my ramblings, just access the Github repo here. It has become a bit of a long article, so here are the ‘chapters’ that you will encounter:

  1. What data do we want?
  2. How do we get the data?
  3. Working with the data, answering questions
    1. Converting to body file format
    2. Finding duplicate hashes
    3. Permission issues
    4. Entropy / file type issues
  4. Final thoughts

Read the rest of this entry »

Errr ok, so the “NSA-style content searching” might be a bit overrated then again it’s usually only the intelligence agencies which perform this type of bulk searches as far as I know. Anyhow, here is an idea on how to abuse Google DLP (available in google apps for work) to perform exactly the same, since it recently incorporated support to also perform OCR on the emails / attachments:

According to this screenshot it seems that you can also perform DLP actions on incoming items:

google-dlp

Which is what enables us to perform specific content searches on all incoming email messages and prepend  certain keywords to the subject. Now imagine you just hacked an organisation and added a rule to the exchange server or individual outlook instances to forward all email to an email your control and has DLP enabled with all the keywords, hashes or rules you need to only get the juicy contents out? Don’t forget to delete the forwarded message with a rule ;) The types of content matching that you can perform is also pretty flexible:

  • Pattern match—A specific alphanumeric pattern (not just string length), including delimiters, valid position, and valid range checks
  • Context—Presence of relevant strings in proximity to pattern and/or checksum matching string
  • Checksum—Checksum computation and verification with check digit
  • Word/phrase list—Full or partial match to an entry found in a dictionary of words and phrases

Based on the DLP trigger you can then just rename the subject and use google rules to forward the message to another inbox or leave it there and just organise it into folders. Kinda saves you as an attacker a lot of time, since normally you’d have to perform or implement OCR / content matching yourself. Added bonus is that since it’s already been stolen from the victim company it doesn’t really matter what you do with it as long as the original sender doesn’t receive some weird Google notification.

You might be thinking “my client will never allow this”, but what if your client is already connected to google apps for work?

As a final thought you could also use this for defence purposes if you are already working with Google apps for work as an organisation. You could use the Google DLP feature to feed it the currently hyped ‘threat intelligence’ file hash information and block different known threat actors if their tools & techniques remain the same for a period of time.

PowerShell overview and introduction

Posted: February 6, 2016 in general
Tags:

This is a long overdue post I was planning on writing as a reference for myself, since I don’t write that much PowerShell. Depending on your own knowledge about powershell you can just skip to whatever sections seems useful to you. Also feel free to correct any mistakes in this article since I intent it mostly as a basic reference :) The resource section contains a nice collection of links to other PowerShell articles & tools, which means you can consider this article a small recap of all the resources linked.

TL;DR The resource section contains useful URLs to learn Power Shell, the blog post itself is just a micro-recap of those resources.

  • What is PowerShell and why would you use it?
  • Basic PowerShell environment
  • How do you run PowerShell?
  • What is the PowerShell syntax?
  • Our first script
  • Calling Windows functions
  • Resources

basic-powershell-commands-intro-840x420

Read the rest of this entry »

Well this will be a rather short post since it’s about the automation of my previous blog post in which we analysed the memory dump of the pageant process and manually extracted unencrypted keys. You can find the tool which automates this process in pageant_xkeys git repository. Since I’m a firm believer that you learn best from mistakes and old code, the repository also includes some of the other code I was playing around with.

 

A Red Team exercise is lotsa fun not only because you have a more realistic engagement due to the broader scope, but also because you can encounter situations which you normally wouldn’t on a regular narrow scoped penetration test. I’m going to focus on pageant which Slurpgeit recently encountered during one of these red team exercises which peeked my interest.

Apparantly he got access to a machine on which the user used pageant to manage ssh keys and authenticate to servers without having to type his key password every single time he connects. This of course raises the following interesting (or silly) question:

Why does the user only have to type his ssh key in once?

Which has a rather logical (or doh) answer as well:

The pageant process keeps the decrypted key in memory so that you can use them without having to type the decryption password every time you want to use the key.

From an attackers perspective it of course begs the question if you can steal these unencrypted keys? Assuming you are able to make a memory dump of the running process you should be able to get these decrypted ssh keys. During this blog post I’ll be focusing on how you could achieve this and the pitfalls I encountered when approaching this.

Read the rest of this entry »

One of the things that has always fascinated me is when you are watching some Hollywood movie and they talk about stuff like “rotating string cipher encryption with a strength of 228 bits”. Now this has always sounded both funny and interesting to me. Like what if you could convert data that is normally static into actual continuous rotating data? This morning it hit me, this is something we can actually accomplish with password hashes. We can rotate them continuously, without the user even noticing and hopefully make it harder for attackers to crack the hash. Which is the main goal of this “idea/solution” making it harder or hopefully impossible for attacker to crack the hash when they obtain it. Here is a PoC preview output, screenshot OTP and usage OTP don’t match because they were obtained at different times:

otp

./hashrotate_poc.py S3cretP4ssword 545130
 Current password hash:
 224bbe14e25287f781eb94d57a49eb8e064f3857e2b369ea8f413ed22e6190e568e2107aaaa8ef60aa7db9413f930a7d6e715c83bd06243dd2f26cf86a9828b9
 Login OK
./hashrotate_poc.py S3cretP4ssword 545130
 Current password hash:
 12abaded0aebd3269229ea53c85be4fe78d5dd876b4feac6b21bd87c4f0235fee01990e600f5664085e9139f108903446376a2f6fab1770c9add86ad4168fbea
 Login Failed

Like you can see we attempt to login with the same credentials both times and yet the second time this fails. If you are impatient then you’ve probably guessed that this is due to the added 2FA data in the login credentials and as usual you can jump straight to the code on my github. Now if you are curious how this works and how you could set this up in a real life setup keep on reading, do note that I haven’t tested this yet on a real life environment however. The setup is actually one of the important parts for this to work and actually slow down or hopefully prevent an attacker from successfully cracking the obtained hashes.

Now after you’ve read that you are probably thinking “shut up already with those ‘uncrackable’ claims” and yeah you are correct. It can probably be cracked, but hopefully we can settle for the second best which is (tremendously) slowing down the attacker.

For the remainder of this entry we will be focusing on further protecting the stored hashes and not on how to protect the in transit plain text password. This since obviously if you have full control of a server where the SSL is terminated you could just intercept all passwords in plain text. This can be solved with fancy challenge-response protocols or maybe (in browser) public-key cryptography. For now, let’s dig further into this ‘continuous changing hashes’ concept.

Read the rest of this entry »