start	end	text
520	5620	Our agenda will be the first introduction, we will introduce ourselves and what we do,
5620	10860	and after that we will look at the Red Team side of the things, and the DevOps side of the things,
10860	17200	and lastly we will meet them together in an example, and after that we will look at how
17200	24920	can we maintain our automation codebase. So we're both Security Engineer Center and
25140	31760	member of Blackbox Security and ITCAT. We're frequently blogging at Trento Tech and we're
31760	38240	performing Red Team and Zero-Day Research at our leisure time. So what we're doing is we're
38240	44340	planning a Red Team engagement and with that plan we are designing our infrastructure and
44340	50700	iterate over it with our team, and once it's stable we're automating our infrastructure design
50700	59280	using Terraform, and after that if the operation will take longer than usual or we will reiterate
59280	64760	one of our infrastructure automation scripts, we will create a pipeline for change management
64760	73020	so that we remove human error altogether. So the Red Team life cycle looks like this.
73020	78300	Usually you're doing external reconnaissance and once you compromise a machine you do
78300	85080	the same on internally until you get domain admin and domain dominance, and after that usually the
85080	93960	company has some target machine and target file to exfiltrate, and until you exfiltrate that file
93960	100940	you continue your loop of reconnaissance and remote code execution.
101900	108260	The operational models for Red Team are like this. The first one is full scope annotation
108260	114300	test. Although it's a controversial one, you can count it as a Red Team because
114300	119520	you have black box scope and you're attempting to gain a full tilt into the target and
119520	128120	steal the data. So it's really kind of targeted attack and although it provides a
128120	134100	data point about the state of a security program, it needs a lot of time and resource.
134380	141600	The similar one but the difference is the long-term Red Team operation. It really needs you to work
141600	147960	towards the company like you're an actual attacker for a year or two, and it has advantages
148540	156180	for the company that you will map their own network and the key divisions so that they can
156180	163080	harden their security posture throughout the time. And the hardest part for a Red Team is
163600	171120	you have to maintain your access over a long period of time. The other is the classic Red
171120	179680	versus Blue wargames. It will strengthen the Blue Team's muscles against the Red Team activities,
179680	188740	techniques, and procedures. And also Red Team's muscles against the Blue Team's in terms of
189190	200990	they will see how the Blue Team handle their attack etc. So the wargames are usually in a
201080	208000	simulated or some scenario-based environment and they are really good to have time to time
208000	215080	within the company itself. And the last one is Adversary Simulation. In this Adversary Simulation
215600	222420	scenarios, they are based on some APT or mock-up scenario based on a realistic timeline. So you're
222420	229600	basically imitating some APT attack or some kind of scenario that the company would like to assess.
229600	237780	So the goal is to exercise that attack without getting identified or discovered
237780	245080	by Blue Teams. So these events are really good for the company because the states and the scenarios
245080	252040	are step by step so they can see where they fail or where they are succeeding at every step.
252580	259560	So in the light of our operational models, there is also Operation Security. It's a term from the
259560	267060	military and it means that denying adversarial information from the opposite side. So as a Red
267060	274920	Teamer, you should be able to deny any information that you may have from the Blue Teamers on the
274920	284880	other side. In the wild, some threat actors have operational security mistakes throughout time.
284880	295000	And let's look at the recent errors. And the first example is just botnets. They were
295000	301240	discovered and doxxed because of not encrypting their C2 servers and the chat sessions.
301320	310800	The other example is Forceful. He's a Russian botnet developer and he gave up his C2 server
311400	318280	used to carry out the data stacks. So he also got exposed. And the last example is the recent one
318280	325300	is IBM researchers found out a huge repository that got exposed due to a security setting
325300	332880	misconfiguration. So if you look at these examples, you can clearly see that the security
333960	340580	settings misconfiguration and also some error due to the C2 or the other elements
340580	350000	that might be have human error is compromising operations. So it happens all the time.
350100	356540	So that's why actually we need an automation. Infrastructure design for the standard
356540	362300	penetration setup is like this. You usually have some team server and you're directly accessing
362300	369360	organization throughout this team server. And usually the team server's assets,
369360	375880	IP addresses or domains are white listed by the organization for penetration testing to test
375880	382300	more clearly. But in the red teaming setup, you usually have different type of servers
382300	391240	behind some kind of redirector, whether it would be traffic or Nginx or HAProxy, etc.
391240	398460	So you have multiple servers behind the redirector. The reason for that is you can
398460	406860	easily build defense and recover your infrastructure against exposures from the blue team.
406860	417320	That's why the redirector approach is more blending into the organization's traffic when
417320	424780	it comes to the operational side of things. So when we design our infrastructure, we should be
424780	430600	able to consider a few things. The first one is the leanness of our infrastructure.
431280	438360	Because we want smooth operation and complicated infrastructure means more maintenance time or
438360	445420	more time to... more things to look at. So it's the last thing that we don't want.
445420	451920	The second is the segmentation. Your tools of choice must be segmented according to
451920	463220	the functionality and they must be accessed from the redirector, not to be directed directly
463920	473060	because of the exposure risk from the blue teamers. So these three gain us interdependence
473700	479020	for our infrastructure. Every part... since every part is interdependent from each other, if
479020	485900	some of them... some of it got exposed, we can quickly destroy and set up again a new one.
485900	491120	And the network footprint from the redirector is a thing to be considered so that we can
491120	498180	imitate some real traffic from our redirector to the company. So blue teams are... don't find us
498180	506580	that easily. And also the engagement domain is also important. Whenever we plan an operation
506580	513440	to a company, we always choose a domain from that company's domain category. We... at least
513440	521460	you should try to select it that way. And the payload and C2 specifications are important
521460	531260	for the... for the opposite side because you should... you can... it's... is your operation
531260	538420	more truly if you will use phishing. You should be able to consider the... the three elements
539220	545400	when you design your infrastructure because you might need then some SFTP mail server or
545400	552040	maybe third-party service if you will use. Also domain fronting if you will use it as well.
552040	559200	You should consider it once you... you're starting your design. And last is access control and request
559200	564880	processing. The... you should always exercise access control for your infrastructure and more
564880	571940	importantly the request processing because if you have some kind of request processing mechanism on
571940	579720	the redirectors, you can relay the blue team that if... if your redirector IP or domain got discovered
579720	588240	and blue team were to visit that domain or IP address or were to mmap or some discovery...
588240	597060	run some discovery, you can redirect them to or relay them to the actual domain or the website so
597060	605700	that you can avoid their work, discovery work. So this... the last... the last thing is the
605700	609380	one of the most important things when you consider your design.
609980	615820	So let's look at the DevOps side of things. DevOps is mainly... is creating self-service
615820	623880	infrastructure for teams and since it's self-service and contains automation, it
624540	630980	removes human element and which also removes manual and slow procedures so that you can
630980	640540	continue work continuously and more lean... lean and fast. So why we are using automation? For every
640540	646860	red team engagement, since they... all engagements are most... most of the time are unique,
646860	653880	you have to plan and design an infrastructure and you need to set up it from UI or some best
653880	660480	script or some kind of means. And if you do that by hand for every engagement, it becomes more
660480	668380	error-prone and slow procedures and it's boring. So we're using automation. So for automation,
668380	675660	using infrastructure as code, it's... it helps you to define provision and manage your infrastructure.
675660	682400	So if you codify all of your infrastructure, you can track version changes or also validate
682400	688300	changes and remove human elements from the infrastructure deployment procedure because...
688300	694020	because it will be done from the code that you're writing. So the provisioning and deployment
694020	702480	process automation is key in here. For infrastructure as code, there are a couple of tools.
702520	709660	Chef, Puppet, Ansible, Sustack, CloudFormation and Terraform are common tools for DevOps practices.
710400	716360	But why we are using Terraform? Terraform and... except Terraform and CloudFormation, the other
716360	721500	tools are mainly configuration management tools and designed to manage existing software.
721500	727240	But CloudFormation and Terraform are provisioning tools. Although they have some little degree of
727240	733560	configuration management capabilities, they are mainly... are for provisioning the infrastructure itself.
734020	741100	And as we said, as the other slide states, CloudFormation is mainly for AWS. So Terraform
741100	750020	has multiple cloud support, so we are using Terraform for it. And if you couple Docker with Terraform
750920	758780	for the configuration management, all of your needs will resolve itself anyway.
759340	766760	And also why we are using Terraform is also have another reason. In DevOps, there is a term called
766760	775100	configuration drift. It happens when you maintain an infrastructure over a long period of time.
775100	782260	They differentiate one another in terms of the software version, etc. So if you're using
782260	788800	Terraform with Docker, you reduce the likelihood of these differences, because the every change
788800	795440	is actually mean a new deployment. And another thing is Terraform have declarative style of
795440	803220	coding. We can give an example for that is if you have 10 instances and you have to automate it
803220	810180	in Ansible, you're automating it like this and in Terraform like this. But if you will have one
810180	819700	more instance on top of that 10, you have to rewrite your Ansible to count is as 1. And on
819700	828200	the other end, in Terraform, it's 11, and Terraform will take care of the mathematics itself. So you
828200	834820	don't have to write new Ansible, you don't need to write useless scripts anymore, because
834820	841790	with Terraform, you can update your existing one and it will keep working.
842400	848760	So the last part is the samples require master and agent to operate.
849020	855960	But Terraform is masterless because it directly talks with APIs, so that it removes the need of
855960	862460	master, server, and agent, which will make our infrastructure more lean.
862980	869100	And one of the design considerations that we have is the leanness, so Terraform
869100	877020	also suits with it. And in the light of this, we have three common combinations when it comes to
877020	880920	build and automate our infrastructure. The first one is Terraform and Ansible
882060	889120	for provisioning and configuration management. But as I said, for Red Team operation, we need
890040	896160	as lean as possible, so Ansible might not work in that scenario, because it requires master,
896160	904340	server, and also some agents to operate. The other is, if you're using some virtual machines,
904340	910880	you can use Packer to template your virtual machines and deploy it with Terraform.
910920	918260	And the last and our recommended approach is using Docker and Kubernetes to orchestrate your
918260	924540	infrastructure assets and deploy them with Terraform, so that everything is to be taken
924540	934220	care of with Kubernetes. And also, nearly all of the cloud providers have managed Kubernetes
934220	941020	service, so you can also take advantage of that and leave the management site for Kubernetes to
941020	948100	them. And you can just deploy your Docker with the configurations that you want and
948100	957730	leave the management site to them, so that you can operate more easily. And let's get the demo.
958580	963100	Hi everyone, this is Caglar. Today we are going to demonstrate building a Red Team
963100	968580	operation infrastructure in AWS. We choose AWS, but you are free to use other platforms as like
968580	976940	Alibaba or Google Cloud Platform or your own private cloud. Our demo has four phases. Inspecting
976940	982840	scripts, run scripts and build infrastructure, payload execution, and destroy. In our demo,
982840	988700	we just create a simple network topology, but you can extend it with your needs or requirements.
990800	996980	Let's take a quick look to our Terraform and Helm scripts. In our repo, we have four important
996980	1007580	Terraform scripts. The first one, vpc.tf file, lets you provision a logically isolated section
1007580	1012640	of the AWS cloud, where you can launch AWS resources in a virtual network that you define.
1012640	1017320	You have complete control over your virtual networking environment, including selection
1017320	1024420	of your own IP address range, creation of subnets, and configuration of root tables and network
1024420	1033680	gateways. Aks cluster file lets you create a Kubernetes cluster with one worker. In our demo,
1033680	1045560	we deploy Nginx, Ingress, and Metasploit managed with Aks. Helm file is used to deploy Nginx and
1045560	1055060	Metasploit to worker. The last one is security group. This file is used for access control of
1055060	1064060	communication server and services. And also, we have a file to see outputs of our scripts for
1064060	1074300	debugging. Let's start building our infrastructure with Terraform. First of all, if you are not using
1074340	1079600	a root account, you have to create a user and attach a policy to access AWS services.
1096370	1100710	After user creation, you should add credentials to your profile.
1101190	1138690	Let's initialize our script and validate. It seems everything is fine. Just deploy it.
1169860	1210380	It seems everything is ready now. Let's check status of Kubernetes classes, nodes, and ports.
1223390	1244650	Let's execute our payload. Now, we are ready to destroy all infrastructure.
1258060	1261020	Everything is clear now. Thanks for listening.
1263180	1270260	Now, let's get the maintenance part. So, as you see, we are to validate, deploy, and destroy
1270760	1278400	at every stage of our testing. So, we can automate it with GitLab CI. And for it,
1278400	1286220	we use init and validate first to test our scripts head check. And after that, we are using
1286220	1295240	apply to deploy it. And if we were to deploy, we should be able to get the state so that we can
1295240	1301200	destroy it afterwards. And after deployment, the last part is the destroy, but it should always
1301200	1313380	work in the pipeline because if you were having some problems with deployment, some of your assets
1313380	1318540	would get deployed, but some of them are not. And if the destroy stage does not work, these
1319120	1328820	deployed assets will be online all of the time. So, we should use destroy part always in our CI,
1328820	1336220	always in our CI with the destroy command. And it will destroy our infrastructure after testing
1336220	1345420	so that we can validate our codes. And we can also see if our infrastructure got deployed
1346100	1353500	correct or not. So, main takeaways from our research and the work is choosing correct tools
1354060	1362540	whether it would be some engagement tools or automation tools. You should always choose
1363100	1371840	whichever you are comfortable with. And for every red team engagement,
1371840	1378240	whether you're doing some long-term penetration testing or red teaming or adversary simulation,
1378240	1385920	do not make your infrastructure complex. Try a lean and interdependent infrastructure.
1385920	1393160	Try to build and the domain choice of the things as we mentioned before. Do not make your
1393160	1400240	infrastructure complex so that you can manage it easily. And at last, use automation and CI
1400240	1405980	so that you can test and validate all of your infrastructure so that you don't have any
1405980	1413380	surprises during the engagement itself. If you have any more, if you have any questions,
1413380	1418380	we will be on Discord throughout the day. You can ask it. And as I've said, we will
1419260	1424600	share the link of the slides in the Discord as well so that you can also reach GitHub page.