hello my name is stefan von puy and
welcome to my first and hopefully not
last defcon talk
today i will be presenting my autonomous
lateral movement technique that i have
developed
at my time as an intern at prelude
research incorporated
so before we get into it i'd like to
discuss a little bit about myself
so currently i am a rising senior
mechanical engineering student at
virginia tech
hopefully there are some fellow hokies
watching
um and i know what you might be thinking
mechanical engineering
uh how does that relate with cyber
security well that's where my time at
prelude research incorporated has come
in so keep in mind i'm an intern i've
only been doing this for two months i'm
not super familiar with the field yet so
if i make any mistakes please bear with
me let's hop in
so the tools that i'll be using i'll be
using preludes operator which is a
command and control center
i will be using two linux virtual
machines which will be labeled as
workstations a and b and which we will
discuss in the next slide and i'll be
using agents and adversaries agents are
remote access trojans in which this case
i will want to upload
and have it connect back to me
and adversaries are a culmination of
ttps which i will use in my attack
finally we have aws which will be used
as a redirector which will allow me to
have connections to workstations a and b
and proxy back to my local laptop which
we will talk about in one moment
so what is the goal
the goal of this attack is to gain
control of workstation b through the use
of agents and have full control using
prelude operators command and control
center which will allow me to distribute
and execute ttps to that said agent
allowing me to navigate and use the
laptop or network server
what is the plan
so as we can see here
that little circle me is that local
computer that i'm currently recording
this talk on right now
i have connection to an aws redirector
which allows me to connect to
workstation a
in this scenario workstation a is a
remote worker's laptop
so i drew inspiration from this tac
or i drew inspiration for this from the
not-patch attack where they got access
from a
worker's laptop and from there laterally
moved on to the it network that's what
i'm going to be recreating here
so workstation a for the sake of
simplicity we are already going to say i
have access to so that is a workers
remote laptop
remote work laptop
workstation b is the it network
so we know that workstation a and b have
a connection because that worker has
connection to
the it network in the real world that
could be through a vpn which allows the
worker to have access to any company
securities or protocols
so what we're missing is that purple
dashed line
that arrow so what we want is we want to
establish a connection between
workstation b and that aws redirector
which will proxy back to my local laptop
that is our goal in this plan
so
there are really only three steps and
i'm going to be describing in this first
half of the talk my
on paper details of the attack so the
three steps are the first one is to
identify any known hosts on workstation
a
secondly we will use those known hosts
that we find to secure copy an agent in
this case the pneuma agent that
prelude supports
the new agent over an ssh connection to
laptop b or workstation b
and thirdly we will remote activate that
agent over an ssh connection and have it
connect back to our aws redirector
now i know there are plenty of ways to
do this and as i mentioned i'm still a
beginner in this field and through my
research i found secure shell
connections to not only be versatile on
their use but also on the simpler side
for me to understand
so this is the first step of code
we're going to cat which will allow us
to read the contents of a file and in
this case we're going to do that in the
hidden ssh directory in the node known
hosts file or list so we want to cap
that and read that and these are the
outputs of that
the outputs as you can see are the known
hosts there so the ip address and also
on the right you can see parse results
which we'll get into
later when we make it autonomous
so now you can see that we have parsed
an ip address or the known host
now secondly we're going to move to
secure copy net
so the way ssh works if anyone's not
familiar we're going to secure copy
the file that we want for the contents
the host
at ip address
and then the location of where we want
to copy it to on that remote user
so
since aws supports linux os and in this
case we're using the default hostname
for that is ec2.user
which is why i took a stab and just
guessed for that that's why you can see
that's the hostname i'm using
and in this case the location that i'm
distributing that numa agent is in the
hidden directory ssh because at the time
i figured you want to place it in
somewhere that's more obscure obviously
so
no one can find it you'd be a little bit
more discreet
the outputs of running this command over
operator are
or follows with a green dot which means
that it was successful a red dot would
mean is a failure
step three is to remote activate it over
ssh
so again ssh hostname at ip address or
the known user that we grabbed
the
numa agent right here this is the
properties we're going to run it in a
detached terminal
have it beacon back to my aws address
right here
and send any outputs or errors to null
once again just to be a little bit more
obscure and discrete
and these are the outputs of that
you see green so successful
so through those three steps we found
local we found known hosts we secure
copied our agent and we activated our
agent and the results of that are we
went from workstation a
to workstation b
so we're done
nope not yet
we're gonna have a little bit more fun
with it and make it even better
we're gonna make it autonomous
or automated
so now let's hop back into prelude so
that was the first step that was
basically like our on plan on paper plan
so now let's go into here and i want to
describe one feature to you all right so
now we're in operator i want to talk
about their use of custom facts
custom facts are variables that are
saved to an agent as a fact
as you can see here operator supports
very many default ones
so now going into
our editor
we can see the manual adversary the
boring way so we can see that in the
known the parse host
there's an expected output a domain a
file and an ip these are all facts so
these are all variables saved to the
agent as a fact which can be called on
and later used to create a chain which
will make things a lot simpler in this
attack
so now let's get into the automated way
tweaking the code a little bit in action
and adding an extra line allows us to
deploy this adversary and have it
connect to
any ips or any host available to it that
we have connection to
just with one click of the button so
once again we'll start with parse known
hosts
again we will search and find and
document any hosts
but what we are really looking for is
this expected output we want this
ip.t1018
we're going to use that again
so next step would be to secure copy
we're going to secure copy and now you
can see that the code is a little bit
different than it was before
this is a fact agent location is a
default fact and operator that takes the
agent's location the property location
so in this case
it's somewhere in the home user's
address i'll show i'll show it later on
but it knows
it knows where to find it
so we're going to secure copy that agent
location on workstation a which contains
all the newer properties
to the username which i'll go back to
at the ip address that we grabbed from
parsing the known hosts
and we're going to upload it to this
location a temporary full temporary
directory
pneuma linux
so now going back to this username this
is the only manual part that i put into
this attack
since i knew that the default user for a
os linux on aws was ec2.user
dash user i added that as a custom fact
and i could add anything i could do
adversary.village
and say us
not sure how that would fit into this
code but if you have any suggestions let
me know
so now you can see that i previously
added the user.name
ec2.user that's the only manual thing
that i did in this
so now going back to the automated way
we're going to secure copy that numa
location on workstation a
to the username at ip address from
the parsing known hosts
next we're going to look at how to
remote activate it to ssh remote
activated so we have the username and ip
address run in detached terminal
and what we want is our numa executable
right here our agent executable
to make it automated i included a fact
but to be able to grab this fact i added
one more line of code
what we're going to do is over an ssh
command we're going to list
the contents of
that temporary directory that we
uploaded uploaded our new
linux agent to as you can see the
expected output is file
t1021.004
that is what we're looking for and we're
going to put that right in here so that
it knows that this is where the agent
location
is on workstation b
we're going to name it workstation
underscore b and have it addressed back
to operator.tcp
that is the aws um
tcp port address
and then once again we're going to send
the
outputs and errors to null
so now we have four steps all automated
and now let's test it out
so here we have workstation a
and we're going to scroll down to our
adversaries and find our automated the
fun way
and we're going to deploy it
and just like that we have now connected
to workstation b autonomously
now the difference is in the manual way
each step relies on each other so two
requires one three requires two and one
so if i wanted to secure copy or do any
ssh command i needed to first know what
the known hosts were and then manually
go back into my code and change that in
this way
operator knows how to intuitively pick
up the facts that it's learned and
incorporate them into the next step
which creates a chain of attacks
now if we look into what actually
happened we can see that it occurred
twice
so we found hosts
and it actually picked up two different
ip addresses
if it uploaded the numa to different two
different ip addresses
it once again remote listed both of them
to create that fact that we wanted and
then remote activated each the problem
is is i don't have credential access to
one of the ip addresses but i have it to
i only have it credential access to one
so if this were a real-world scenario
and you were deploying this attack on a
network that had several connections and
credential accesses to you it would
result in a lot more agents connecting
back and even more expansive network of
agents that you control now
all right so now if we look in here we
can see the known hosts so we can see
the ip address of
the
network that we connected to the it
network and
the results of doing that
and the activation which resulted in our
workstation b
alright and that was it for my
presentation on my lateral movement
technique
on preludes operator
once again my name is stefan von puy as
you can see my contacts are empty
knowing you guys are all professionals
in the cyber security field i am sure if
you want to contact me you will find a
way
follow along on the blog the prelude
blog because this was phase one out of
my four phase attack and come back in
when i conclude my attack fully
thank you so much for your time and i
hope to be at the next devcon
have a great day bye