Today I stumbled upon the tweet from Dominic Chell which was about this article that he wrote. This triggered a feeling of nostalgia of the era during which red team was still not a very familiar term with most of the clients. This triggered me to write up the story of a red team that I participated in around ~2010. To ensure that some details remain hidden, I’ve mixed in a couple of techniques from other red teams that I participated in around the same period. Although I’d almost bet that the gaps in my memory are enough to obfuscate the most important details :P
You might be wondering, why write up something old and probably with zero relevance to the actual state of defense today? The reason is exactly that, to hopefully provide insight in how clients and technology have evolved to make it more difficult for adversaries not only to get in, but to remain undetected. In addition I hope that the mistakes that we made back then enable other people to learn from.
If you feel that you are suddenly hoping that you would have done red teams back then, don’t feel sad. There is a big probability that in another ~10 years you will look back and think: Whoa, red teaming was pretty easy around ~2019.
If you enjoy stories from the past, keep on reading.
secure, that’s one of those words that is capable of triggering a (usually negative) physical reaction with most people working in the security industry. Thing is, whenever someone claims secure, they usually forget to mention against what kind of threat(s) it is secure. So every once in a while I like to attempt to build something that is secure against a chosen threat model, just for the fun of the mental workout.
This blog will be about the exercise of performing a threat model of a slack bot I might build. It will not contain instructions on how to implement it, it will just be my train of thought while doing a threat model for the solution I want to build.
Most of the times it ends in the project not being finished or if I finish it people point out all kind of security issues in the solution. The latter being the main reason that I like doing these type of projects, since I’ve come to realize that somehow when you are designing a secure solution on your own, you will always end up with blind spots. While if you where to look at the same solution without building it you’d be spotting those exact same security issues. Thus you learn a lot from attempting to build a secure solution and have some else shoot some nice holes in it.
This time I decided to build a simple slack bot that would be capable of receiving a URL to an online Youtube video and download it for offline consumption. After some thinking I came to the following definition of the slack bot being secure:
Hard target to casual and opportunistic attackers
Hard target for memory corruption vulnerabilities
When breached, constraint the attacker to pre-defined resources
So basically I want the solution to be secure against a curious user that uses the bot and decides he wants to hack it for the lulz. In addition when the attacker succeeds, I want that the attacker is only able to view / modify the information that I consider expendable. You’ll notice that I’m saying ‘when the attacker succeeds’ and not ‘if the attacker succeeds’. This is due to the fact that I always assume it will be breached, thus forcing myself to answer the question(s): “what’s the impact? can I accept it? if not, what should I mitigate?”. The other reason is of course that I’m a terrible sysadmin, and I expect myself to forget to patch stuff :( Besides the security requirements I also wanted to learn something new, so I decided I wanted to develop the bot using go.
So how do you proceed to design something with the above requirements? Normally I just perform a threat model-ish approach whereby I mentally think of the assets, attacks and the corresponding security controls to mitigate those attacks, sometimes with the aid of a whiteboard. This time however I decided to give the more formal drawing of a threat model a go. So i searched around, found this awesome blog and after a short while of (ab)using draw.io I ended up with the following result:
Let’s dive into this diagram and see how to further improve the security controls or security boundaries.
TL;DR Threat modeling is a fun and useful mental exercise and aids in spotting potential attacks you might forget to secure against. Also it is 2019, we should be using seccomp and apparmor or similar technologies much more frequent.
A while ago I wrote a script to perform what I called poor man’s forensics. The script was meant as a way to utilize the native operating system to extract some minimal data from exotic filesystems to be able to create a timeline and identify possible abnormalities. As a reminder to myself here are some additional raw notes, commands and resources on performing (forensic || incident response || compromise assessments) investigations on ZFS / Solaris environments. I encountered ZFS / Solaris during some of the FoxCert investigations I participated in.
These raw notes are by no means complete and you must definitely not follow these blindly and always ensure you are working on a copy of a copy of a copy of the real evidence.
Depending on your personality the concept of being legally allowed to break into places has a kind of mythical ring to it. You’ve seen it happen in movies and series like James Bond, Mission Impossible, Leverage and a dozen others and you might have wondered is that how it really happens in real life? On some level you already know that the movie depictions are not that close to reality. Why? Mostly due to all those other stories of regular burglary where the break-in is much less sophisticated, yet very effective.
In this blog post I’m going to try and give an overview of physical penetration tests and how to start doing them from my own perspective (European context, we have to worry less about guns). In addition I will focus on the type of tests where a target asks you to ‘casually’ break in and gain access to a room, plant a device or steal some specific information. ‘Casually’, what does that even mean? In my experience it means that you get one or two days for your preparations and one day to execute the attack. Doesn’t seem like a lot, but you’d be surprised how many targets can be breached with minimal preparations, some courage and the fact that you aren’t really going to jail when caught ;)
I’m also no expert on this subject, so feel free to leave corrections as well as additional tips, tricks and personal experiences in the comments. Lastly, not all physical penetration tests will be the ideal take 4 weeks to do your thing type of job. So I consider it good practice to also be able to perform these type of smaller jobs where thinking on your feet is almost mandatory, not to mention fun if you like to practice your improvisation skills.
Before I forget, this information is mostly for your general running off the mill big corporation with standard security and where the target is just interested in an attacker that doesn’t invest a lot of time in the attack. Don’t attempt to access high security facilities with minimal preparation. Even though it might succeed, you will most likely strand at the first door or person that you attempt to bypass.
I’ve written a couple of times on the subject of boot loaders and full disk encryption, but I haven’t really explored it in more detail. With this blog post I hope to dive a bit deeper into how to actually start performing these type of analysis and why they are useful to perform. I’ll start with the usefulness first and then go into the part on how to do it, but will not be fully reversing a disk encryption boot loader. I won’t be doing a lot of hard-core reversing like finding vulnerabilities within the cryptographic operations or reversing custom filesystem implementations, but hopefully provide enough information to get started in the area of reversing unknown boot loaders.
The type of products with which you can use the approaches and techniques described in this blog post are the most useful when applied to full disk encryption (FDE) solutions that are configured to not require pre-boot authentication. The reason being, that you then could potentially obtain the disk decryption key. If the solution requires pre-boot authentication, the information that you can obtain, might be reduced to meta-data or ‘deleted’ files. Which brings us to the whole, why are these type of analysis useful?
The reason of why this is useful, I didn’t fully realise until a couple of years ago when a colleague introduced me to the wonders of all the (hidden) information that FDE solutions may contain. Let’s look at the type of information that you may encounter while investigating these solutions:
(encrypted) Hidden file systems
(obfuscated) Encryption keys
Windows domain credentials
Configuration information of the FDE solution
Files marked for deletion
Finding 0days and bypassing encryption
Based on the above list of items we can pretty much conclude that analysing FDE solutions is useful from an offensive as well as from a defensive point of view. It can either help us to breach a target network or obtain sensitive information as well as collect forensic evidence or aid us into understanding the specific cryptographic implementation to enable us to decrypt the disk and analyse it. The helper tools I’ve used in this blog post can be found here. Keep on reading if you want to know the rest of all the details and the process I usually follow. I’ll try to describe the following steps:
Creating a (partial) copy of the disk
Analysing the disk
Static & dynamic boot analysis
Since I don’t have easy access to disk encryption software with the exact features I’d like to analyse I’ll be using DiskCryptor as an example product.
For some reason it seems that the products with the most interesting features to reverse engineer have a horrendous ‘request trial’ process as well as not providing trials to a random researcher on the internet :( sad panda :(
The other reason to use DiskCryptor is the fact that it is open source, thus enabling people that want to get started with type of stuff to more easily understand difficult snippets of assembly. My personal approach to a lot of reversing challenges usually revolves around finding a similar open source variant first or finding the open source components used in the proprietary solution if applicable. Reason being that it makes your life a lot easier to understand not only general concepts, but also specific code quirks. A very nice explanation on finding as much information as possible before your start reversing is given by Alex Ionescu in his offensive con keynote ‘Reversing without reversing’.
Oh and there is no specific goal, besides just explaining my general thought process. As a side note I am no reverse engineering expert, so feel free to correct me :-)
The hijacking of port 445 to perform relay attacks or hash capturing attacks has been a recurring topic for a while now. When you infect a target with meterpreter, how do you listen on port 445? A few weeks ago this topic resurfaced again in part due to Dirk-jan (@_dirkjan) that saw this question flying by in the #bloodhoundgang slack channel and asked me to look into it. This sounded like fun to figure out and he promised that if it worked, he’d document a working setup that would be able to perform SMB relay attacks through meterpreter. Turns out, this is an already solved problem with readily available tools out there, but not a lot of people are aware about the solution.
We will explain how you can leverage these tools to perform relay attacks on a target on which you have a meterpreter session. The added benefit of this approach is the fact that you don’t need python2exe or a whole python stack on the infected host, just a simple driver and a meterpreter infection will do the trick.
The first part of this blog will focus on the thought process of being able to hijack port 445 and the second part of this entry will focus on making it usable for relay attacks. If you want to skip the thought process and relay setup you can also skip directly to the already available solution:
The rest of this entry is divided into the following sections:
Who is the owner of port 445?
Hijacking and redirecting port 445
The full SMB relay setup through meterpreter
Please note that we took the easy route while writing this blog post and just put all the files on the disk. If you want to avoid that we suggest that you use a ram disk solution or expand the current meterpreter in-memory execution functionality to support something similar to this.
The magical ‘in memoryexecution‘ option of meterpreter is of course one of the better options that we as attackers love to use. However if you want to store ‘random files’ in memory or need to execute more complex applications which contain dependencies on other files, there is no ‘in memory’ option for that as far as i know. To be more specific, on Linux you can do it with build in commands, on Windows you need to install third party software (list of ram drive software). I decided to dig into it and see if I could achieve this through a meterpreter session. The reasons for wanting a ram disk are multiple, if you are still wondering:
store stolen data in memory only, until you can move it
execute applications which require multiple files
running multiple legitimate files from memory
You might be asking, why not use it to bypass AV? This is of course possible, but you would need to modify the driver for this to work and ask Microsoft to sign it. To bypass AV there are enoughmethodsavailable in my opinion, I sometimes just want to be able to store multiple files in memory.
Where to start? I decided to start with the ImDisk utility for two reason:
It is open source
It has a signed driver
The first reason allows me to better understand the under the hood stuff, the second reason allows me to use it on Windows versions that require a signed driver. First thing I tried is to use the bundled tools, but it seems that the command line interface has a dependency on the control panel dll file. I tried a quick recompile, but then I thought, why not code my own version? The original version includes, amongst other things, the ability to load and save the ram disk as an image file and for the moment I won’t be needing that functionality. So i decided to code my own reduced functionality version of the original client. It would have been easier to just use the original client, but this was more fun and thought me a thing or two about driver communication.
The original source code was very very clear, which made it a breeze to hack together some code to talk to the driver. I still need to add way more error handling, but for now it does the job and you can use it through meterpreter. Be aware of the fact that it still leaves traces on the regular hard disk, like explained in this blog. A short overview of the traces left behind:
The dropped driver
The registry modifications to load the driver
The driver loading does not use a service, thus there is no evidence of a service creation
The mounted ram disk
Traces of files executed or placed on the ram disk
For me the benefits of having an easy way to execute multiple files from memory outweigh the above mentioned forensic artefacts. In addition it becomes more difficult to retrieve the original files, unless the incident response team creates a memory image or has access to a pre-installed host agent which retrieves the files from the ram disk. Let’s get practical, here is how to use it through a meterpreter session (I won’t go into details on how to obtain the meterpreter session):