everyone and thank you for joining my
talk my name
is gilberton and today i'm going to talk
about red team challenges
i will also demonstrate how we tackled
these challenges
in our team and enable you to do so in
yours
before we dive in a bit about myself i'm
originally from israel but currently
based
in singapore hacking was always part of
my life
resulting me in trying to figure out how
i utilize technology and science in
order
to basically make my life easier i have
over five years of experience within the
cyber security industry
where i started from application
penetration tests
through infrastructure engagements and
red teaming
my expertise lies around enterprise
security
and the related aspects of it
today i work at signia consulting as an
offensive security engineer
being part of its security research team
i am available on many social networks
which are listed here
so feel free to reach out
first let me give you some context
we have to admit it red and purple
teaming
became harder throughout the past years
retinals are struggling with challenges
during engagements this is because
organization organizations
lifted up their detection capabilities
and also
integrated advanced security solutions
this caused the execution of even basic
red team tasks to get complicated
organizations have also a variety of
products and vendors
incorporated in their networks making
techniques that worked in one
organizations
to fail or get detected on another
logging and monitoring capabilities were
also enhanced
we are recorded 24 7 by the big brother
sim and
its sock siblings so avoid triggering
alerts during an operation
became a challenge by itself
to handle the situation adversaries
spend even more time on the
weaponization phase
and this is done prior and during the
operation
many times these tasks are repetitive
and
sometimes cause delays due to technical
issues
and these technical issues we have all
experienced before
let me ask you a question how many times
have you weaponized the same tool or
how many times you helped a colleague to
use a technique
that you found or used speaking about
colleagues while working with a growing
team
that are divided across multiple
engagements
we realized that new challenges were
added
these challenges include working from
home due to the covered era
or back-to-back engagements also
new developments that team members
created got lost
as soon as they finished their
engagements
so we understood that we want to have a
better platform to collaborate on
in my opinion having a base standout can
enable
equal capabilities across your team
members
now whenever we do develop
or discover a new capability we have to
somehow
store it right there are
many documentations and methodologies
out there and
every day a new exploit technique or
tool
are released so
sometimes it's hard to follow and
incorporate
every technique in your methodologies
while being busy
on with multiple engagements
security teams are also sharing thoughts
during
whole conversations or coffee breaks but
memorizing and storing this entire
content in an efficient way
became complicated so until elon musk
will provide us his neural link we have
to find a solution
we understood that we want to import
more automation
into our engagements as we want to
reduce
the time on repetitive tasks which we
are not really interested in
we know that the community already
adapted the cicd pipelines concept
to automate tasks that are related to
offensive tool weaponization
offensive ccd pipelines have been around
for a couple of years
with the goal of helping great teams to
automate
their tasks i'm not going to talk in
detail about cicd
but we are going to dive into the
advantages
of using it for offensive needs
i truly believe that we cannot automate
the entire editing operation
as we need to bring our own expertise
knowledge
and way of thinking we want to have a
mind behind the operation who can take
decisions
in real time and according to the
feedback he receives
so then you will be able to put more
focus on bypassing
new barriers which he never tackled
before
we started exploring the cicd area and
perform a research that
ended up with a pain that we really
wanted to solve
this pain pushed us to design and
develop
our own offensive pipeline framework
while focusing on the needs of our
growing adversarial team
such needs include simplicity
as being part of a growing team we
wanted to onboard
new members to use that concept easily
and also make it even simpler for us so
the migration
will be faster there is also a need for
modularity
the framework must allow the developed
techniques
to be packaged individually so we can
mix between them
when assembling pipelines that weaponize
different tools we wanted that the
framework will be able to maintain
itself so
we don't add overhead to ourselves by
making it we're looking for a system
that anyone can contribute to so the
efforts
will be gained from each and every team
member
this is because we have all many
engagements and any of our team members
solving complex challenges
that we can then uh share back
to our uh offensive pipelines framework
we want also that the environment's
infrastructure
be controlled by us since
the sources and the tools we are trying
to recognize
considered malicious and we don't want
them to get
analyzed or blocked
does having these frameworks on a sas
solution
could create obstacles throughout the
way
also while performing a letting you
sometimes in a need for a specific tool
this tool can aid you with achieving
your goal and
we all know that we may lose the
the operation when having delays during
it
we have to remember that each engagement
get
different artifacts so it will not
affect
other other engagement if the device and
the collection of the
of the tools will be will be
lost its reputation but
now considering all these needs
we ended up choosing gitlab as the core
of our framework if you're looking at
the
high level description we may predict
that
it can answer our needs and let me
explain
why we researched a variety of
frameworks
such as jenkins circle ci github actions
and appvio which served us for the past
year
where we learned the power of having ccd
concepts
within your security needs
these tools didn't really came up with
our needs
even gitlab was not perfect i actually
started
going over their source code when i saw
a possible constraint
but still high level is debris
gibberish so let's discuss the technical
aspects of it
so gitlab started off being code
repository version control
allowing you to store and manage sources
of of your tools
gitlab also provides a restful api
which allows you to automate anything
that you can basically do
manually it comes together with a
detailed documentation
that can save you some time when you try
to figure out how to approach a call
a must-have feature is the gitlab ci
providing you with
the ability to create pipeline jobs
which i refer
as recipes this is done
in a simple and organized manner through
the yaml format
files the ccd also offers multiple
integrations to different systems
where you can execute your job recipes
for example
as part of the ci concept you you need
to execute your jobs
in an operating system either linux or
windows
it can be on a single server or on a
container
and having a support
with docker and kubernetes can help you
with achieving the goal
faster jobs can also be executed on
on specified conditions for example
on a push that you you just did your
repository
or whenever another pipeline just
ended successfully or
being triggered by another pipeline
the multiple pipeline support allows to
trigger several pipelines through
executing only one
for example when we perform a rating we
tend to use
a collection of tools and we don't want
to
weaponize them one by one right we want
to trigger
one pipeline that will deliver all of
them
to ourselves i believe that this is just
the tip of the iceberg and i'm pretty
sure that you'll find
additional features to use in the future
let's see a simple example of an
offensive pipeline recipe
in motion the pipeline starts off
cloning the rubios tool a c-sharp tool
from the code repository
then the tool gets built using a job
that we define
containing the dependencies for ms of ms
build
the compiled binary passes to the next
stage
would get obfuscated using confuser ex
the confused binary then passes to the
next stage
where it gets wrapped by a.net assembly
loader
those letting us
to execute a dotnet tool via powershell
finally it gets deployed to your
favorite bucket
so you can download it from anywhere you
want
in addition we also deploy it here to
our point drop server which is a server
that allows you to manage the way you
download your files
another example can go with powershell
where we use the tool
invoke domain passwords plane in this
time we don't need to build it
but aggregate it from few powershell
scripts
the combined powershell script is then
passes to the
next stage where it get where it being
obfuscating
or force obfuscated with chimera that
a tool that designed to bypass ansi and
i2 values
when obfuscating powershell scripts
then it goes directly to the last stage
when it gets deployed
to our pawn drop server so we'll be able
to download
and execute it on the targeted
environment
in the same way we made may add
additional sources
of different tools and define the
pipelines with jobs
that we already developed and this is
where
the modularity plays its significant
role
for desert we can use the pipeline
triggering options
or gitlab api to trigger
multiple pipelines based on different
groupings
this enables us to weaponize
tens and hundreds of tools in minutes
today i want to introduce scallops
scallops is a framework that empowers
red teams by enabling them to put
more focus on what they need to do
instead of
how to do it and this can be achieved by
designing
great recipes
let's dive in to see the possibilities
of this framework
so
after we authenticate to our git lab we
can see that it contains few
repositories
the one the first one is the ci recipes
the same recipes is a collection of all
the yaml files that could contain the
jobs
that we are using to weaponize our tools
the three other repositories
are tools that we want to recognize
now let's say we want to add additional
tool
and in this case we want to add the
sharp edl checker what we're going to do
is that we're going to enter the ci
recipes tool
the ci recipes repository
and add the relevant direction
for the sharp edl checker tool
and this time we'll use the web id which
is very useful here
and you will see few sections within
this repository
the relevant repository for the tools
are is the
tools controller where you can see the
recipes of the different tools we want
to weaponize
the tools index contain all the tools
that are imported
to the gitlab instance
to add the additional tool we have to
create an additional object within this
array
and provide it with the sharp edl
checker
git repository link
we have to also specify the name of the
project in order to for the
automation to not uh to distinct between
the other projects
and also create a recipe for it
so it can be automated
with the whipponization of itself
because the its recipe is not existing
yet
we have to create it
using a new file
and because sharpie dr checker is a
seashell
file that was built seemingly the same
to a built-in structure
the same as rubios we can actually copy
the same recipe
and change the relevant namings
we have to remember which stages are we
going to execute
in this in this case we are going to
build obfuscate
and deploy it now all the
relevant jobs are included within
the yammels above
now when when we commit tools index
we actually trigger a pipeline
that automatically imports the tool
you can see that the pipeline was
triggered below
and a job was created
we let the job to work and see how we
we designed it to do it so under the cia
maintain we included many things that
maintain the
framework and the infrastructure itself
and in tools import
we have the import public tools job
where it reads the tools index file
and compare it with the existing
project within our gitlab instance
eventually it imports imports
the leftover tools
as you can see the job was succeeded we
also have
the api output here and we can see
that sharp edl checker was added to our
projects list
let's trigger its pipeline and see what
happens
if you remember we pointed it at builds
obfuscate
and deploy stages
as you can see there are three different
stages with each
job on each of them so let's understand
each and every job let's go to the build
job
which will possibly be under the ca
builders
in shoptools.yammen
here we're using a customized windows
container
where we created it to contain the ms
build
and all its relevant dependencies to
build c-sharp tools
it will build it with it will compile it
with the release configuration
and eventually upload it to the job
artifact
so the next job will be able to pick it
up
the next stage is confuse is obfuscating
with the confuser ex which will be under
ci obfuscations
the confuser ex also executed on a
container a customized container that we
created for it
it starts off fetching the previous
the artifact from the previous job
and executing the confuser ex
features to obfuscate the
compiled binary eventually
it will also upload the compiled
obfuscated binary
to the job artifact so the next job will
be able to pick it up
the last job is deploy to pawn drop
let's take a look
at what it is
it will be under the ci deployers point
drop deploy.job
it will be executed on a linux container
and if you noticed we are actually
weaponizing our tool
through two different operating systems
with different dependencies
and this is done in no time
for deployment to pundop we have to
provide this job relevant
variables that it will be able to
reach it and upload the files in with a
with the relevant access since we didn't
provide these variables
this jo this job will be failed
let's leave it here and go to the
to to take a look at the multi pipeline
feature this is will also be part of the
ca recipes
and we want actually to build and
trigger the pipeline of the three
repositories that we had
so we already made a ad yaml under the
under the ci multi pipeline
folder where there are three different
jobs that actually trigger the pipeline
of the
other repositories
when we supply the the condition to
to execute these jobs are when you
supply the ci multi-trigger variable
together with the relevant value and in
that way
we can tag different group of tools
in order to trigger their pipelines
together in an efficient way
let's execute the pipeline of the ci
recipes
in order to choose the relevant the
relevant
the relevant pipeline
as you can see we have the ci
multi-trigger
variable here which execute multiple
pipelines
so we want to execute all of them and
they all have the
all terms so we just write all and since
we want to
deploy them to our point of server we
have to provide
its url and also its right key
we'll copy it and enter into the
variables
we can extract the right key from this
green button
don't enter don't enter this
just take the right key now
we can run the pipeline
and see that the
relevant repositories pipelines
were triggered directly from here
we can see that powerup sql was
triggered rubios
and also grody these tools are made from
three different different languages that
we wanted to show you
rubio's passes through the build of
boost case and deploy in the same way we
did we sharped the out check here
because we copied that
power of sql goes through shimera and
deployment and god just go to get built
and being deployed
now we'll wait for the pipelines to
finish in order
to see what happened so
green indicates that everything was done
successfully
let's take a look at the output of the
powerup sql jobs
so we can understand what really
happened
we see that a lot of obfuscation values
here and we see
that it also uploaded the artifact for
the next job
here in the pen drop deploy we'll be
able to see that the job succeeded and
we can see also the response from the
pawn drop
it means that all the files that we just
created all the pipelines should be
right here deployed
let's change the way that shimera is
being
downloaded and take a look at the file
so as you can see all the strings looks
obfuscated and randomized
even the a function's name
so looks very useful
the last thing i wanted to show you is
the docker files
we are actually storing our customized
docker files
within the maintain folder where there
is
a job that that can pick them up and
build build them
on top of another container this is only
supported with linux
and is maintained through a google
project named kaniko
we actually can take this docker file
and build it
through our pipeline managing
all the infrastructure and this
framework
as a code
you can see that we have a special
variable to trigger that kind of
pipeline
if we'll take a look at the ci recipes
pipeline and try to trigger it
we'll be able to provide
the name of the docker files we want to
build and push
docker file build linux is the name of
the variable and now
we will enter the name of the docker
file
the prefix of it that we want to
actually build and push
as you can see a new job was created
named build linux
linux container and this job
is can be found under the ci container
builders
where it actually uses the kaneko
project
eventually it pushes the container
to our private container registry
great so
i hope you enjoyed the demo and after
we've seen all the magic
let's understand what is the
infrastructure
running behind the scenes of this
framework
so we start off having we start off
having the gitlab instance
and this gitlab instance comes with the
built-in ci cd
to execute our jobs we are using
kubernetes cluster
where we have two different node pools
one node pool for executing
linux related jobs and the other one for
executing
windows related jobs in order for the
kubernetes cluster to communicate with
the gitlab instance
gitlab created something called gitlab
runner which is
a helm deployment that you can deploy to
your ribbon to your kubernetes cluster
which will act as a proxy between the
gitlab instance and the kubernetes
cluster
it will receive jobs from the gitlab
instance
and instruct the kubernetes cluster how
to to execute them we also created
another gitlab runner deployment
that responsible for the windows related
jobs
our kubernetes cluster is connected to
our container registry where we are
storing our customized
container containers to use during
the operation and the pipeline execution
now having this framework on-prem can be
nice and great
let's assume that we can also shift it
to the cloud
and using in this example google cloud
resources
in order to host it and in this time we
created the kubernetes engine
together with google container registry
which
communicate perfect where we attached a
service account with the relevant
permissions to push and pull
containers the
kubernetes engine and the gitlab
instance
can communicate communicate internally
because they are sitting
on the same vpc we also added
a google store cloud storage to allow
ourselves
storing some utilities that we will be
we will need during our pipelines
we also created a firewall rule to allow
us operate the framework and use it
and actually enjoy it without
exposing it to the world internet
everything is sitting on a single gcp
project where we can
maintain it in one place
the gitlab then can import tools
from a remote git repositories
and as part of
the scalabs framework we are releasing a
telephone script
that will allow you to deploy the exact
same environment
in your cloud this comes with the
built-in recipes we've just
shown before
all you need is a gcp subscription and
a web browser refer to the project's
repository
and follow the instructions
few words about the cloud costs we can
divide
it to idle and to per job because
we want the framework be a waiting for
us so
when we want to operate it and run the
pipelines
but we're not always continuously
running pipelines
so so there is a need to operate two
instances that are utilizing most of our
credit
also there is a per job credit
that takes out when you previously
provision new nodes
and this is very tricky because you may
provision
one node and create one job which will
translate it into one pod but if you
create
10 jobs simultaneously they will use the
same credit
unless you plan you plan to supply
weaponized tools to the world community
the bottom line is that you have to pay
less than 100 us dollars a month in
order to use
this framework
additional thoughts that came up to my
mind during creating the framework and
also
the this presentation is are that
this can be a community driven framework
we just released the infrastructure the
the code of the infrastructure
and also the ci recipes repository
itself
allowing people to collaborate and share
their techniques
through a through one place where anyone
can enjoy and share
this can be done in the same way people
are sharing today
cobble strike aggressor scripts
there will be another problem
coming up to you after using this
framework because
now you will be able to speeding speed
up the tasks that
you're using you're doing when you
performing
reactive engagements finding yourself
collecting
all the the enumeration reconnaissance a
lot of information
in no time so you find yourself trying
to understand how you
process all this data now
also if your team will really
take take the decision to
use this framework in an efficient way
you may
end up finding an operator executing
a task that bypassed few security
tools security defensive tools
when where they the operator will not
even know how we bypass them
and i'm not into not knowing what you're
doing but
this is the thing that can happen which
may enable
additional people to pers to perform
adversary simulations
and ratings also
i believe that the question about
commanding controls
came up to your mind and we are not
planning on replacing them with the
offensive pipelines but
we do have to use them together because
command controls are very monitored
tools
by the detection and prevention security
tools
and also they are not they are not
getting
enough updates so you may find yourself
using an
old update of some tool and
and trying to figure out how to load a
new tool
now also with the offensive pipelines
you may
find yourself grabbing your bitcoin
agent or grant from your favorite
command control
perform the obfuscation and evasion
techniques
on it send it back to some hosting
server
so we will be able to download and
execute it on the targeted environment
without getting detected
i also listed here the references to the
technologies
that this framework leans on
you can go ahead to extend your
knowledge about every byte and bit
that actually created this framework
i want to thank anyone who took part in
designing this framework and
also for anyone who helped me who helped
me with preparing this presentation
so thank you very much and also
thank you for staying up until now
i hope that that that you
enjoy the talk and consider to adapt
cicd concepts into your ratings
i will be taking your questions
feedbacks and comments
on the discord server see you there bye
bye