greetings ics village
thank you all so much for joining me
today
i hope you're all doing well and your
families are
staying safe and healthy i'm very
excited to be here today to talk to you
about
living off the land in an ics ot
penetration test
so brief introduction on myself my name
is aaron boyd
i'm a senior industrial penetration
tester here at dragos
i live in denver colorado my background
is mainly been in security architecture
type roles in verticals such as oil and
gas
manufacturing and aerospace i do hold a
couple of cyber security certifications
mostly in the offensive discipline
and let's just jump right into it so
talking about an example ics environment
is really difficult because
as penetration testers we never know
what type of environment we're dropping
into
whether remotely are on site we have no
idea what type of configurations we're
going to be up against
what kind of architecture is in place
but there are typically two
commonalities that we see
more often than not and
the first of the commonalities is
there's usually
no internet access at least we hope
there's not any internet access
and with no internet access we don't
have a way to
download our payloads or our scripts or
establish connectivity to our
centralized command and control
infrastructure
in addition to no internet access there
is usually
usb restrictions whether usb itself is
completely
disabled through the machine bios or
there's group policy objects and
enforcing the restriction of removable
media
so with these two things we have no real
way
to get data to the environment get data
from the environment so what do we do
we live off the land and i'm going to be
talking about
one of these techniques today but first
let's talk about what living of the land
actually is
so living off the land is a broad term
that
describes the use of pre-existing
utilities
on windows operating systems or networks
that are known
and trusted with legitimate capabilities
but we flip that script and use it for
nefarious purposes
and there's a link here in the
presentation to a drago's white paper
that talks a little bit more in depth
about living off the land in ics
or ot cyber security but as far as this
presentation goes i wanted to touch on
four key points about living off the
land
first point being living off the land is
likely not going to be detected by
antivirus
as most of us know some ics environments
may not have any of ours
if at all and if there is antivirus
leveraging the existing tools and
utilities on the machines or network
prevents us having to download files to
the disk
which prevents us from getting detected
quickly
in addition to that these living off the
land
binaries are commonly used in a lot of
environments
so if monitoring has been implemented
we do hope that the monitoring is tuned
to your environment
because a lot of these things generate a
fairly significant
amount of logs and with that those
looking at those logs
the risk is increased for alert fatigue
or false positives being decided
additionally a lot of these are trusted
by default because they're
windows operating system binaries
natively
on the disk that are digitally signed by
microsoft
and if they're not natively in the
operating system they can be downloaded
directly from the microsoft website
so if you have antivirus in your
environment or you have
application whitelisting with a rule
that blocks
executables binaries or scripts from
unknown or untrusted publishers
this gets around that defense mechanism
and another one that doesn't get a whole
lot of attention when talking about
living off the land
techniques but it does happen is the
trust relationship with vendors
so sometimes work is performed in an
environment from a trusted vendor
and this can be done from either an
implementation or support standpoint
so when we drop into an environment and
we see tools a vendor is leveraging
a lot of times there's potential for us
to use those tools
so because you're already accustomed to
them you trust them
you expect to see it we can leverage it
and it'll just look like
normal behavior so as i mentioned
there's lots and lots of different
living off the land techniques
and i was going to focus on one today
and it's one that
i personally have had more consistent
success with
and that is bits
bits admin is a command line tool to
manage
the background intelligent transfer
service and microsoft windows
so bits admin is used to either
create jobs to either download upload
copy or transfer files and
it can also be used to monitor the
progress of already existing jobs
and the native binary location for bits
admin is your system 32 or sis wow 64
directories and in addition to that
there's also
some powershell commandlets for
interacting with
bits admin and the bit service so
talking about
bits from a high level i'm going to ask
three questions first
do you pat your systems if you do
there's a
strong possibility that whatever
solution you use
leverages bits to download and apply
updates
for example on your enterprise machines
you have google chrome
browser of choice periodically checks
for updates
if you look at your windows event viewer
logs for operational bits client data
you will see both these browsers
periodically checking for updates
i'll get in the windows event viewer a
little bit later in detail
but because that behavior is expected at
normal
chances are it's going to be successful
do you have application whitelisting
implemented
with a lot of application whitelisting
solutions it's not uncommon for there to
be
a default rule to either automatically
trust execute or
elevate microsoft signed applications or
binaries
like i touched on if you've got a rule
to block unknown
untrusted publishers the fact that a lot
of these living off the land binaries
bits admin for example signed by
microsoft gets around that defense
mechanism
and just another homage to antivirus
a lot of times or sometimes antivirus
may not be installed in a lot of
environments
or if it is it has a lot of exceptions
to not
interrupt the process and
i will say that some antivirus providers
are getting better
with detecting abuse of a lot of these
living off the land techniques
for example i know the latest
definitions and updates for windows
defender
if you execute bits admin.exe to create
a job
it's going to trigger on that in windows
defender
there are ways around that i'm not going
to get into detail on that here
but the potential is there so i'm
talking about bits admin
you're probably asking me do i have an
example
of course i do so let's paint the
following
scenario we have access to an operator
workstation this operator workstation
could be running an hmi or a dcs that's
running in full screen view
there's not an easy way to get rid of it
if you are able to get rid of it
then you've got group policy objects
applying at the machine level
applying other restrictions preventing
you from traversing the file system on
the machine
or other restrictions that we commonly
see
we do have ways around a lot of this
again i'm not going to go into detail on
any of these
but for the sake of time let's just
assume we bypassed
all these restrictions and now we've
attained
a powershell prompt at this point we
start enumerating the machine
we look at the host information we look
at the user information
we look for things like startup scripts
if the machine is domain joined
startup scripts log on scripts log on
log off
startup shutdown are commonly configured
through active directory group policy
objects with the scripts being located
on their domain controllers depending on
the importance of those logon scripts
there's a good chance that those scripts
are also going to be locally stored on
these machines
and that's just an extra set of
redundancy in case the domain
controllers
or domain goes down for any reason those
scripts still run
the function of those scripts can vary
greatly but the more common ones i've
come across are
mapping network drives checking the
context of the user that's logging in
applying restrictions
just to be an extra layer of security
so with those scripts locally on the
machine a lot of times there's
access control lists or other
whitelisting type mechanisms
implemented on those directories where
the contents are protected
from non-administrative users so let's
actually go through the process
of discovering the startup script
so as mentioned we've got the powershell
prompt
and we can pass this get item command to
enumerate the registry
to look for items that run at logon and
in this case we find one
called bat located in the scripts
directory
on the c drive so curious about what
that script is and what it contains we
pass the type command on it
to see the contents in this case it's
just a simple
demo script that says this is a startup
script demo for living off the land
once we see the startup script we look
at the permissions on the script with
icackles
to see who's got permissions to either
modify it make changes
etc and in this case only the nt
authority system of the machine itself
and administrators on the machine have
full access
to the script so in
wondering this operator user we have a
powershell prompt on
are they inadvertently added to the
administrators group
and through using the net user command
we can
see that the user is not a member of the
administrator group
so therefore the account will unlikely
be able to make changes
to that script i always like to do an
extra set or just a second piece of
verification
just in case there's something else
running in the background
to overwrite access control lists and in
this case
that did not work because i opened the
script in notepad
i tried to make a change just by
appending a test
before that pause command and attempting
to save it
we can confirm we don't have permission
to that file
however we do have the permission to
copy that file
save it on our desktop and then make
changes to it
which is exactly what i did here so i
copied that script put it on my desktop
added those two lines to create a new
local user
and add it to the local administrators
group on the machine
so now that i have this script on my
desktop the registry key says
run the script in the scripts directory
so i need to find a way to take the
contents of the script on my desktop
and have it be placed over writing the
script in the scripts directory
here's where bits admin comes into play
so with bits admin hike it runs in an
elevated context on this machine
it runs as either administrator or
system because of those auto trust
application whitelisting rules so even
though the context of the user i'm
running the command
doesn't have permission of that file
because bits admin runs in an elevated
context
it should overwrite the permissions of
the user
so in this case i basically am telling
bits admin
create a transfer job and call it dragos
if you're doing this on an engagement
be mindful of the job you're naming it
because
bits admin and bits client in general
natively
stores these logs in windows event
viewer like i mentioned earlier and like
i'll mention again later
where if you're naming it something
blatantly obvious
it's going to stick out like a sore
thumb if somebody's monitoring the logs
so once creating the job called dragos
which we can see that happens
successfully
i'm adding a file to that job with
source and destination
so i'm telling the drago's pit's admin
job to add this file
source file being that startup script on
my desktop with a destination
overwriting what's existing in the
scripts directory
and as we see it was able to add
the source and destination file
successfully because we weren't
presented
with an access denied message so
once i saw that happen now we can resume
the job
which is our way of telling bits admin
we've got no further changes to the
drago's job
just go ahead and add it to the queue
for processing
depending how bits is configured in the
environment it could either process it
immediately
or process it on a predetermined time
frequency
in this case for the proof of concept
and the demo
i wanted it to go right now so i told
bits admin just go complete this job
called dragos
and we're able to see the job completed
to validate there's no other jobs in the
queue
or just bits admin already did my
bidding i'm good
i'll pass bits admin reset just to clear
the queue
in case there were any other jobs hung
up in this case there were none
so to really confirm this worked the way
i intended
i now type the output of the drago's
batch script in the
scripts directory and we can now see
those two lines appended
to create a new local user and add it to
the administrators group
now even though we were able to
successfully overwrite this script using
bits admin
we still have another hurdle to get over
so in order to add users to a machine
and add them to the administrators group
we need to have administrative
permissions on the machine
which our operator does not have so for
proof of concept
just assuming this is a penetration test
we would then reach out to our point of
contact with the client
and say something along the lines of
like hey
something might not be working the way
intended we're not sure if this is a
restriction
on our account or something wasn't
configured properly
would you mind logging in just checking
we have the access you intended us to
have
and everything is working properly
before we proceed
with our engagement a lot of times
they'll say yeah sure
not realizing that this request is part
of the engagement
which happens a lot so they log in with
their administrative
permissions and the script executes
successfully
as we can see with the image on the left
there's the context
you know it's a startup script demo
living out the land
the command completed successfully twice
so we can assume that dragos was the
dragos user was created
and they were added to the
administrators group now to someone
that's seen
the output of the script many many times
it's safe to say they would either just
minimize it or close it because they've
seen it so many times
they expected no changes they wouldn't
notice command completed successfully in
this prompts
if they weren't aware so once that
script runs
they do their thing they check and make
sure they tell us
yeah everything is working as intended
we say okay thank you for validating
you know we're good to go from here
we'll continue with the engagement
so we'll log back in with the operator
account achieve that powershell prompt
again
now we run the net users command to see
the users on the machine
and we can confirm dragos is a user
so now we can run powershell as the
dragos user
and you can tell by the prompt below we
ran a who am i just to confirm
and enumerated the local administrators
group on that machine
and confirmed dragos is an admin we now
have admin on that box
so assuming this machine is domain
joined
we can now turn off a lot of those usb
device restrictions
if they were being applied through gpo
and interact with the lsas.exe process
creating a memory dump of it
extracting it offline looking to harvest
and tlm hashes
hopefully there's going to be a domain
account we're able to see for
lateral movement that we can harvest for
past the hash activities
or we can extract you know the the sam
security system hives
out of hkey local machine for impacted
secret stump or um
we can enable w digest on the machine
and reboot it
and try to capture credentials and clear
text
for next logon attempts so as i
mentioned
there are so many living off the land
techniques and what i demonstrated today
with bits admin
is just one example of the capabilities
of using it for nefarious purposes
so assuming we're in an environment with
internet access
we can also use bits admin to download
files from the internet
and execute them immediately and
another living off the lan technique run
dll32
we can download our malicious dll file
replace an existing legitimate one and
execute it
achieving a callback to our centralized
command and control server
or if you really wanted to get fancy
with it you can by creating one-liners
to either run a command or a sequence of
command
and one of the common questions i get
asked when
presenting conversations like this is
aaron why are you
telling us all about your ttps you know
if it's successful for you why are you
risking it getting burned
as penetration testers at dragos we're
not here to point fingers we're not here
to judge
we're here to raise awareness and
there's
a lot of belief especially me personally
that there's been
so much attention put on the prevention
of these things from happening
and not enough attention on monitoring
and detecting it
because as you saw there was an access
control list
on that scripts directory where an
operator or owner would think only
admins can make changes to this
directory
or good i demonstrated pretty quickly
no i was able to get around that so with
that
if something were to happen if you
weren't monitoring or looking for it
you'd have a tough time answering the
questions how did it happen
when did it happen who did it so with
that
i want to jump into how you can detect
this activity
and one of the ways to do that is
monitoring windows event logs
because like i mentioned this is enabled
and turned on by default
in the microsoft windows operating
system and the event log captures
everything related to the bit service
and these logs are located
in this location of the event viewer
applications and services logs
microsoft windows bits client
operational
and there's five event ids i recommend
paying
particularly close attention to so event
id3
is bitservice created in your job this
is the equivalent of me doing
bitsammon.exe forward slash create
dragos that's me creating the drago's
job this would show up in event viewer
event id3
drago's job was created event id4
transfer job is complete again that's me
forcing it to go ahead run it right now
don't worry about the queue there should
be no user
manually creating or completing job
jobs with bits admin event id5
the job is cancelled like i had
mentioned if there's someone trying to
get
bits having to work it's not working the
way they think they created
numerous jobs they're just sitting there
hanging they want to clear it all and do
a clean slate
they do bits admin exe cancel to wipe
out all the jobs from the queue
if anyone does that on a machine
something's going on
right then and there and then event ids
59 and 60
will just word it as starting and
stopping the job
but the interesting thing about both
these ids is
they also contain the download or upload
urls that might be interesting
so if the machine does have internet
access looking at these event ids will
tell you
where bits is going to download jobs so
something is being
downloaded from a source that's not
normal you'd be able to see that in the
event viewer
natively if you're not capturing windows
event viewers assuming you've got some
other type of log aggregator
whether it's syslog sysmon or you've got
another sim
like splunk pay attention to the command
line options like i demonstrated
so transfer is the transfer of a file
from one location to another
and the example i did i just copied it
so it's still
maintained on my desktop but let's
assume there's a dll file
in a trusted directory and i don't want
to have it anywhere else i just want it
there
or in another location i can run bits
admin transfer
to physically move it from one location
to another
again like i mentioned there should be
no users going in manually creating or
adding files to jobs
and the set notify the set minimum retry
set custom headers
all those are defense evasion techniques
so if you've got community rules
snort anything like that that's looking
for common headers found
in iocs attackers can pass that set
custom headers to set a custom header
to evade that defense mechanism and
resume
like i had mentioned no user should be
going in manually doing these jobs
and like i mentioned earlier bits admin
can also be interacted with
through powershell so also pay attention
to your
powershell logs or other admin type logs
that can also contain information
relating to bits activity
i know turning on those powershell logs
can be super tedious
but at least you can just look for these
commands that i've highlighted on the
screen here
as it relates to bits admin
so like i mentioned there's tons of
living off the land binaries and scripts
bits admin is only one of them we've
used
a handful of others actually many others
in our engagements
successfully so if you're leaving here
curious
what other types of binaries and scripts
are out there for living off the land
techniques
i will share this project with you it's
open source and community driven
where they talk about other potential
binaries or scripts used in living off
the land techniques
and the site is interesting not only
because it talks about
how they are and how they're leveraged
but they also post
if applicable mitigation or detection
strategies with them
so if you are curious and other living
off the land techniques
detections and mitigation strategies for
them i highly encourage you to go visit
the site
bookmark it check it on a periodic basis
because it is being updated as new ttps
are discovered so with that
i'd like to thank you for being here
with me today hopefully i didn't ramble
too fast for you
please feel free to reach out to me with
any questions you have
i can be reached by my drago's email
which is a boy to dragos.com
or feel free to reach out to me and
connect with me on twitter
my handle is at ics underscore blitz and
i'd be happy to answer
any questions that you may have
again thank you for being here with me
today thank you to
defcon and the ics village for giving me
the opportunity to be here
i hope you and your families all stay
safe and healthy and i hope to be able
to meet with you all
one day soon take care