Our agenda will be the first introduction, we will introduce ourselves and what we do,
and after that we will look at the Red Team side of the things, and the DevOps side of the things,
and lastly we will meet them together in an example, and after that we will look at how
can we maintain our automation codebase. So we're both Security Engineer Center and
member of Blackbox Security and ITCAT. We're frequently blogging at Trento Tech and we're
performing Red Team and Zero-Day Research at our leisure time. So what we're doing is we're
planning a Red Team engagement and with that plan we are designing our infrastructure and
iterate over it with our team, and once it's stable we're automating our infrastructure design
using Terraform, and after that if the operation will take longer than usual or we will reiterate
one of our infrastructure automation scripts, we will create a pipeline for change management
so that we remove human error altogether. So the Red Team life cycle looks like this.
Usually you're doing external reconnaissance and once you compromise a machine you do
the same on internally until you get domain admin and domain dominance, and after that usually the
company has some target machine and target file to exfiltrate, and until you exfiltrate that file
you continue your loop of reconnaissance and remote code execution.
The operational models for Red Team are like this. The first one is full scope annotation
test. Although it's a controversial one, you can count it as a Red Team because
you have black box scope and you're attempting to gain a full tilt into the target and
steal the data. So it's really kind of targeted attack and although it provides a
data point about the state of a security program, it needs a lot of time and resource.
The similar one but the difference is the long-term Red Team operation. It really needs you to work
towards the company like you're an actual attacker for a year or two, and it has advantages
for the company that you will map their own network and the key divisions so that they can
harden their security posture throughout the time. And the hardest part for a Red Team is
you have to maintain your access over a long period of time. The other is the classic Red
versus Blue wargames. It will strengthen the Blue Team's muscles against the Red Team activities,
techniques, and procedures. And also Red Team's muscles against the Blue Team's in terms of
they will see how the Blue Team handle their attack etc. So the wargames are usually in a
simulated or some scenario-based environment and they are really good to have time to time
within the company itself. And the last one is Adversary Simulation. In this Adversary Simulation
scenarios, they are based on some APT or mock-up scenario based on a realistic timeline. So you're
basically imitating some APT attack or some kind of scenario that the company would like to assess.
So the goal is to exercise that attack without getting identified or discovered
by Blue Teams. So these events are really good for the company because the states and the scenarios
are step by step so they can see where they fail or where they are succeeding at every step.
So in the light of our operational models, there is also Operation Security. It's a term from the
military and it means that denying adversarial information from the opposite side. So as a Red
Teamer, you should be able to deny any information that you may have from the Blue Teamers on the
other side. In the wild, some threat actors have operational security mistakes throughout time.
And let's look at the recent errors. And the first example is just botnets. They were
discovered and doxxed because of not encrypting their C2 servers and the chat sessions.
The other example is Forceful. He's a Russian botnet developer and he gave up his C2 server
used to carry out the data stacks. So he also got exposed. And the last example is the recent one
is IBM researchers found out a huge repository that got exposed due to a security setting
misconfiguration. So if you look at these examples, you can clearly see that the security
settings misconfiguration and also some error due to the C2 or the other elements
that might be have human error is compromising operations. So it happens all the time.
So that's why actually we need an automation. Infrastructure design for the standard
penetration setup is like this. You usually have some team server and you're directly accessing
organization throughout this team server. And usually the team server's assets,
IP addresses or domains are white listed by the organization for penetration testing to test
more clearly. But in the red teaming setup, you usually have different type of servers
behind some kind of redirector, whether it would be traffic or Nginx or HAProxy, etc.
So you have multiple servers behind the redirector. The reason for that is you can
easily build defense and recover your infrastructure against exposures from the blue team.
That's why the redirector approach is more blending into the organization's traffic when
it comes to the operational side of things. So when we design our infrastructure, we should be
able to consider a few things. The first one is the leanness of our infrastructure.
Because we want smooth operation and complicated infrastructure means more maintenance time or
more time to... more things to look at. So it's the last thing that we don't want.
The second is the segmentation. Your tools of choice must be segmented according to
the functionality and they must be accessed from the redirector, not to be directed directly
because of the exposure risk from the blue teamers. So these three gain us interdependence
for our infrastructure. Every part... since every part is interdependent from each other, if
some of them... some of it got exposed, we can quickly destroy and set up again a new one.
And the network footprint from the redirector is a thing to be considered so that we can
imitate some real traffic from our redirector to the company. So blue teams are... don't find us
that easily. And also the engagement domain is also important. Whenever we plan an operation
to a company, we always choose a domain from that company's domain category. We... at least
you should try to select it that way. And the payload and C2 specifications are important
for the... for the opposite side because you should... you can... it's... is your operation
more truly if you will use phishing. You should be able to consider the... the three elements
when you design your infrastructure because you might need then some SFTP mail server or
maybe third-party service if you will use. Also domain fronting if you will use it as well.
You should consider it once you... you're starting your design. And last is access control and request
processing. The... you should always exercise access control for your infrastructure and more
importantly the request processing because if you have some kind of request processing mechanism on
the redirectors, you can relay the blue team that if... if your redirector IP or domain got discovered
and blue team were to visit that domain or IP address or were to mmap or some discovery...
run some discovery, you can redirect them to or relay them to the actual domain or the website so
that you can avoid their work, discovery work. So this... the last... the last thing is the
one of the most important things when you consider your design.
So let's look at the DevOps side of things. DevOps is mainly... is creating self-service
infrastructure for teams and since it's self-service and contains automation, it
removes human element and which also removes manual and slow procedures so that you can
continue work continuously and more lean... lean and fast. So why we are using automation? For every
red team engagement, since they... all engagements are most... most of the time are unique,
you have to plan and design an infrastructure and you need to set up it from UI or some best
script or some kind of means. And if you do that by hand for every engagement, it becomes more
error-prone and slow procedures and it's boring. So we're using automation. So for automation,
using infrastructure as code, it's... it helps you to define provision and manage your infrastructure.
So if you codify all of your infrastructure, you can track version changes or also validate
changes and remove human elements from the infrastructure deployment procedure because...
because it will be done from the code that you're writing. So the provisioning and deployment
process automation is key in here. For infrastructure as code, there are a couple of tools.
Chef, Puppet, Ansible, Sustack, CloudFormation and Terraform are common tools for DevOps practices.
But why we are using Terraform? Terraform and... except Terraform and CloudFormation, the other
tools are mainly configuration management tools and designed to manage existing software.
But CloudFormation and Terraform are provisioning tools. Although they have some little degree of
configuration management capabilities, they are mainly... are for provisioning the infrastructure itself.
And as we said, as the other slide states, CloudFormation is mainly for AWS. So Terraform
has multiple cloud support, so we are using Terraform for it. And if you couple Docker with Terraform
for the configuration management, all of your needs will resolve itself anyway.
And also why we are using Terraform is also have another reason. In DevOps, there is a term called
configuration drift. It happens when you maintain an infrastructure over a long period of time.
They differentiate one another in terms of the software version, etc. So if you're using
Terraform with Docker, you reduce the likelihood of these differences, because the every change
is actually mean a new deployment. And another thing is Terraform have declarative style of
coding. We can give an example for that is if you have 10 instances and you have to automate it
in Ansible, you're automating it like this and in Terraform like this. But if you will have one
more instance on top of that 10, you have to rewrite your Ansible to count is as 1. And on
the other end, in Terraform, it's 11, and Terraform will take care of the mathematics itself. So you
don't have to write new Ansible, you don't need to write useless scripts anymore, because
with Terraform, you can update your existing one and it will keep working.
So the last part is the samples require master and agent to operate.
But Terraform is masterless because it directly talks with APIs, so that it removes the need of
master, server, and agent, which will make our infrastructure more lean.
And one of the design considerations that we have is the leanness, so Terraform
also suits with it. And in the light of this, we have three common combinations when it comes to
build and automate our infrastructure. The first one is Terraform and Ansible
for provisioning and configuration management. But as I said, for Red Team operation, we need
as lean as possible, so Ansible might not work in that scenario, because it requires master,
server, and also some agents to operate. The other is, if you're using some virtual machines,
you can use Packer to template your virtual machines and deploy it with Terraform.
And the last and our recommended approach is using Docker and Kubernetes to orchestrate your
infrastructure assets and deploy them with Terraform, so that everything is to be taken
care of with Kubernetes. And also, nearly all of the cloud providers have managed Kubernetes
service, so you can also take advantage of that and leave the management site for Kubernetes to
them. And you can just deploy your Docker with the configurations that you want and
leave the management site to them, so that you can operate more easily. And let's get the demo.
Hi everyone, this is Caglar. Today we are going to demonstrate building a Red Team
operation infrastructure in AWS. We choose AWS, but you are free to use other platforms as like
Alibaba or Google Cloud Platform or your own private cloud. Our demo has four phases. Inspecting
scripts, run scripts and build infrastructure, payload execution, and destroy. In our demo,
we just create a simple network topology, but you can extend it with your needs or requirements.
Let's take a quick look to our Terraform and Helm scripts. In our repo, we have four important
Terraform scripts. The first one, vpc.tf file, lets you provision a logically isolated section
of the AWS cloud, where you can launch AWS resources in a virtual network that you define.
You have complete control over your virtual networking environment, including selection
of your own IP address range, creation of subnets, and configuration of root tables and network
gateways. Aks cluster file lets you create a Kubernetes cluster with one worker. In our demo,
we deploy Nginx, Ingress, and Metasploit managed with Aks. Helm file is used to deploy Nginx and
Metasploit to worker. The last one is security group. This file is used for access control of
communication server and services. And also, we have a file to see outputs of our scripts for
debugging. Let's start building our infrastructure with Terraform. First of all, if you are not using
a root account, you have to create a user and attach a policy to access AWS services.
After user creation, you should add credentials to your profile.
Let's initialize our script and validate. It seems everything is fine. Just deploy it.
It seems everything is ready now. Let's check status of Kubernetes classes, nodes, and ports.
Let's execute our payload. Now, we are ready to destroy all infrastructure.
Everything is clear now. Thanks for listening.
Now, let's get the maintenance part. So, as you see, we are to validate, deploy, and destroy
at every stage of our testing. So, we can automate it with GitLab CI. And for it,
we use init and validate first to test our scripts head check. And after that, we are using
apply to deploy it. And if we were to deploy, we should be able to get the state so that we can
destroy it afterwards. And after deployment, the last part is the destroy, but it should always
work in the pipeline because if you were having some problems with deployment, some of your assets
would get deployed, but some of them are not. And if the destroy stage does not work, these
deployed assets will be online all of the time. So, we should use destroy part always in our CI,
always in our CI with the destroy command. And it will destroy our infrastructure after testing
so that we can validate our codes. And we can also see if our infrastructure got deployed
correct or not. So, main takeaways from our research and the work is choosing correct tools
whether it would be some engagement tools or automation tools. You should always choose
whichever you are comfortable with. And for every red team engagement,
whether you're doing some long-term penetration testing or red teaming or adversary simulation,
do not make your infrastructure complex. Try a lean and interdependent infrastructure.
Try to build and the domain choice of the things as we mentioned before. Do not make your
infrastructure complex so that you can manage it easily. And at last, use automation and CI
so that you can test and validate all of your infrastructure so that you don't have any
surprises during the engagement itself. If you have any more, if you have any questions,
we will be on Discord throughout the day. You can ask it. And as I've said, we will
share the link of the slides in the Discord as well so that you can also reach GitHub page.