hello and welcome to practical malware
analysis and triage
my name is matt kiley i go by husky
hacks and i will be your instructor for
this course on the art and science of
malware analysis
so let's do a quick who am i
when it comes down to it i am a guy that
tries to learn something every single
day as i said my real name is matt kiley
and i go by husky hacks online
i am a cat dad that cat that you see in
the middle there that little black and
white tuxedo guy his name is cosmo
you'll actually be seeing him a little
bit more during this course
and he's a black and white tuxedo cat
and i love him very much i am also a
mountaineer i have summited mount
kilimanjaro like you can see up in the
upper right hand corner i've done much
of the new hampshire white mountain
ranges i was through hiking the
appalachian trail i got pretty far and
then had to turn back because of the
covet 19 outbreak but i do plan on
getting back out there and finishing it
someday i'm also a marine corps veteran
and i was staff at mit lincoln
laboratory in their space systems and
research division as their lead cyber
security analyst now some of my
education credentials i have a bachelor
of science in i.t from northeastern
university in boston massachusetts and a
graduate certificate in cyber security
from the rochester institute of
technology i was also previously a red
team operator at a large financial
institution and now i write and produce
content professionally on twitter i'm at
husky hacksmk and hey feel free to give
me a follow or just send me memes if you
want now let's do a brief overview of
this course this course is a purely
practical introduction to the field of
malware analysis triage and light
reverse engineering this course has an
emphasis on malware that is common to
the windows operating system and the
malware binary samples that have been
written for this course emulate
real-world malware ttps some of the most
common things that you'll see hitting
endpoints in your organization are going
to be emulated in these malware binaries
you're going to learn the state of the
art of malware analysis with a focus on
techniques and methodologies first and
tools second because tools always come
and go and there are always improvements
being made to tools but the
methodologies and techniques generally
remain the same now one thing i'm most
proud of is the fact that this is a lab
centered course now there are 20 plus
malware specimens in the lab repository
that was built for this course and
they're yours to poke them produm slice
them splice them dissect them inspect
them to your heart's content and the
vast majority of them were written
custom by me to reinforce the learning
concepts of this course and to be safe
for analysis you're also going to learn
how to build a malware analysis lab from
the ground up and how to handle malware
safely you'll learn how to proceed
through an analysis methodology to
extract key insights out of these
samples and along with real world ttps
you're going to learn the latest trends
in malware and tradecraft we have
malware samples written in many
different types of languages like go and
nim and c-sharp we have different types
of malware like ransomware process
injectors we have c2 agents we have
malicious documents we have malware
delivered via vbs and powershell and
much much more there is tons to explore
in this course and all of it mirrors the
real world and what's going on with
malware today and finally and maybe most
importantly this course covers report
writing and signature writing so that we
can publish well-written reports to tell
the world what we saw now let's briefly
cover the topics of this course from a
high level
we will start with safety always setting
up a lab and malware handling in which
you will learn the safe practices and
build good habits of malware handling we
will then move to learning the four
foundationals of malware analysis basic
static analysis basic dynamic analysis
we will then have a challenge binary
advanced static analysis advanced
dynamic analysis and then we will have
another challenge binary
and then after we have learned the
foundational phases we will move out to
more specialty classes of malware this
will include phishing malware like
microsoft word remote template injection
and microsoft excel macros we will look
at shell code analysis we will also look
at scripted malware delivery including
powershell and vbs we will then move on
to c-sharp assemblies in which we will
decompile and analyze the near source
code of a c-sharp assembly we will then
analyze malware written in go
and we will take a look at android
malware in the mobile applications
section finally for a penultimate course
capstone we will look at the boss fights
in which you will analyze a real world
malware specimen
after the penultimate challenge we will
look at automating the process with
jupiter notebooks and malware sandboxes
and then we will talk about writing yara
rules finally we will talk about writing
clear and concise triage reports and
organizing our notes to submit for
publication and then we will have the
course capstone which i will leave as a
surprise until we get there and finally
we will wrap up with a course conclusion
and some further readings
now i've got to say this from the
beginning and i want to set the tone
right here
this course presents risky activities by
nature but that's okay
your safety and as an instructor i'm not
just saying this i do believe this your
safety is extremely important to me
so safe malware handling procedures are
taught from the very beginning of this
course and it is critical that you
follow them at all times when you're
handling malware it never hurts to go
back and look through your configs and
make sure that your configurations are
all okay and that your host and
operating system are not going to be at
risk while we're learning these skills
and finally i just want to say thank you
sincerely this is an incredible thing to
be able to put together and give to the
community and i just want to thank you
for purchasing the course
i hope that anyone regardless of your
skill level can leave this course having
learned something and as an aside if
you'd like to email me my email is right
there or you can dm me on twitter
i love hearing from students i love
answering questions so please don't
don't hesitate reach out if you'd like
and now let's move on to the next
section here we're going to talk a
little bit about the course discord and
where you can find support and talk to
me directly on discord so we'll see you
over in that section
all right my friends let's get this
party started
in this video we're going to be going
over how to install the hypervisor that
we'll be using in this course hypervisor
is very important for malware safety
because it allows you to detonate
malware in a safe environment without
risking your physical operating system
very very important now the hypervisor
we'll be using for this course is oracle
virtualbox and i chose oracle virtualbox
for a couple reasons one it's free it's
open source it's very very easy to use
but more importantly it allows you to
take and fall back to snapshots and
that's going to be very important when
we start detonating malware in the
environment
so what we're going to do is google
virtualbox
and you can say oracle as well and
download
and go ahead and google that and one of
the first links here is going to be the
one that we want to go to we want to go
to virtualbox.org
and the downloads section you can go
ahead and click on that
it's going to bring you to this page
with the downloads for different hosts
and for this video i'm working on a
completely stock brand new windows 10
install so i'm going to install it for
windows but of course feel free to
install this on the operating system
that you own and i will throw some links
in the references for how to install
virtualbox on the different host
operating systems but in any case we're
going to download the virtualbox
installer it's pretty quick
and once it does a quick little virus
scan we can throw this right onto the
desktop right here
double click on this installer
executable to run it
and we're effectively going to leave all
of the
default settings through this
installation and you can change this to
however you desire but i'm going to
leave it to the defaults
and there will be a uac prompt right
here you can select yes there will be a
few times when this asks hey do you want
to trust anything that oracle decides to
install on your computer i'll leave it
up to you to say that i'm going to go
ahead and say yes you don't have to of
course and that's why it's asking but it
will run the installer and when you see
this right here you will click finish
and you can start oracle virtualbox
right there
and here we go if you're seeing this
window you have installed it correctly
and this is now
available to you to build the virtual
machines that we'll use in this course
and in the next video we're going to
grab those virtual machine images we're
going to build them and we're going to
get going on building our lab out so
meet me in the next video and i'll see
you over there alright everyone so i
have moved back to my physical host you
can see the changed background with this
gorgeous gorgeous view here
and what we're going to do is install
the first operating system that we need
for this course and that's going to be a
windows 10 operating system
and it's important to have a windows 10
operating system because a lot of the
malware not all of it but a lot of the
malware we'll be working with in this
course is designed specifically for
windows 10 and that's actually something
that's pretty common out in the real
world too most people use windows 10 and
therefore most malware is designed for
windows operating systems
so what we'll need to do is go find the
windows
evaluation copy
for windows 10
and one of these first links right here
try windows 10 enterprise on the
microsoft evaluation center at
microsoft.com so you know it's legit
it'll bring you over here and we can
select our iso for when the windows 10
enterprise edition we select our
enterprise iso and we can hit continue
now it will ask you for some information
here i'm not going to tell you you need
to actually put in your real information
so i'm asd asd i work at asd
llc
one person in the company i'm in the
press my email is asd asd.com
my phone number is one one one one one
one one three three
and i live in antarctica
there it is all right great and i don't
need any additional tips on this i can
hit continue
it will ask you what type of
architecture you want for this windows
operating system we will select 64-bit
that's very important that we select the
64-bit version of this operating system
and go ahead and select your language
i'm going to select english
and with all of these settings selected
you can go ahead and click download this
is a pretty big file it's about five
gigs so this may take a while depending
on your speed of internet so we'll go
ahead and fast forward to the part where
this is completely downloaded i'll see
you in a second
and here we go we have a downloaded iso
i hope you enjoyed that slight break i
myself treated myself to a nice shot of
espresso and uh it was very good but
we're back now we have our iso
downloaded
what i want you to do is find a place on
your operating system where you can keep
your virtual machines and if you look at
what i have i have my virtual machines
located in my documents section on my
physical host
and here you can see all of the virtual
machines that i've put together
now i've made a pmat section in the
virtual machines
directory that i can store all of my vms
and my isos and so what you can do is
create a section on your hard drive
where you can keep these and just copy
that right into that directory
and this will just help us keep
organized for when we're building our
virtual machines
now we will set up our windows operating
system what we need to do is go to the
new button right here in the tools
section
and we're going to set up a windows 10
64-bit operating system
now for the machine folder it will give
you this
uh default location but you can also
set it to that area that we just set up
in documents virtual machines pmat if
you so desire but wherever you put it
just make sure that you keep track of it
so you know where it is and we're going
to call this pmat dash
flare
vm f-l-a-r-e-v-m
and we'll talk about what that means
here in a second but for right now we'll
hit next we can keep our ram size to the
default two gigs of ram should be fine
for this install and we'll create a
virtual hard disk now of type vdi
virtualbox disk image
and you can hit next dynamically
allocated is fine you can click next and
for the storage amount you can leave
this to the default
and you can make sure that it goes into
the pmat flare vm section and we hit
create
now we have a placeholder virtual
machine and if we start this up
virtualbox is going to say hey we want
to start this vm but we don't know what
to do with it we don't know what image
to use and so what we need for this is
we're going to go to add
and we can go to our pmats section so
navigate to documents we'll go to
virtual machines if i do date modified
i'll go to pmat and we can select this
iso that we've just downloaded and hit
open now if there are any other isos
here we can go ahead and ignore those so
just click the virtual machine iso that
we downloaded and click choose
and we hit start
and virtualbox is going to do its thing
it's going to initialize the install if
you do see this windows loading screen
right here you have correctly set this
up and what we now need to do is install
our windows 10 iso as a virtual machine
you can select your settings that you
want and click install now
and just let this run for a little while
now you'll see this you can click i
accept the license terms go ahead and
read those if you need something to help
you fall asleep but otherwise you'll
select custom install you will click new
on the drive 0 on allocated space and
click apply leaving all of these to the
default you can click ok at this prompt
it will create additional partitions
here and that's fine you'll click next
and this will install the virtual
machine
operating system and this may take a
little while so i will cut to the part
where we pick up after the install has
completed so i'll see you in a bit now
after the install is complete you'll see
this it will restart here in a couple
seconds
and virtualbox will boot up again
it will skip by the boot from cd or dvd
and go right to the iso boot
all right now we are at the windows
installation portion of the install here
we'll hit yes to whichever your area is
you can select your keyboard i select us
we don't need to add a second keyboard
layout that's fine
now this is going to set up just some
run-of-the-mill windows installation
features we just have to click through
more or less on these because we're not
really setting this up to be
a host that we're going to use every day
we're setting this up just to be a lab
environment
now at this point it's going to ask you
if you want to sign in with microsoft
you really don't need to do that you can
just do a domain join here
and you're going to say uh whatever user
you want for this and i'm going to say
husky
we'll click next
uh super memorable password will be
password
and confirm password
security question uh one will be name of
the city i was born in and that's of
course asd
security question two is first pet's
name and that's going to be asd
and security question three oldest
cousin is bob
okay
now for this one gotta love microsoft
here go ahead and select no for all of
these settings
and we'll go ahead and say not now with
cortana we don't necessarily need
cortana for our purposes once you pass
through that section of the install it
will give you the little we're getting
everything ready for you you just have
to give it another minute here and it
should boot to the desktop
all right and if you see this awesome
gorgeous windows background you have
successfully booted to the desktop but
wait there's one more thing that we got
to do here and you're probably wondering
am i going to have to do the whole
course in this tiny little virtual
machine window and the answer to that is
only if you want to
otherwise no
what you can do is go up to devices here
and insert guest edition cd image
and this will load in a cd drive to the
virtual machine
you just got to wait a second if you go
down to your file explorer right here
and go to this pc you'll be able to see
it here virtual uh box guest additions
right here go ahead and open this up
and among all of the files that are
available here we do have the vbox
windows editions amd64 otherwise known
as 64-bit we'll go ahead and
double-click on this to install our
virtual machine tools
if you get the uac prompt you can go
ahead and click yes
and we're just going to leave all of
these to the default settings and click
install so just click through those
click install again oracle's gonna ask
you do you wanna trust everything that
we install here i will say yes you don't
have to
and you're gonna see some funky action
on the screen and you're gonna see this
right here reboot now all you got to do
is reboot the guest operating system
and then when you restart the guest
operating system the vm tools will boot
up as a service
so go ahead and log in to your account
here
and it may just take a second to boot up
you might see a cmd.exe window pop up
right here for a second and then if you
click minimize and click maximize you
now should have a better screen
resolution and why don't we go ahead and
just get rid of these little bubbles
right here and you should have your base
installed windows 10 operating system
now we're going to do something very
very important i want you to go up to
here and we're going to be doing this a
lot in this course so it's very
important you get this right if you go
up to machine
and go down to take snapshot
we're going to call this base not vase
base
install
your base install snapshot is going to
be very important if anything else
messes up through the duration of this
course you can always revert back to
your base install snapshot
and that's it for our base windows
install next up we're going to show you
how to install remnux which is our linux
operating system we'll be using in this
course and then after that we'll come
back to our windows operating system and
install all of the tools that we're
going to need to actually do the work of
the course so meet me in the next video
and we'll talk there
all right now in the last video we set
up our windows 10 base operating system
and if we're still here all we need to
do right now is go click on machine and
click pause
and that will
effectively suspend our virtual machine
we don't need to worry about this for a
little bit next up we need to find
something called remnux which is a linux
distribution that is built specifically
for malware analysis and reverse
engineering
so if we go to trusty old google we're
going to type in remnux r-e-m-n-u-x
and we'll take a look here at
remnucks.org
we can open this up and this is the page
to download the distro of remnux
we're going to go ahead and click
download
and if we're looking at the virtualbox
ova
we're going to download the ova from box
which is the primary distro
download site
and it says we can't preview this
because it's too big that's okay you go
ahead and click download
now again this is about five gigs so
this is going to take a little while so
go grab yourself a nice beverage or
maybe a snack or something and i'll see
you in a little bit
all right it looks like remnucks has
finished downloading
now we're going to
make a new directory
and we'll call this pmat
remnucks
open up that directory and we will drag
this right into this new directory that
we just created
now we can actually go ahead and open
with and you'll see the virtualbox
manager here you may have some other
hypervisors installed but don't worry
about those for now you can actually
just open this up right in virtualbox
and it's going to bring you to the
import section for this vm image we
don't have to install this from base
image
like windows 10 this is a pre-built
installation ready to go all you need to
do is import it
so we can actually rename this and we're
going to call this pmats
remnux
and we can go ahead and click import
and this might just take a second
now after the install we'll have our
pmat remnucks virtual machine guest
operating system here and we can go
ahead and click start and fire this bad
boy up
and it will go through the boot process
and bring us to the home screen this
should be pretty quick this is a pretty
lightweight operating system so it's
it's very snappy
now it should boot us right into the
desktop and open up a terminal for us
which is quite nice
so you can kind of make this smaller
again we've got a very tiny screen here
so we can get rid of these bubbles here
now what we want to do is sudo make deer
we're going to go to media and we're
going to go to cd-rom this is going to
be an empty directory that will house
the mounted cd that we're about to put
into the operating system and we want to
do a sudo mount
dev cd-rom and then we need a place for
this which is the place we just made
media cd rom
and it will say
device right protected mounting read
only that's totally fine
so we will go to
media cd-rom and ls and we should have a
whole bunch of scripts here so what we
want to do is punch up to the root user
so sudo-s it won't prompt you for a
password at this point and what we'll do
is dot slash autorun.sh
and this will bring up our
installation menu and this should
install all of the tools that we're
going to need to make this operating
system a little bit easier to work in
inside of the hypervisor
and this will take a second so i will
cut to when this is done
all right and if you see press return to
close this window you can go ahead and
hit enter
and now all we need to do is reboot
and this will bring us back out and
virtualbox will do its thing it will
load up the guest operating system
and we'll just wait to come back and we
should pop right back into our remnux
operating system but this time we'll
have a nice big operating system desktop
environment to be able to work in isn't
that nice look at that now if this
doesn't happen if this is still in a
tiny little box for you all you got to
do is go up here to click the minimize
window and then click the maximize
window and it should snap right out to
the desktop size that you have and look
at that that's what we have for our
remnux install
later in the course we're going to talk
about the networking required with this
but remnux is now ready to go
so meet me in the next video and we will
keep it rolling we're going to install
our primary windows environment which is
flare vm so meet me over there
all right my friends now we are back at
the virtual box manager here and we will
remember we paused our flair vm
operating system
now our primary operating system that
we'll be using to do this course hasn't
actually been set up yet we do have the
windows 10 but we need to install the
software that we'll be using for this
course so go ahead and click machine and
we'll click pause to unpause it and
we're back
so we'll open up microsoft edge which is
everyone's favorite browser to download
chrome
and go ahead and grab the chrome
download
and this is a pretty quick setup so just
go ahead and click download chrome
follow all the prompts we'll get the
little chrome installer exe right here
and we drop this to the desktop
and we'll go ahead and run it
and this will set up chrome for us you
can click yes for the uac prompt
and it will install chrome for us and
once chrome is installed we should get a
nice chrome browser
all right and we got a google chrome
browser so we're looking for flare vm
this github repository right here now
what is flare vm it's awesome is what it
is it is a whole operating system
install script setup that will install a
bunch of reverse engineering and malware
analysis tools on a windows operating
system it's maintained by fireeye labs
advanced reverse engineering team and
all we really need to do here is follow
the instructions on this install so take
a look at the requirements here i think
we should be good with this and what we
want to do we've actually pretty much
sorted out all of the pre-install steps
here so we've taken a snapshot of our
machine and if anything goes wrong we
can always revert back to it now what we
want to do is
right-click on install.ps1 and copy link
address and we're going to open up a
powershell prompt
and we open this up as administrator so
right click and run as administrator and
you can click yes
and what we want to do is hit enter a
couple times until the prompt comes here
and set
exec policy or execution policy and you
can tab autocomplete for that
unrestricted
and it will say are you sure you want to
do this and you can hit a which is yes
to all
and that should be good now what we want
to do is wget oops
we wget
we can go down here to install.ps1 and
copy link address and you're going to
wget that right into your operating
system and you can do a dash use basic
and hit tab autocomplete for use basic
parsing and the other argument that we
need here is the outfile argument now
keep in mind that we're currently in the
context of system32 and we don't
necessarily want to install it there
so we'll do outfile and we'll do c
users and whatever your username is so
for me that was husky desktop and we can
do install.ps1
and that will drop it right to your
desktop
of your current user and we've got
install.ps1 here if we change
directories to see
users your username for me this is husky
desktop
and we do a deer command
we'll see that my install.ps1 is right
here so all we now need to do is dot
slash install
and we're gonna let this run and this is
gonna take a very long time and it says
you have less than 40 gigs free disk
space left you can go ahead and select
yes that's fine password for user husky
and you can hit ok to that and this is
going to
do a full install of the tools in flair
vm and it will take a little while so go
ahead and let this run and i'll meet you
back here when this is complete
now after a reset or two it will ask you
to put in your auto login password so
you can go ahead and put that in mind
remember was password for the husky user
and it will keep going
oh hey remember when i said this would
take a while i i was completely serious
it takes forever
in the time that it's taken and this
isn't even done yet i have done my
laundry i have paid my credit card bill
uh i've done a couple other chores just
hang in there if you get any prompts
that say do this continue just do
whatever it needs uh it does take a
while but uh it is worth it i do promise
that so
i'll see you in a bit
all right finally it looks like we've
got our flare vm distribution installed
if we hit enter here maybe hit enter a
couple times here we should be back to
our desktop and all we would need to do
at this point is restart
and we'll put in our password of
password
and there we go we've got our awesome
flair vm background and if you see this
background it's likely that our
installation has succeeded
all right now we are at the single most
important part of this whole flair vm
installation process if you take one
thing away from this video let it be
what i'm about to say
what we need to do and i think you might
know what i'm about to say is go up to
machine
what we're going to do is pause
and we are going to take our snapshot
this is the most important snapshot that
we're going to make and this is our
flare
vm
bass snapshot
and the reason we're doing this is
because every time we detonate malware
we do not know what has changed on the
operating system maybe something was
installed into the registry maybe there
are now files in a directory that
weren't there before maybe nothing
happens at all but the idea is that if
we don't have a good baseline to revert
back to we might never uncover some of
the activity of the malware that we're
detonating and so
whatever happens if we unpause this host
and let's say that this readme.text gets
deleted and uh i mean if the malware
only did that consider ourselves lucky
but let's say that happens all we would
then need to do is shut this virtual
machine down
we'll go back to our
virtualbox manager
and we would go over here to snapshots
and we see that we have our base install
and we also have our flare vm base if
you see this current state changed you
know that something has changed between
where your vm is currently and where we
took the snapshot and what we're gonna
do is go back to restore it to the flare
vm base and click restore you don't need
to create a snapshot of the current
machine state
if you click restore we're back to our
flare vm base and we can start back up
and once it restores back to the
snapshot state we see that readme.text
is still here and effectively our base
flare vm install is still good very very
important for when we start to play with
things like ransomware and things that
install persistence so make sure that
you do that it's incredibly important to
restore to that that good baseline
configuration okay but that's it that's
our install for flare vm and we're gonna
get rolling on setting up the network
and then we're gonna start detonating
malware it should be a very good time so
let's go to the next video and i'll see
you right there
all right everybody now we are going to
set up the network that we'll be using
for our virtual machines to be able to
analyze malware now we want to do this
because we need a safe environment that
we can actually detonate or run malware
when we drop it in
and we don't want to risk our physical
operating system that's very dangerous
to be detonating malware in an area of a
network that can reach your physical
operating system so what we want to do
is set up a kind of special network
we're going to be able to put pmat flare
vm and pmat remnucks here are two
virtual machines we're gonna put them on
a network that is physically separate
from our host operating system but
logically connected so that both of
these can talk to each other but they
cannot talk out to our physical
operating system so the first thing that
we need to do let's go to the tools
section on the main gui here
and we'll click this button right here
and we go to network and in network
we have a virtual box host only ethernet
adapter right here we're actually going
to make our own for this and we're going
to specifically make one for a malware
analysis network and so what we do is we
click create
and you may get a uac prompt here asking
are you sure you want to do this you can
go ahead and click yes to that
and so let's go to the adapter tab here
on hosts only ethernet adapter number
two
we will click this dhcp server enable
and we notice that we have a 192.16
24 address that's fine but what i like
to do as kind of a best practice is to
change this ip range so that it's it's
noticeably different from something like
my home network now my home network is
set up with a
192.168. i don't quite remember what the
third octet is here but that's not too
important the real thing that i want to
get across here is to make this into
something that is noticeably different
from any of the other networks in your
area so
let's make this into a 10.0.0.1
address right here
and so for the ipv4 subnet mask you can
leave that as 255.255.2
that makes it a slash 24.
and we'll go over once we're done with
these settings right here we go to dhcp
server and we just have to fill out a
couple simple things here first one is
going to be setting this to 10.0.0.
again we leave the server mask as
255.255.255.0
the lower address bounds we're going to
set to 10.0.0.3
and the upper address bound we're going
to set to 254.
so to recap
we have a 10.0.0.1
ipv4 address our subnet mask is a slash
24
our dhcp server is at 10.0.0.
and our lower bounds is
10.0.0.3 and our upper bounds is the
upper part of the ipv4 range
and when that is all done we will click
apply
and again you may get the uac prompt
saying
you need to be an administrator to do
this just go ahead and click yes
now we go to our first vm here and we'll
click on that vm and we go up to
settings
and we scroll down to the network
settings right here
by default this is set to a nat adapter
a network address translation we
do not want this
this means if you leave this as a nat
adapter this means that your flare vm
guest operating system can route to your
physical operating system by way of its
physical ethernet adapter
we don't want that
definitely don't want that you do not
want your detonating malware to be able
to route to your physical operating
system
so what we want to do is select host
only adapter
and when we click on this we have a
couple options here we have the original
adapter that we saw and we have number
two number two remember was the one that
we just set up and we click on that now
it's worth pointing out we should check
these other three adapters right here
and make sure that they are not enabled
this one should be enabled but these
three should not you don't want some
random
adapter still live that might be bridged
into your network or something crazy
like that that's just not good if you're
detonating malware we just want complete
control over one adapter right here and
when we set it to adapter number two we
will click ok
and we do the exact same thing for
remnux we go down here we are in the
details section here and we go to
settings
and we'll go down to network same thing
we're natted over here we do not want
that we go to host only adapter and it
may default to number two here but if it
doesn't just drop it down and select
number two and check remember we're
going methodically we're going slowly
here we're doing this correct from the
start so we check to make sure that
these other adapters are not live and
they are not and that looks good and we
will click ok now we have both of our
virtual machines set up on a host only
network and they'll be able to talk to
each other but they will not be able to
talk out to
the greater internet and we will start
both of these virtual machines
and you can drag that a little bit out
of the way and i'll keep both of them
here on the screen at the same time as
they start up
all right when we boot to the main
screens here we're going to log into
flair with our password of password and
remnuck should already be set up right
here
and what we'll do is we'll check the
internet adapter settings so we'll issue
an ipa command over here on remnux and
we'll go down to the windows machine and
we'll type in cmder for commander which
is remember our kind of fancier command
terminal ipconfig
and we inspect our adapter settings and
remember we want to be in the
10.0.0.0.24 network and it looks like we
are
so over here
10.0.0.3 we are good on remnucks and
over here
10.0.0.4 we're good on flair vm and the
other thing that we want to do is
remember we want to make sure that we
cannot actually ping outside of this
network so let's go ahead and do a ping
google.com that should fail good okay
but maybe google's dns server is down or
something crazy like that let's try
pinging 8.8.8.8 that's google's main dns
server ping transmit failed excellent
that's what we want over here on
remnucks we want to do pretty much the
same thing
ping google.com should fail ping 8.8.8.8
should also fail looks good but can we
talk to each other at this point let's
try ping 10.0.0.
and we are four over here on flare and
it's looking good
and over here we do a paying 10.0.0.3
and that looks pretty good
all right it looks like we have a
network that's now set up that two of
our virtual machines can talk to each
other but they cannot talk to the
outside world and we're looking really
really good so in the next video we're
going to set up a bit of a fake internet
situation that's going to allow our
malware to be tricked into thinking that
it's talking to the internet when really
it's not so meet me over there and we'll
set that up
all right for this next section i
thought before we get into
setting up our fake internet i thought
it would be valuable to go over kind of
what this network is going to look like
the parts of it and what each part is
going to function as and so really what
i want to do is break out my new drawing
pad for this one so
follow me on a journey through the
malware analysis network
so let's say that this
laptop icon right here is our
physical
host
now on our physical host we have a
couple of virtual machines
and what we've already succeeded in
doing
is making a network that is going to be
shielded
from our virtual machines in other words
the physical host is acting
as kind of the facilitator for
everything that's going to be inside of
this network but there's no way for the
virtual machines inside to actually
route out to the physical host so we're
basically have
a couple of consoles into these virtual
machines and they have no network
capability back out towards our physical
host and that's exactly what we want
all right so let's talk about the two
virtual machines that we have inside of
this network remember this is the
10.0.0.0.24
network and really there are only two
hosts in this network
we've got over here host number one
flare
vm
and over here host number two we've got
rem
nux
flair vm and remnux flare vm is our
first one that we're interested in
because it is a windows operating system
it is important that when you're
studying malware you have a place that
you can run the malware otherwise known
as detonating it uh that matches the
architecture of what it was designed to
do so when we detonate malware and i'll
draw a little bug here so we've got this
guy
and he's got some legs
and he's got some antenna
so that's our bug our malware bug when
we detonate this
boom it will have its full effect on the
operating system because it was designed
for the windows operating system
now
it begs the question why do we have this
remnux host which is a linux
operating system and the reason for that
is because it benefits us greatly to
have an operating system that the
malware was not designed to detonate
within
and so what ramnox ends up doing is it
ends up being a couple different things
one of them is going to be an internet
simulator
so remnux has this capability where we
can set up a little program called inet
sim and it's going to respond to any
outbound internet requests that the
malware is going to make the malware is
going to say hey i'm detonating right
now i am looking i'm making an http
request to some strange website and
remnucks with this internet simulator
program is going to say oh i gotcha fam
go ahead and send me what you got and i
will send you back some information
so it helps that ramnox is sitting on
this network to be able to respond to
requests like that there are in fact
programs that do this on flair vm but
we're going to do them on remnucks so
that we have an external location to be
able to study malware the other thing
that we're going to do in a broader
sense is a network
analysis
platform
and so we're going to look at things
like wireshark and tcp dump and we're
going to take the requests that are
coming in from this malware detonation
and we're going to study them at the
network protocol level and so
broadly speaking what we want to do
is set up two different locations
one that's going to focus on host
based
indicators
and one that's going to help us with
network
based indicators
so let's say the malware detonates boom
and it changes some files over here on
flair vm
and it deletes some files or it adds
something or it changes a registry key
you're not necessarily going to know
about those host-based indicators over
here on remnucks but let's say the
malware detonates boom and it sends some
http requests over the wire we're going
to be able to pick those up using our
network telemetry meaning wireshark and
tcp and the fake internet simulator that
we're going to be putting up
and that's why it's beneficial to have
two virtual machines in this network
one to be able to study the host space
indicators and one to be able to study
the network based indicators
all right now enough of me talking let's
go ahead and set up the internet
simulator and test it so that we know
that it works
all right and we're back over here on
remnux now the program that we want to
set up to fake the internet for this
malware range is called inet sim
i net sim and if you run inet sim it's
actually quite easy to start
it starts right up and it has a whole
bunch of services and these are great
but there are well there's really one
that we want that's not running right
now so we can control c if you hit
control c out of that process it should
stop
and so before we run inet sim again
we're going to sudo
nano etsy
inet sim
inetsim.conf file and this is the config
file that inetsim uses to run the
program and hit enter
now if you have not used nano before i
will give you some pointers as we go
along so that you know how to use the
text editor for it but really any text
editor that's available on remnux can be
used to edit the text of this file so if
you find another one on remnucks that
you're more comfortable in just go ahead
and use that one no big deal anyway we
are up the top of the inet sim
configuration file and what we want to
do is scroll down to this start service
section which is right near the top and
you'll see that a bunch of the other
services are already uncommented meaning
they don't have this little hashtag
symbol or pound symbol in front of it
and we really want our dns server up and
running for our malware detonation so
what we want to do is remove the comment
and you can just hit the delete key to
remove the comment to make that a
service that will start up
so the second thing that we want to do
is we want to go find we're going to
scroll down to service bind address here
and so
what we want to do is uncomment service
bind address which is set to this
10.10.10.1
delete that and we do
0.0.0.0 and that is a shorthand ip
address assignment for all interfaces so
this will bind to all interfaces on the
host
alright next up we want to go find the
dns default
so we scroll down
and we keep scrolling and we keep
scrolling and we do find the service dns
here right here now our default port is
going to be fine as 53 because that's
the default for dns but this default ip
is what we're interested in
so what we want to do is uncomment the
dns default ip and if we just leave it
to the default it'll be
12700.1 but that's not really going to
help us we want this to be the ip
address of our
rem nux box so what we want to do is set
this to the ip remember that the ip in
this instance is 10.0.0.3
and we can actually correlate that if we
open up another terminal window or we
open up a new tab here and we just do a
quick ipa
we see that our ip address is 10.0.0.3
all right looking good
and so if we have done those things
we can then hit control o
which writes to the file
and we leave the file name as default
and hit enter
and now we can hit control x
to save and exit the file
now let's start up inetsum again we'll
do inet sim
and this time we see that our dns 53 tcp
udp is actually started along with all
of the other
services that are running and that's
good that's what we want
all right now what does inet sim do well
to do that we're going to go back to our
flair vm box which i've powered down all
right so we are back over on flare vm
and the reason i wanted to come over
here was to show you how inet sim is
going to work so we open up google
chrome and what we'll do is go to
10.0.0.3 which is the default address of
our remnux box
and if we go to that address on http we
find the default html page for inet sim
http server fake mode and look at that
it actually serves us out a default page
there's not a whole lot here but it does
give us a 200 okay
and it serves us some html
so what if we go to https colon slash
and hit enter now it will say not secure
because it doesn't have a correct
certificate the certificate is invalid
but it still serves us out something on
the page
so if you think maybe a malware sample
has detonated and it reaches out for a
second stage to some url right
this is going to serve it out and
respond to that request and say yes i am
that address send me your information
and so another interesting feature of
inet sim is if you go to something like
mals.exe
and you hit enter it actually downloads
something instead of just returning a
404 and so let's take this let's throw
it right on our desktop and let's double
click what happens inet sim this is the
inet sim default gui binary so it
actually downloads an executable to our
downloads folder
now this is useful for something like a
piece of malware that operates to
download and execute a second stage so
let's say that a piece of malware
reaches out to some url and it downloads
second
second stage
payload.exe
instead of just returning a 404 and
saying oh i don't know what that is i
net sim actually does respond to it and
we'll at least know it won't be the
actual payload because it's the same
kind of executable every time but it
still does download one so let's say
this drops into maybe like the temp
directory or something like that we
could actually go hunt this down
and say hey the malware actually got a
second stage payload and it actually
goes to this directory and we can take
that as a fact and record that
and there's actually one more thing that
we want to do here we'll go down to our
start menu and we'll do network
connections view network connections and
we want to look at our ethernet adapter
we can double click on this and go to
properties
and we'll go down to internet protocol
version 4
and we are obtaining our ip address
automatically that's okay we can leave
that as the default but we want to go
down and use the following dns server
address
and we want to set this to the dns inet
sim server that we just created which is
the remnux box which is 10.0.0.3
and we'll go ahead and click ok and
we'll click ok and we can exit out of
this
so
at this point if i type in any old
address so ase ase asd.com
it will go to and you know what let's do
that again so it shows it from a fresh
chrome tab just to to really drive the
point home here we open up a fresh
chrome tab and we go to asdasdast.com
and it serves out the default html page
for inet sim the exact same page that we
got from punching in the ip address and
so what this means is that we now have a
functional fake dns server that's going
to respond to any dns request that we
put in here we can put in free t-shirts
dot com and we get inet sim we can put
in fancy lad snacks dot info and we get
inet sim and the idea is that we're
going to be able to get a really good
list of every domain name that malware
calls out to when we detonate it inside
of this network simply because we now
have inet sim running at the remnux ip
address that's super important and it's
a very powerful tool and it will help
you out immensely when we start to do
the network
indicators in this course and now
with no further ado we are now at the
part of this course where we get to
actually detonate malware
inside of our flare vm workstation i'm
excited for it you should be excited for
it let's go to the next video and let's
get this party started
hey everybody if you're joining me from
the last part of this course you should
now have the link to the course
repository and so that's going to be at
github.com husky hacks pmat dash labs
so if you go to that you will be brought
to the course lab repository github page
and after you see this spiffy spiffy
logo here you should see a little bit of
information about the labs themselves
so let's do a quick lab orientation
we're gonna talk a little bit about the
structure of the labs uh where to go to
find different things i do have to point
out please click on this end user
license agreement and please read this
warning carefully uh the long and short
of it is that you're about to partake in
labs that have live malware in them now
the malware that's written for this
course by me has been written to emulate
real-world malware characteristics while
being as safe as possible but this
repository does include real life caught
in the wild malware and you just need to
be very careful when you handle this
malware at all times so please do click
on this right here please click and read
the end user license agreement but also
really the warning just kind of
summarizes that so please just read that
as well
now moving on to the structure of the
labs the main lab repository folder
contains all of the different sections
which all map to the different videos in
the course and they go in sequential
order
and so let's actually scroll up we'll go
into the labs section here and each of
the sections is numbered 0-1 1-1 1-2
generally speaking they're all numbered
in sequential order and you will take
them in the order that they are shown
here
and so what you'll do is you'll go into
0-1 during the section that deals with
handling and safety and the sample for
use in 0-1 is in a zip
password-protected folder inside there
now in some cases there are two samples
maybe more in a single directory so
please just make sure that you're using
the correct one always refer to each
video in the different sections of the
course for which sample that you need to
work on so for example some of them are
used in basic static analysis and used
in basic dynamic analysis so just make
sure that you're always working on the
one that is being referenced in the
video now moving on there are the
challenge binaries in here as well so
the challenge will include the
description of the challenge it will
include the
questions that you need to answer during
the challenge and if you get stuck there
is an answers directory here which has a
readme file in written in markdown that
has the answers to these challenge
questions here at the bottom so if you
get stuck you can go to the answers
section but but do try to make it
through the challenges without viewing
the answers first but if you get stuck
go ahead and check out the answers
section now back out on the main page
here we'll scroll down and in this
section we cover the topics of the
course so go ahead and read those we
have a brief description of the
challenges now every sample is zipped
and password protected and the password
for all of the samples is infected all
lowercase right there uh i also have a
reporting template so for the report
section at the end of the course we'll
go ahead and use that so that's in here
as well and then please do read this
blurb on cosmo to make sure that you
understand uh what's going on with the
cosmo.jpg uh picture in this repository
so you see that i have cosmo.jpg right
here
and there he is his face is quite big um
but yeah go ahead and check that out and
just make sure you understand what's
going on with that
all right and that is the lab repository
so again that's at github.com husky
hacks slash pmat dash labs and this is
going to be every single binary every
single sample every single script piece
of malware that you need for this course
will be in this repository and so to
download it all you need to do is go to
code and download zip do make sure
you're on the main branch here there are
two branches but just make sure you're
on the main one
you'll go to code and download zip and
that should download it to your physical
host and then you can drag and drop this
into your lab environment and then all
of the samples will be available in your
lab environment for you to use all right
and that wraps up the orientation for
the lab so meet me in the next video
alright so we have downloaded the course
repository we have the labs now out on
our desktop and we have cosmo.jpg right
here very important before we proceed to
the next video where we will be
detonating our first malware sample
we're gonna go up here
go to machine
and just so that we're all on the same
page we're gonna take a snapshot
we're going to call this pre
destination
so once we have our name put in as
predetonation we'll hit ok
and this will save the machine state
before we go about detonating our first
piece of malware in this course
and the first piece of malware in this
course is quite a destructive one go
ahead and open up to the lab directory
and we'll go down here to bossfight
wannacry.exe
we open this up
when we open up the 7zip directory we
use a standard password of infected
and we can bring this right out to the
desktop in prep for the next video in
this course
so
once again make sure that you have a
pre-detonation snapshot to revert back
to
go ahead and move wannacry.exe to the
desktop
and again that's found in the labs
directory go to the labs directory 4-1
boss fight wannacry.exe
and meet me in the next video where we
will detonate this piece of malware
listen carefully listen closely we are
about to detonate malware for the first
time
now if you're anything like me
the first time that you detonate malware
even in a test environment your heart
might be beating a little bit you might
have the jitters but that's okay i'm
here to tell you we're gonna get this
over with right now
and while it never may fully go away
this kind of feeling of anxiety when
you're about to do this
the more that you trust in your own
habits and safety
when handling malware the easier it's
going to become
now
i have the pmatlabs directory open to
the wanacry subdirectory and i have
wanacry.7zip right here
now what we're gonna do
is double click on this
and we're going to drag this to our
desktop
and we have a password to enter the
standard password for every single
zipped malware sample in this course is
infected all lower case i n f e c t e d
hit enter
immediately you may notice
that this malware sample is not in
executable file format
and we can double check that by going to
the properties it is just a file
and if we double click on this
windows is going to say how do you want
me to open this
now we can arm
this sample
by adding a dot exe
to the end
when you add a dot exe
consider this to be a live sample
so what we want to do
is we want to right click on this
and we're going to take a nice big deep
breath and we're going to click run as
administrator now what i want to point
out and what's common among malware
samples in general
is that at first it may seem like
nothing is actually happening
there's always going to be more to
malware than meets the eye initially and
that is part of the reason why we need
good snapshots to revert back to because
do you know if wannacry just installed
itself as a persistent binary do you
know if it made a service do you know if
it changed a registry key somewhere now
we start to see some of the actual
symptoms of this infection it looks like
they got cosmo and if we try to open
cosmo here we're gonna get a we cannot
open this because it appears corrupted
and we see some other things here
wannadecrypter.exe
we see the wannacry extension is now on
our files and we see this super scary
background picture that's been unpacked
and it's going to actually change on the
background here in a second but the fact
remains
that at first detonation we may see some
symptoms of a malware infection but we
don't see everything and even
furthermore there might be examples of
malware that nothing happens at all to
the to the human eye
now
it looks like this is pretty obviously
ransomware right we see the background
here and it says oops your files have
been decrypted but let's say we double
clicked on a piece of malware and
nothing happened at all how would we
know what was going on and let's say
that we ran it again do we know that
anything changed from the first time
that we ran it so it's very important
that we have good snapshots to revert
back to and i hope that this illustrates
that point we now have a fully encrypted
hard drive full of files that are
completely useless to us until we fork
over some bitcoin to a particular
address so this is bad of course and if
you see this monday morning when you go
into your office you're probably just
gonna walk right back out the door right
but we are smart analysts and we have
the snapshot to revert back to you see
that i have my predetonation snapshot
here and so what we'll do now that we've
seen our little show here is that we
will exit out of this vm we're gonna
power off the virtual machine
and we can actually check this box that
says restore current snapshot
pre-detonation and when you click this
this will get rid of the current state
and revert it back to the pre-detonation
snapshot and if we start up again
we restore the virtual machine state
and look at this it's like it never even
happened if we get rid of this we can
open up cosmo again and there he is
and it looks like our machine is
completely back to normal and so
i want to underscore the importance of
this because it's incredibly important
for an analyst to be smart and safe when
they're handling their malware like this
but also it aids in the discovery of the
facts related to this malware did it
install itself as a persistent binary
did it install a service has it changed
any registry keys if you run it multiple
times do different things happen these
are all fantastic questions and we need
good snapshots to revert back to if
we're going to answer these so i hope
that that was an enlightening experience
for you we got the first one out of the
way together and don't worry i promise
you that if you follow the instructions
to the t in this course you will not get
infected with malware
now for now
we're going to put wannacry away because
we
don't know how to handle this piece of
malware at this point we don't have a
methodology yet to follow to be able to
extract facts about this binary
so we're going to put it away and we're
going to treat it kind of like a boss
fight we're going to come back to this
at the end of the course and i want you
to soak up as much information along the
way so that when you see this binary
again you can take it down and you can
take it down easily so we'll get rid of
wannacry for now we're gonna start by
learning the methodology of malware
analysis which starts with basic static
analysis so meet me in the next video
and we will get started on the real deep
work involved in malware analysis i'm
excited to do it you should be excited
too so meet me over there
hey everybody it's actually husky from
the future here you might see a few
things on my desktop that are not
there or you haven't set them up in the
environment at this point don't worry
about that
what i wanted to do is record a video
because something actually just happened
to me while i was recording a later
video in this course and it actually
illustrates a really good point about
troubleshooting your own tools so i
wanted to just record this to show you
what i did in this scenario so basically
it goes down like this at a certain
point in the analysis sections i went to
go use a tool and it was this one right
here procmon i double clicked and it
said oh we're searching for procbon we
don't know where it is oh no it looks
like during the installation of flare vm
it looks like a few of the tools at
least one of the tools did not install
properly now what happens when this kind
of thing happens
do we just give up no absolutely not
what we can do is very briefly put our
analyst workstation back on the internet
and download the required tools so that
we can keep rolling on in the course and
this is going to apply to the procmon
example that i'm about to show but truth
be told any time that you run into a
tool that didn't install correctly all
of the tools in flair vm are open source
and available on the internet for free
so all you really need to do is google
the name of the tool and you'll be able
to find it so how do we get our analyst
workstation back on the real internet
we'll go up to machine and we'll click
on settings
and we'll go down to our network section
and remember that we are on our host
only adapter network right here and
we're going to switch this back to nat
network address translation remember we
don't want this when we're actually
detonating malware but for the moment
just to be able to get back on the
internet so that we can get our tools we
can go ahead and select the nat network
and you might need to just restart here
so you'll go ahead and restart all right
and we'll log back in with our password
and we'll go back to the desktop once it
loads up
and we should be okay if we go down here
we notice the little internet access
network icon and so we can test this by
going to
google.com
and there we go we have the actual
google.com now one thing to notice is
that you might have to go into your
network connections here so just go down
to the start menu and do network
connections you can view network
connections and go to the ethernet
adapter
you can click properties
and you can go down to ipv4 and make
sure that both of these are going to
obtain ip address automatically and very
importantly obtain dns server
automatically
remember that during the setup we
actually put in the ip address of our
remnux box as the dns server and that
allowed us to make use of inet sim
but for the real world internet we want
to get that dns server automatically so
if you click both of those and click ok
you should be able to get back to google
all right so how do i find this tool so
i'm going to start by googling the name
procmon and download
and as it turns out that procmon is
actually a program inside of the sys
internal suite which is provided by
microsoft now you can download this
individually but you can also go
download the full sysinternal suite
all right now once we've downloaded the
sysinternal suite we can just drag that
right to the desktop and we can
right-click and go to 7-zip and we can
extract to sys internal suite slash and
that should extract all of the tools in
the sysinternal suite out to a folder on
the desktop
and if we scroll down we see that
procmon and procmon64 are right here and
we can go ahead and double click on that
and run it and so all is right in the
world so that's how to kind of cover the
installation if any of the installation
of the tools goes wrong you can go ahead
and put your analyst workstation back on
the internet download the required tool
and of course what we want to do we want
to reverse this as well so go back to
settings
and we'll go down to network and switch
it from nat back to host only adapter on
number two remember that was the one
that we set up for our analyst network
and click ok
and the last thing that you may need to
do is go into view network connections
so type in network
connections
click on this and we're going to set our
dns server again to be our remnux box so
remember to use the ip address whatever
that is and put that in here so for me
that's
10.0.0.3 or 4. i'm not totally sure but
i'll check after this video
and you can go ahead and click ok on
that and then just for good measure
we're going to go ahead and give
ourselves a reboot
and that's how to cover any tools that
fail to install during the installation
so if that happens at any point in the
course just follow that methodology and
you should be fine
all right and that's just a little bit
on the troubleshooting meet me in the
next video
all right my analysts and training
welcome welcome to the dojo
i will be your instructor for this
portion of the course as well as the
rest of the course and today we're going
to talk about the most important part of
this entire course if you take one thing
away from this course at all it doesn't
have to be the technical side of this it
doesn't have to be how to analyze
malware but i want to drive one thing
home and that is exactly what you see on
the screen right in front of you safety
always not safety first safety always
what you're about to do
is risky by its nature and
that's okay because if we adhere to some
basic principles we're never going to
put our own operating system or our own
data and files at risk
and so
we really want to mitigate a couple of
things here so
the idea is that we're going to have
live malware
in an environment a controlled
environment that we're going to be able
to detonate now the times that you are
most vulnerable are going to be when the
malware is in transit
let's say you find a piece of malware
here's our little bug he's got the legs
he's got the antenna
he's got the other legs
now you have an exe that is a piece of
malware it is known to cause damage to a
system and we want to make sure that we
can get this into an environment where
it's not going to do any harm before it
gets there so the idea is that your
executable is going to have a dot exe
extension now one principle of safe
malware handling is to add an extension
to this
that will
remove the probability that you as the
analyst when you're handling this piece
of malware are going to accidentally
trigger it without you meaning to so
let's talk about a scenario so let's say
that we have our
analyst workstation here
and this is totally fine for malware
detonation so we can put our bugs
and little antenna
and legs maybe he's got some eyes we can
put our bugs in here and we can blow up
our malware and inside of the
environment here it's going to be
totally safe but remember that this is a
virtual machine
inside of your host operating system
so the risk factor goes up a little bit
if you're inside your physical host
transferring
malware from some outside location into
your physical host and then trying to
get it inside the analyst virtual
machine
so we can do a couple things to kind of
mitigate some of the risks here so let's
say that
let's say that our file of interest is a
dot e x e
right which is the file extension in the
windows operating system for executable
and that means if you double click this
or if you use command.exe to run this
the malware is going to run and it's
going to do whatever it was designed to
do be that good or bad
and so one of the ideas is that when you
find your malware source
let's say you find it on this website
that's out here before it even makes it
to your host operating system what
you're going to try to do is handle this
so that the exe extension is defanged or
disarmed by adding another extension
that does not have executable properties
i like to use malz for malwares so i
know what i'm working with but this
could literally be anything the common
malware executable extensions are going
to be things like of course.exe uh some
of the scripted malware.js
we could use something like maybe dll
so while you are studying how to handle
malware properly you're going to start
to realize which ones of these are more
dangerous than the others uh some things
like txt
uh dot md not so dangerous
my point is that before the malware
makes it into your environment what you
want to do is append that file extension
with another file extension that's going
to defang the malware so that by the
time it gets into the host operating
system you're not risking inadvertent
detonation now let's talk about one
other thing that we can do to kind of
mitigate the risks of inadvertent
malware detonation and that's going to
be the way that we handle the malware in
a directory structure we're back in the
analyst workstation what i want you to
do is go to the xero handling and safety
section of the pmat labs and what we're
going to look for is the subdirectory
there called malwarecalc.exe.mals
now i want you to pay attention to
exactly how this file is named now
inside of this directory we have a
couple different things here we have
this 7zip file which is
malware.calc.exe.7zip
we have an
md5sum.txt we have a password.txt and a
sha256sum.txt
now
i'm naming the malware this it is a
standard convention to me there is no
real one standard naming convention on
what to name malware
but whatever makes sense to you you
should pick something and stick with it
so this could be maybe malware is the
classification of malware we don't
necessarily know what this is yet
although it does say calc.exe
so we can make an educated inference but
until we know exactly what we're dealing
with maybe we just call it malware and
then when we get a little bit more
information let's say it's a trojan we
could call that trojan and then
separated with a dot if this is the
first time that you are
researching this particular specimen it
might not have a name yet you might get
to name it that's pretty cool uh and
then what i like to do is keep the file
extension right next to the name and so
you know because you know just from name
of a malware specimen you don't know if
it's a powershell file
or an executable or dll
what i like to do is make sure that the
original file extension is here in the
the file name somewhere and then dot
7zip
all right so we have our malware
specimen inside of this 7-zip file what
we can do is bring this out to the
desktop
and we can open this up and inside we
will have our malware specimen itself
again notice that there is a naming
convention here it's the same naming
convention of the zipped up directory
and it is just dot mal's to defang the
piece of malware so that you cannot
inadvertently run this without meaning
to
now
the next very important part here is
that if we try to copy this out to the
desktop we're going to need to enter a
password it is the standard convention
in the industry to password protect and
encrypt all malware specimens and the
idea is that the password is not to keep
people out the password is to make sure
that the analyst that is about to copy
this to their workstation wherever that
ends up being knows very well what
they're getting themselves into and so
the standard password for malware is
infected all lowercase i-n-f-e-c-t-e-d
and if you hit enter it copies out to
the desktop
and the final part here is that we want
to arm our malware
by removing that erroneous extension
hitting enter it says if you change the
file extension it will become unusable
which is ironic because that's the
opposite of what we're doing are you
sure you want to change it yes
and then after we have double checked
our system configurations and made sure
that we cannot route to our physical
host and all of the other safety
measures are in place we have handled
our malware from source to sync making
sure that we don't risk inadvertent
infection of our host system and that's
when we get to
double-click the malware and run
and this one spawns calc like it says or
does it
well for this one yes it does it just
spawns calc but you know later in the
course maybe there are others that kind
of look like they're just spawning calc
but they maybe do some other kind of
things okay so that was the primer on
safe malware handling these procedures
are to be practiced at all times during
this course so just to recap remember
when you source malware make sure that
it has a defanged or or d armed
extension appended to it
make sure to encrypt in a password
protected zip directory all specimens
and make sure that that specimen is not
brought out of the directory until it is
in a safe location for detonation and if
you follow those instructions you should
be safe from inadvertent infection
and we're going to move on to the next
part of this which is talking about the
sourcing of malware and how to find
malware
from reputable sources so meet me in the
next video and we will talk about that
hello my analysts if you join me from
the last video we talked about safe
malware handling and how to delay the
risks of inadvertent infection on your
host system but that does beg the
question
where do i find malware in the first
place and the answer it may shock you
because when i started doing research
into this i thought malware was very
hard to find and i would have to plumb
the depths of the dark web to be able to
find samples and i'm here to tell you
that's not the case uh it's going to
maybe shock you how easy it is to find
malware out in the open and more
importantly find safe reputable
repositories where you can go to collect
these samples without risking your host
system or your data
um what i want to drive home here is
that you do not have to go to sketchy
websites in the dark web to find these
samples uh they're out there at
reputable websites how about github
github's a pretty reputable website so
let me introduce you to the three main
repositories and one's really a
compilation of other repositories that i
like to use when i'm sourcing malware
now the first one is the zoo which is
curated by yitzif
not quite sure if that's how you
pronounce that but that's okay this is
the zoo a live malware repository uh
this is on github so the
site itself is reputable and safe to
visit uh now this is fill to the brim
with live binaries and and source code
that you can analyze as well and i do
like that a lot because you may start
with analyzing just the binaries here
and there's plenty to choose from i do
believe wannacry is in here somewhere uh
but once you get a handle for kind of
the the basics of malware analysis maybe
you start to get interested in the
source code to understand how these
things are built and constructed and so
the zoo has both of those
now you can go out to the main page here
and there's actually a
section on how to get started installing
this
but suffice it to say you can
effectively just download the zip file
right here bring that onto your analyst
workstation and you will have more
malware to analyze than you know what to
do with
so that is the zoo the second place that
i want to bring up is the vx underground
malware source code repository it is
once again on github now this one's very
interesting because vx underground likes
to source malware from various locations
i do not recommend going to their main
website what i do recommend is going to
their github repository and looking
through the different samples that they
have here now you never quite know what
you're going to find here i want to draw
your attention to the leaks directory
here and if you go you see that there
was something uploaded 17 hours ago in
the other and look at that that's the
babuk ransomware that's been as at the
time of recording this video has been a
rash of ransomware attacks uh with that
ransomware as the uh particular specimen
so i don't quite know where vx
underground is getting their specimens
from and i'm okay with not knowing
because they put them on the github repo
again you can do download zip and bring
that onto your analyst workstation and
there are plenty of architectures here
to choose from as well lots of this is
windows
but there are python samples too and mac
os
all of these are in zip directories
again trying to adhere to best practices
of malware handling
and so the last repository that i want
to bring up which is really a
compilation of multiple repositories is
at zeltzer.com if you don't know who
lenny zeltzer is he is a titan of
industry he's one of my heroes he does a
ton in the space of malware reverse
engineering analysis he's been around
for a while and he did teach this
professionally as well so he he knows
what he's doing and he has put together
a bunch of resources for malware
researchers and analysts and these are
not specifically all databases of
malware there certainly are many of them
but there are other things that we'll
actually get into later in this course
like any dot run and so there are lots
of different things to play around with
here but remember the idea is that we
don't want to be going to the dark web
we don't want to be going to sketchy
forums we don't want to be sourcing
these uh unethically or from places that
you know you risk your your physical
operating system to procure these
samples they're out here in the open on
on the clearweb and they are available
for you to download and play around with
so
for this course however the only
required samples are going to be inside
of the pmat labs
directory here and you see this says
pmatlabs main but yours may just say
pmat labs every required binary for this
course is going to be inside of that
directory provided you've downloaded it
from the github repository and so that
will be all you need for this course
specifically but let's say that you get
through this course and you're hungry
for more and you're saying where can i
go to find more of this stuff well i
wanted to bring that up just to show you
that you don't have to go to these
sketchy websites to find this stuff you
can go right here in the comfort of your
own github repository pull it down and
you can reverse engineer and analyze to
your heart's content
all right and that is the spiel about
safe malware sourcing and so let's move
it on with our first section of analysis
in this course which will be basic
static analysis so meet me in that video
and we'll get going
all right my friends here we go
and so we begin the first phase of
malware analysis
we begin with basic static analysis of
our malware samples now if we break down
the terminology here basic static is
going to mean we have a limited triage
approach to the tools and techniques
that we're using and static meaning that
we are not running the binary so this is
going to be a a i want you to think of
this as like a first pass without
actually executing or detonating the
malware
and we're going to pick up
maybe things that will give us key
insights to what the malware could be
doing now in this phase it's very early
in the analysis
and we really will not be able to draw
any definitive conclusions without
running the binary but i want to liken
this to let's say that you have an alien
that you're performing an autopsy on
and if you just do basic static that's
like looking at the alien without
actually slicing into it and saying i
know exactly what this alien does and
how it functions you can't really say
that right but basic static would be a
little bit like if you looked at the
alien's antenna and said all right i
wonder what that's for i've noticed that
this alien has some antennae on it and
maybe that's used to transmit some kind
of information and so you can begin to
build out these hypotheses about what
the malware could be doing nothing
definitive but we might be able to find
a few key facts here
what i want you to do is open up to the
pmat labs in the basic static analysis
section and we're going to go to the
malware.unknown.exe.malsdirectory
now when you open this up you will have
the 7zip and the password which is of
course infected and you also have a
readme here now remember that you should
normally have the md5sum and the sha256
hash right here but we don't have that
the readme says analyst we do not have
the file hashes for this sample yet
please pull the hashes and submit from
the re team
all right so so begins our first section
here and this is our basic static
analysis the first thing that we want to
do is pull the file hashes of this
sample now we open up and we punch in
our standard infected password and we
have the malwareunknown.exe.mals
sample right here
now we don't actually have to arm this
sample yet if we're in basic static
analysis we don't have to make this
executable because we will not be
running this binary
now the first thing we want to do is
collect one of the two file hashes that
i like to collect which is the sha-256
sum and so you can type in sha-25 and
hit tab autocomplete on flair it should
get you to the executable
and then following that we will give the
name of the sample which is
malware.unknown.exe.mouse
and we hit enter
and we'll take this and we will copy
this down into our notes
and we can put this into a text file for
now but what we will want to do is copy
that out to our physical notes that we
have out on our host operating system
if we have the first file hash
we will then pull the md5 sum
and same thing malware.unknown.exe.mals
and same deal we can take this and we
can copy this
out excellent so we now have two pieces
of information that we can use to
fingerprint this sample the sha-256 sum
and the md5 sum and this is going to be
important for the next section so meet
me in the next video where we talk about
submitting these to virus databases and
seeing if this sample has been seen in
the wild before
all right picking up from where we left
off what i want you to do is on your
physical host so outside of the analyst
virtual machine back out on your
physical host i'd like you to
open up a chrome browser or a browser of
your choice and what we want to do is go
to virustotal.com
now virustotal.com is a gigantic
repository of lots of different
information about malware samples
it has
file hashes it has files themselves it
even has urls and uris and what you can
do is submit information to virustotal
and ask it hey have you seen this before
is this a malware sample that has been
seen in the wild somewhere
and so what we can do is copy out either
one or both of the file signature hashes
that we have received and so we go over
to the search
function right here and we can control v
and copy this in and hit
enter
and so it will search and what is going
to happen is it will say no matches
found now at the time of recording this
these are fresh malware samples that i
have written myself and there won't be
any virus total hits but as time goes on
i would anticipate that this starts to
turn up that these are malicious samples
and the reason is because as more people
submit this file hash or the samples
themselves to the file
part of virustotal
virustotal is going to scan these files
and say hey i am identifying certain
functions that i think are malicious so
what i also want to do is show you maybe
what this would look like if it picked
up something that was actually malicious
so i'm going to use our tried and true
wannacry sample here and so what i'm
going to do is do the exact same thing
md5 sum but instead of the malware
unknown sample i'm going to type in
wannacry and we'll take this and we will
control c copy this out we'll go back
over to virustotal and in the search bar
we'll search for this one and wouldn't
you know it
and which is not very surprising 63 out
of 68 malware vendors found that this is
a malicious file and a lot of them will
actually tell you exactly what that is
so
that's a pretty interesting thing that
virustotal knows this file so well that
it can pin down exactly what specimen it
is but that just goes to the power of
these kind of collective databases of
malware
so that is the second part of our basic
static analysis we will submit the file
hash to virustotal and see if this
sample has been seen in the past all the
while we are annotating these pieces of
information we're taking the md5 sum and
the sha-256 hash and putting that into
our notes for a report later down the
line and so that's it that's submitting
to virustotal and we're going to keep it
rolling with the next part of our static
analysis
all right for our next section of basic
static analysis what we are going to
talk about are
strings
now what is a string
in the computer
science and programming context a string
is very very simply an array
of
characters
right so
while you and i as humans understand
something like a sentence that might say
hello
world
a computer doesn't really get what this
is it doesn't have an idea of what a
word is it doesn't really have an idea
of what a phrase is but it does know
each of these individual characters
and so
strings are very useful to humans but
not so useful to computers but humans
need strings in programs to do lots of
different things if you think about
maybe a programmer is trying to get a
program to
talk to https colon slash
dot com
that
is a string
a computer is not really going to know
what that is but it will treat it as an
array of individual characters so it
will say this is the zeroth part of this
array this is the first this is the
second the third the fourth
the fifth would be the space right here
six seven eight nine ten and then
there's actually one final part right
here which is a null byte
which means that it is ending the string
and saying this is the end of the string
don't go any further than this and so
that would be the 11th
element of the array
so that's a little bit of background
about what a string is to a computer but
what does it mean to a malware analyst
well like i just said
if the
malware author wants to
program the malware to reach out to
https
colon slash slash and then this could be
any malicious domain
dot com
slash and this could be evil
dot e x e
the malware author needs to code this
into the program at some point so that
the computer can assemble this array of
characters into a string and make some
kind of web request to it
and this comes in the form of a string
that is embedded right into the exe i
want you to think of an exe as kind of
like this box right
and so when the box is assembled or
compiled
there are lots of different bytes that
are inside of this box
and one of those bytes might be http
colon slash
domain
dot com
and so if you can reach inside of this
binary and take a look at the strings
inside it might inform what the binary
is doing but you can't really draw any
absolute conclusions out of this the
best that you can get really out of
looking at the strings is a brief
glimpse into what might be used as a
sentence or a phrase or a word or maybe
a url inside of the binary
now let's take a look at how we can
extract these strings out of the binary
now as i previously mentioned when the
binary is assembled these strings are
kind of just sitting inside of the
binary and can be read by looking at the
bytes of the binary and we don't have to
run the binary to do this and so we can
extract the strings out during the
static analysis phase there is a program
called strings that will do that it'll
look at the binary and pull out all of
the strings the arrays of characters and
present them to us
but there's actually another program
that i like to use a little bit more
and it's called floss so thanks strings
floss it's like a better version of
strings
which is made by the fireeye team that
is going to do just that it will pull
the strings out of the binary but it
will also try to decode and de-obfuscate
any strings that it finds uh with a
little bit of programmatic magic on the
back end and then present us the strings
at the bottom of the output of this
program so that we can more easily get
an idea of what the strings are inside
of this malware and what we might be
dealing with so again we will do our
malware.unknown.exe.mals and we'll use
the program floss and hit enter and so
depending on the size of the binary this
may take a little while or it may be
pretty much instant
and so this binary happens to be pretty
small
so what you see here is floss takes a
look at the bytes inside of the binary
and it pulls out any array of characters
that are greater than length four
now it will treat that as a string and
say hey i found an array of characters
that is larger than 4 bytes and here it
is and it's terminated with a null byte
that might not be great always now we
can see some of these strings are
completely useless uh this doesn't mean
anything right this is just a random
array of bytes inside of the binary that
may be serving some kind of programmatic
function but it doesn't really tell us a
lot about the words or the phrases or
the urls that are used inside so the
idea is that not all of these are going
to be useful but every now and then
you're going to come across one that's
incredibly telling
as you can see here i didn't really do a
lot of modification when i was writing
this malware so you can actually see the
exact
path of the malware in my repository
from the original compilation my pmat
maldev repo right here is where i was
writing all of this malware now you may
get very lucky and see something like
that but you can just kind of keep
scrolling and after you get through some
of these other
less useful strings you start to see
some other things in here and this is
actually kind of
it ties into another part of the static
analysis phase that i'm going to cover
later but you start to see these things
like internet open url w internet open
url
wininet.dll to a trained malware analyst
some of these are jumping out
immediately url downloads to file w now
to someone who's not really familiar
with what this could be what could these
things be well maybe they are the names
of functions or maybe they're the names
of uh things that the binary is doing
and as we keep scrolling we see a few
more of these and then eventually we get
to the very bottom of floss where floss
is going to pull out the static unicode
strings and these sometimes are some of
the most telling of all of the things
that that floss will pull out and so we
see things like cmd.exe and then cmd
looks like it's running some kind of
command here and we see things like http
colon slash ssl and then maybe like a a
domain name here help desk bros.local
favicon.ico we see something in the
users public documents directory right
here now
what we should be careful here is that
these may be thrown into the binary
intentionally to trick us or they could
be actual pieces of the binaries
functionality we don't know at this
point but certainly all of this right
here is very interesting
and so what we want to do is take note
of this and maybe like think of it like
putting a pin in this right here so
we're going to take like a little a
little pin and we're gonna put it right
in that cmd.exe and say i don't know
what the string is doing but now that i
know that it's in there i'm gonna take a
look at the things that are using this
string and maybe some of the stuff that
happens around it and so we see some
very interesting information here but
again at this stage in the analysis
there's just not enough to go on we
really need to start to go deeper to
figure out what these strings are doing
and why they're in here but in any case
extracting the strings out of a binary
can be a very informative first step at
identifying where to go next so it's
very important to do so that is string
extraction and we're going to be moving
on to our next section of the static
analysis so meet me in that video all
right analysts we have looked at the
strings that are setting inside of the
binary we have used a tool called floss
in order to extract them and in order to
look at the structure of the binary and
maybe find some more information about
when it was compiled and what kinds of
functions it might be using we're going
to go to this flare directory right here
which is a shortcut to the programs
directory and we're going to scroll all
the way down so go all the way from the
top and find this utilities subdirectory
right here
we open up the utility subdirectory and
we're going to scroll a little bit of
the way down and we find these pe
programs right here we want to open up
pe view
so double click and open up pe view
and when this opens up it will ask you
what do you want to load into it and it
will try to find an executable as a
default now we don't have our malware
sample in executable format so we can go
to all files and what we want to do is
find our malware.unknown.exe.mouse
double click that and load it in
now what i want to point out is that
this right here in the center is is kind
of a very interesting way to think about
what a pe looks like now you think like
with a powershell script or maybe a text
file you kind of know what it looks like
when you open it up right
you see some characters and maybe some
sentences and maybe some some if it's
powershell maybe you see some functions
in there but can you honestly say
what does a portable executable look
like
like really when you think about it what
does it really look like well
when you open it up in something like pe
view you get an idea of what these
things are actually made of and what it
comes down to is that a portable
executable is really nothing more than a
gigantic array of bytes and you see
these bytes are represented here in
hexadecimal format
and you'll see the raw data are the
hexadecimal bytes in the center you see
the p file column right here represents
the offset of these bytes so where in
relation to the beginning of the program
did these bytes exist and all the way
over here on the right side you'll see
the value column
it's a character representation of what
these bytes look like sometimes they are
actual characters and sometimes they're
not able to be represented and that's
when you see these dots right here but
truth be told all of these bytes have
some kind of purpose inside of the
binary now every portable executable
follows the same exact format
it starts with this byte right here
which tells the file system and the
operating system what kind of file it is
this mz right here is a signature
giveaway that this is an a a windows
portable executable and this is actually
someone's initials i actually learned
that recently and so following this
magic byte right here that tells us that
this is an executable a little ways down
from this we can actually pick out a
sentence right here this program cannot
be run in dos mode this is the dos
header of the portable executable now
i'm not going to go through the whole
anatomy of a pe
that's kind of outside of the scope of
this course but what i want to get
across is that all of these programs
follow a very very particular format
and so something like pe view was
constructed to tear apart this format
and look at all of the different
sections and we can extract a lot of
insight as to what this executable might
be doing
from looking at these sections
now one of the first things that i like
to look at is to go right down here to
the image file header which is under the
image nt headers section
and so one set of bytes inside of the
portable executable will have the time
date stamp the time date stamp is a time
of compilation for this particular
executable now the time date stamp may
in fact be a reliable point of
information but it might not there are
some circumstances in which this time
date stamp is going to be the same no
matter when this executable was actually
compiled now for this one i did happen
to compile this today you see the
calendar down here is 9 4 20 21 and you
can see up here that this was compiled
on 9 4 20 21 so the date time stamp of
this executable is accurate but let's
say what if this said 1992 some date in
1992 that's pretty old right it's not
necessary that that particular
executable was compiled back then
but that might be an indicator of some
other kind of information the borland
delphi compiler so malware written in
delphi if it was compiled with the
borland delphi compiler it will always
have a timestamp of 1992 a date in 1992
and so this can be a reliable piece of
information but you you really need to
look at it carefully and critically to
determine if that was actually when it
was compiled so let's move on from the
date timestamp down to the image section
header of the dot text section so the
dot text section is one of the about
five locations in the binary that has
information that can be read into the
binary at runtime so one thing that i
like to look at here are the virtual
size and the size of the raw data
you can compare these values these are
going to be written in hexadecimal and
so what you can do is break out your
trusty programming calculator
and you want to take a look at the
virtual size and the size of the raw
data for both of these fields
now if we select the hex section of our
programming calculator and we type in
the size of the raw data 1600
in decimal that means that that is about
5
632 bytes
now we take that number and we compare
it to the virtual size here one five a
one
so let's go ahead and go back to our
programming calculator and one five a
one
and it looks like that is five thousand
five hundred and thirty seven now if
these two values are similar we can
ascertain that the size of the raw data
of the binary is roughly the same as the
virtual size you can think of the
virtual size like the amount of data on
disk when the binary is run
now let's say that this was much much
higher than the size of the raw data so
the actual raw bytes inside of the
binary are actually much much lower than
what it is when it's run
and what we could maybe surmise from
that is that there is more to this
binary than is initially available to us
and we can maybe think that that's
what's known as a packed binary
so i do like to look at these take a
note of these and make sure that these
values are relatively close if they're
not we may be dealing with a packed
binary and a little bit later in the
course i'm going to show you exactly
what that looks like now i want to look
at one final piece in pe view
and if we go to the section of the r
data and look at the import address
table this might be one of the most
important parts that we can see inside
of pe view
now to really understand why the import
address table or iat is so important we
need to look at something
called the win 32 or really now just the
windows
api
now to explain the windows api i think
i'm going to break this into its own
video because it's a very interesting
topic but it can be a lot at first
glance so i want to make sure that we
break it down so meet me in the next
video we'll briefly cover what the
windows api is and then we'll go back to
why the import address table is so
important for this phase of malware
analysis so meet me in the next video
all right now we're back and we're
talking about the windows api now api
stands for application
programming
interface
now i want you to think of the windows
api like this
way back in the day when the very very
smart people who designed the windows
operating system were working on it
they said hey
we work on the operating system all the
way down here which is a very low
kind of code to be working on now down
at the heart of the operating system
you're really dealing with things like
zeros ones and instructions like jump
and xor
and
lots of very very low things like that
right now as the operating system
developed
certain features of the operating system
were developed as well and so the
programmers decided hey instead of
requiring people to be working all the
way down here at the very very gritty
low operating system level why don't we
expose
these functions of the operating system
so that anybody who wants to design a
program and write a program in something
like c or c plus plus can make use of
these functions instead of tapping into
the the very very low code of the
operating system and so what you can
think of these functions
is
easier to work with
versions of these very very low level
programs that are running inside the
operating system
so the windows api
can do things like hey if you want to
download
from url
you can use this api and in your c or c
plus program
instead of writing a whole bunch of
low-level code you can just say download
from url
and then you would define that in your
program and so
as part of the windows operating system
we now have this application programming
interface called download url
and so if we want to use that in our
program we need to supply it a few
things we need to say which url to go to
and which file to download
and where do we want our out file
and what will that file be called
and so microsoft put together
documentation that says hey if you want
to use this program inside of your own
program you just need to supply a very
specific defined pattern of information
and thus the windows api was born
now programmers all over the world can
make use of all of these functions all
they have to do is import them from the
operating system now is the windows api
bad
no no it is not
many different programmers from from
many different walks of life are able to
use the windows api for all kinds of
programs
but that means that malware authors can
use it too
now if we look at the import address
table we start to get a feel for what
kind of api calls this portable
executable is making and so right off
the bat
to the untrained eye none of this might
look really that interesting but there
are a few things that jump out to me
so
when you see something like shell
execute w if you don't know what that is
maybe all you need to do is open up the
documentation for it so we go right over
here to
old googles and we're going to say the
windows api shall execute
now
microsoft has documentation for each of
these functions
so shell execute a performs an operation
on a specified file
so this is an example of one of the api
calls that a program can make you can
tap right into the operating system and
call this and it has like a built-in
function to allow you to do some kind of
thing so that is definitely something of
interest again we don't have enough to
say that this is definitively evil at
this point but it is a very big
indicator
and if we keep looking we're going to
see other things that might be
indicators as well how about this one
url downloads a file that was kind of
the example that i was giving when i was
explaining the windows 32 api well here
is the actual api call again if you
don't know what this is go over to the
googles and we're gonna do url
download to file
downloads bits from the internet and
saves them to a file now that can be
pretty telling but a lot of different
programs might use that kind of api call
uh maybe spotify uses that to download
playlists uh maybe your bank application
uses that to
sync your information to your accounts
but if we already know and anticipate
that this file has malicious functions
this is a pretty big indicator that this
malware might be trying to download some
kind of second stage executable
so again you can look at the different
parameters here of how this function is
invoked or called and all it really
requires is a url to actually download
from the file name
and it will write that file to the file
system somewhere
so this is the import address table this
can be very telling about what a piece
of malware is doing at any given point
but we don't know if these programs are
even invoked yet because we have not run
the binary
and that wraps up looking at pe view to
identify a few of the characteristics of
the import address table the compile
time and some of the different section
headers and so we are going to move on
with our static analysis hello my
friends so we're back it is about a
month a little over a month since pmat
released
and one of the most common pieces of
student feedback was that hey during the
import address table and windows api
analysis sections
you've underscored the importance of
analyzing apis to identify malicious use
but i'm confused at which ones i should
be scrutinizing because there are so
many and i'm not sure which ones can be
used maliciously so i think this is one
of the cases where when you ask the
universe for something it sometimes
provides it because a few weeks after
the course dropped a researcher by the
name of mrdocs on twitter which you can
go find their their twitter right there
they released this which is mal api dot
io this is a phenomenal resource and it
just fits the needs so well of what that
piece of feedback was looking for now
you won't be able to get to this in the
lab of course you're going to need an
internet connection for this so on your
physical host you can go to mal api dot
io and so what i liken this to is if you
took something like gtfo bins and
something like the miter attack
framework and kind of put them together
this is a little bit like that it's
specifically for the purpose of
cataloging windows apis that can be used
maliciously and identifying samples of
malware that those apis are used
maliciously in
and so it's just amazing because mr
doc's put together this this set of
columns that are going to identify each
of the apis by usage by ttp uh injection
evasion spying internet usage
anti-debugging
and so what you can do is you can go and
click on each of these apis as you see
fit so let's uh go ahead and find one of
the most uh you know infamous api usages
which is create remote thread so when
you click on a particular api usage
you'll get the name of course you'll get
a description uh you'll find the library
that the api is loaded in from so this
one happens to be from kernel 32
and so associated attacks is again a
little bit like the miter attack
framework where we are classifying in an
abstracted way how these apis are used
maliciously and then of course you're
going to get the documentation so the
actual msdn so you can go ahead and open
that up as well and you can go see the
exact parameters that are passed in to
this api now what's interesting is that
in some of these api entries you will
get a malware sample of a piece of
malware that actually uses this api now
in this case this one is linking to the
vx underground github page and you can
see that the cbot.7zip sample right here
is going to use this create remote
thread so if you want an example of a
piece of malware that's using the api in
some of the api entries you'll be able
to find that there
so the other cool part of this is that
mr docs has made this kind of like a
community contribution effort so that
you can actually go and contribute to
this let's say during your research you
identify a particular malware sample
that's using an api in a malicious way
you go to malapi.io you take a look
around you say hey it doesn't look like
that api is cataloged here well you can
go right up here to contribute and you
can fill out the contribution guide and
mr docs will add this to the api catalog
so fantastic stuff there
the last interesting feature that i want
to point out here is that we have again
similar to something like the miter
attack framework matrices we have the
mapping mode here let's say that you're
performing research on a particular
specimen and given that specimen you've
identified a few api usages let's say
the malware starts by enumerating all
the processes and calls that api to do
so then it creates a process in a
suspended state with a create process a
api call and then it creates a remote
thread and injects right into it and
then let's say the malware invokes the
sleep api to put itself in a sleep state
and then it will open a request to a url
and it will download a file and write it
to disk and so you can select each of
these apis to highlight them on the
table and then what you can do is hit
export table and this will export a png
of this table that you can then take a
screenshot of and include in your report
as a mapped out set of the apis that the
malware is using so very good for report
writing
so that is malapi.io uh go ahead and
send mr doc some love please follow them
they're putting out fantastic research
and check out mao api.io and that's it
for this video thank you and let's move
on to the next section
to pack or not to pack that is the
question
at least if you're a malware author that
is the question now
when we talk about packed malware what
are we really talking about here
basically packing you can think of as
kind of like a compression or encryption
mechanism to make a piece of malware
look different than its original source
so you can think of this it's a lot like
if you put a bunch of files into a zip
file for example
you'll throw it into a directory and a
computer program will look at the
directory and say okay for all of the
strings of characters that look like
this i'll just crunch them down and
replace them with something like this
and that's basically how compression
works and that's also kind of how
packing malware works it's basically
just a compression of an already
existing piece of malware so as always
let's draw it out let's say we have
mouse.exe and this is a very well-known
piece of malware and it's been going
around for a while now well let's say
that our malicious author takes a
packing program and in this case we're
going to use a packing program called u
p x which is a very popular packing
program and upx is going to take this
piece of malware mals.exe
and it's going to blow it up like this
and it's going to say all right this is
all of the data that's actually inside
the malware all right awesome
what upx is going to do is put a little
program in here
called a packer stub and sometimes this
is called a compression stub or a coater
stub
and what it's going to do
is say all right the compression stub
is going to take all of the code that's
located below this point in the program
and it's going to crunch it down
and so when this program is compressed
like this the resulting program looks a
lot smaller than this right
it's really now got three sections it's
got the original portable executable
header like this and it's got the
compression stub and then it's got a
tiny tiny little piece of code right
here
and so at runtime this stub will take a
look at all the code inside of this part
of the program and say all right time to
go to work it's going to take all of the
code that's inside of that section and
then expand it to be the original size
and it's going to do that at run time
now why might somebody want to do
something like this well if you think
about antivirus
let's say antivirus is on the lookout
for things like this this original piece
of malware that we have over here
if antivirus knows the signatures of
this original piece of malware it's
going to know exactly what it looks like
but it might not know when antivirus you
know shines its big spotlight
right here
on this tiny little piece of malware
that's got the stub in it
it might say oh you know what that
doesn't look like any signature that i
know of i think it's totally fine
and after antivirus takes a look at it
when the program then inflates and
becomes the full-sized malware program
mouse.exe
the antivirus is not going to know how
to handle it
so that is effectively what compression
and packing malware looks like and you
can really think of it like it's just a
way to make an existing piece of malware
look different on disk to antivirus and
other kind of security products now to
illustrate this point i have made two
exact identical pieces of malware inside
of the
basic static analysis directory go to
the malware packedandnotpact.exe
directory and open this up it's got our
usual password md5 and sha256 and go
ahead and open up the subdirectory in
here and you can copy both of these out
to the desktop again we have our
standard password of infected
all right now we have malware packed and
malware not packed right here and we're
going to go back to our program pe view
so remember go to the flare directory on
the desktop and go to utilities and
we're going to scroll down and open up
pe view
and again it will ask us
for a program let's go to all files and
let's start with the not packed malware
now this should look pretty familiar
because we just did this for another
piece of malware and we've got the full
program here and actually this time it's
pretty big by the looks of it and we can
see that we can read a bunch of these
strings we can see
we might not exactly know what they're
doing but they are human readable at
this point use http keepalive feature
print version number and exit stuff like
that
so all of these uh strings in here are
readable by us and we can see that the
the layout the portable executable
structure of this binary looks pretty
much the same as the one that we saw
when we did the analysis the first time
so we have our section headers which has
all of the strings that are located for
the binary in the text section we have
the resource section which has other
strings that may be in the binary
we've got the data and the uh our data
and we've also got the import address
table here and as you can see even
though this is a pretty simple binary
the import address table is full of all
of these api calls that this binary
might be using and where they are
imported from so we see that
kernel32.dll
is
imported
to make use of all of these api calls
and now we're not so much worried about
what's going on in here remember this is
just a very brief example but remember
that this is an unpacked piece of
malware it's very easy to decipher
what's going on because the import
address table is full of lots of
different things and if we look back at
the malware itself there are human
readable strings in here
that can maybe tell us what's going on
so let's close out of that and let's
open pe view again and this time we're
going to look at the packed sample so
we're going to select instead of the
notpac.exe we're going to select packed
and we might not see much yet but right
off the bat there are a couple
differences here and we see some things
like section upx right here and so upx
is the name of the packer program that
was used to pack this particular piece
of malware and so we see that all over
the place really it says upx0 upx one
two of the sections are named after that
now something very interesting here is
that we still have an import address
table but look how small it is now
remember i told you that packed and not
packed are identical copies one is using
a packer program
so when we look at the import address
table and it ends up being this tiny
tiny little thing
even the simplest of windows executable
programs would have more imported api
calls than what we see right here but we
see a couple that are very very telling
get proc address and load library a are
two api calls that are used to identify
other imports at runtime so instead of
something like the unpacked version
which has all of the imports listed out
in the iat
this packed program has to actually go
find them from the other dlls that it
loads in so it doesn't know where those
api calls are directly but the existence
of get proc address and load library a
say to me hey i don't have these address
imports in my table right now i've got
to go find them and so what's happening
here is that when the packed piece of
malware decompresses or inflates back to
its original size get proc address and
load library a are invoked to be able to
find those other api calls and that's
why they're not listed in here let's say
this program reaches out to the internet
and downloads a file remember there was
the download file from url api
well that may very well be a function of
this malware but we won't know that just
by looking at the iat because it's
packed and get proc address and load
library a need to be invoked at runtime
to be able to find that that api to use
now one final thing that i like to look
at with packed malware is something i
actually pointed out in the first
section when we looked at the iat of the
first piece of malware and what ends up
happening is that the size of the raw
data and the virtual size now have a
significant difference if you crunch the
numbers on what c00 is in hex it's a
certain amount of bytes it's not very
high but it is you know a non-zero
number but look at the size of the raw
data the size of the raw data is
actually completely zero
and so if the virtual size is non-zero
and the size of the raw data is zero we
know that we're dealing with a packed
piece of malware because the size of the
raw data is not represented in a numeric
form but the virtual size is and that is
because the raw data doesn't exist yet
it needs to be initialized after the
binary inflates from its packed state
so that is the wrap up on packed and not
packed malware it can be very
interesting to look at the differences
here but know that a piece of packed
malware is really not going to tell you
much about it until it actually runs and
so that segs into our next section where
we need to start thinking about basic
dynamic analysis in which we actually
run the binaries to be able to know what
they do and just for the curious if we
arm these binaries by removing the dot
mal's extension and setting them back to
exe and we run both of them well looks
like they're just calc.exe again
all right my analysts now for this next
one we're going to go back to our
original malware sample that we were
working with so
malware.unknown.exe.mouse
now what i'm about to show you is a tool
that might be one of my favorites to use
during the initial basic static analysis
phase now as it usually goes in cyber
security when people started developing
out their methodologies for doing static
analysis of malware
people started iterating on these tools
and making better versions of the same
tools so if you think that in the static
analysis phase we've looked at the
strings inside the binary we looked at
the iat we looked at some of the the
headers inside of the binary and we
looked at some of the bytes inside that
had key pieces of information now we
used a couple different tools to do that
but eventually people thought why don't
we just make a tool that does a lot of
those different things and so there are
a few of those but one of my favorite is
pe studio
so go ahead and go to the flare
directory on the desktop and we're going
to scroll down to the utilities section
again
and yet again we will scroll down until
we find the slew of pe tools and we're
going to open up this one right here pe
studio
now when pe studio opens up you can
either drag and drop a file into the the
window to analyze it or you can go to
open file here
and we'll go to the desktop and we'll
select malware.unknown.exe.mals
now pe studio does a bunch of things
automatically and why it's one of my
favorite tools is because it makes the
early stages of static analysis very
very simple and straightforward
so let's look at some of the information
on the screen right now right off the
bat we already have three of our file
hashes that we can work with we've got
the md5 we've got the sha-256 which are
the two that we've been using in this
course and we even have the sha-1 right
here
now if you are on a system that is
connected to the internet which again i
don't recommend but if you are you can
actually click on these file hashes and
if you see the link right there it'll
send it to virustotal to check that file
hash for you so that actually takes care
of the second step
now alternatively if you're on a lab
system that does not have an internet
connection the way that we've set our
lab box up to you can of course copy out
this file hash by copying the values and
go to virustotal and submit them
it also has both the hexadecimal
representation and the text
representation of the first bytes of the
file now this can tell us if it's a
portable executable by this first magic
byte right here we see the mz so we know
that this is a windows portable
executable it's got the total size and
bytes and it even has the architecture
and we're working in a 32-bit
architecture with this portable
executable now there are so many other
sections here that we can go into to
take a look at other kinds of things pe
studio has kind of an additional layer
of analysis that it likes to put on top
of
all of the other kind of basic
information about a portable executable
and so one of those layers of
information is the indicators pe studio
has as part of the program a bunch of
information about certain strings or
patterns that it sees in a portable
executable and if those tend to be
malicious or not and you see that we
have the indicators here we go by level
from most severe to least severe
and it picks up a couple of things right
off the bat the file imports symbols the
file references a url pattern and here
we see that we have that url that we saw
earlier in the strings
as i mentioned earlier in the course
there are certain libraries that are not
necessarily evil right out the gate but
they do
imply that there may be some kind of
malicious intention behind them
now once we get an idea of some of these
indicators we can go into the different
sections and take a look at the the
specifics of this binary and we can look
at things like the libraries now these
are all of the dlls that the portable
executable loads in to be able to
execute its program and some of these
are pretty benign kernel 32 you're going
to see a lot all over the place shell 32
you're going to see all over the place
but we do have this column here that i
will refer to as the block list not
necessarily the name of the column
itself but that's what i will be
referring to it in this course and you
might be able to see that some of the
dlls that are imported are likely to be
used in malicious software like url mon
and wininet and let's say you don't know
what these libraries are or maybe what
they do well we also have a description
field over here and so url mon and
wininet are noted as potentially
malicious because url mon is the
embedded library for ole 32 extensions
for windows ole is object linking and
embedding which allows different
microsoft office components to talk to
each other and is constantly used for
malicious software purposes and when
inet.dll is the internet extensions for
windows dll and that's not of course by
itself malicious but is commonly abused
by threat actors and cyber criminals to
download things from the internet uh
open up sockets that kind of thing
and then the last thing that we want to
look at is the strings of the binary and
of course we've already covered the
strings but there is again an additional
layer of analysis that's happening with
pe studio in which we can sort by the
string value we can look at the size of
the strings and sometimes the bigger
strings are the ones we want to be
paying attention to but of course we
also have the hint column here which is
also very interesting so the hint column
is very interesting because pe studio
will take its best guess at what it
thinks the string is doing and we can
see that it identifies some of these
ping and open strings as utility and
that's pretty spot on right uh it also
identifies mozilla 5.0 as a user agent
spot on so pe studio is pretty good at
picking this stuff out and if we rank by
the bad list here we can take a look at
some of the strings that pe studio is
saying these are likely to be abused and
it looks like they've got a couple ones
that are interesting here of course url
download to file an internet open url
two common apis that are used for
malicious purposes and pe studio has
flagged those as bad strings and so all
of this is to say that when you sit down
to start to do your static analysis of a
binary pe studio can be a very very
powerful application to help you speed
things along
so that wraps up our basic static
analysis section we're going to move
into the basic dynamic analysis which
means that we're actually going to start
running the binaries inside of our lab
and recording what we see and i think
that we're now pretty well set up to
take these little pieces of information
from the static analysis section and
apply them in the basic dynamic analysis
section to find out more about these
binaries and what they're doing so meet
me in the next video
now before we go any further let's make
sure that we review our notes so if you
have not been taking notes up to this
point i strongly recommend that you
start if you have been taking notes
let's compare notes to see what we have
so far and really when you think about
it coming out of the basic static
analysis portion we're not going to have
a ton to go off of but there are a few
things of interest so just to briefly
cover some of the things that i saw in
the basic static analysis portion
we of course got the file hash we have
the sha256 and the md5 some hash which
are right here we also submitted this to
virustotal but there were no results at
the time of submission this may be
different by the time that you're taking
the course but for right now there are
no results for these two file hashes now
some of the more interesting pieces of
information that we found we have the
strings and the floss output from this
binary and right off the bat we have
some inferences and maybe some
hypotheses of what could be happening
with this binary we don't have anything
definitive of course but we do want to
make sure that we're being very
scientific and recording some of the
things that we extract out of the binary
and right off the bat the strings that
we have coming out of the binary may be
very telling about what's going to
happen in the next phase and we don't
want to we don't want to say anything
definitively yet but we will be taking
these strings into the next phase of
analysis and verifying to see if any of
them hold any weight and of course when
we reviewed the iat and looked at it in
pe view we saw that there were a few
import address table calls to some api
functions
of note we found shell exec
internet open url a and download from
url now each of these could indicate
malicious functionality inside of the
binary again it is too early to tell but
we'll keep that in mind for when we move
into the basic dynamic analysis portion
and i'd just like to remind you note
keeping in this is so so important so
make sure that you're keeping good notes
the whole time so we're going to move
into the next phase of analysis and
we're going to expand on that as well
hello my analysts all right if you're
joining me from the previous video we
have just wrapped up our basic static
analysis of the first sample in this
course now let's go back to the metaphor
remember that we are scientists and we
have an alien in the lab on the
operating table and during basic static
analysis we have effectively stood over
the alien with a clipboard and a pencil
and we've pointed at a few different
parts of the alien like its antenna or
its eyes or its limbs and we've said i
wonder what this does i'm taking note of
something on the outside here and i have
a hypothesis of what it might be doing
and that is basic static analysis it's a
very good starting point pulling the
strings looking at the iat these are all
good starting points but nothing nothing
is going to tell us more about what this
binary or this sample in general may be
doing than actually running it
and to find out more we need to now move
into dynamic
analysis
this may also be known as heuristic
or behavioral
analysis
you may hear people say one of these
terms heuristic analysis behavioral
analysis dynamic analysis they are all
effectively the same thing
now
we are starting at the basic level of
dynamic analysis and according to our
methodology that means that we are
taking a triage approach with a limited
set of tools and a limited amount of
time to look at what this malware might
be doing and the key fundamental
difference is that we will be running
the piece of malware in the lab at this
point now when it comes to dynamic
analysis there are two categories of
information that i like to think about
dynamic analysis is going to tell us a
lot about the host
indicators
and the network
indicators
now you can think of the hosts and the
network indicators as two sides of the
same coin when something happens on the
binary on the host maybe it deletes a
file
delete
file or maybe it installs itself as
persistence installs
persistence
these are host based indicators because
they happen to the host that the malware
is detonating on
now on the other side on the network
indicator side let's say the binary
calls out
to a domain
maybe it downloads
a file
these would be network indicators
because we have some kind of network
indicator to hone in on to identify what
the binary is doing now there are some
indicators that kind of tread the line
between these two areas so if you think
about something like a dns request well
dns is definitely out on the network
side but there's also a certain
component of windows logs that can pick
up when a process makes a dns request so
sometimes a dns request might be a
host-based indicator if it's being
pulled from a host log or it could be a
network indicator if it's being pulled
from network logs or identifiable on the
network wire
now it doesn't really matter which
indicator you try to look for first
there's really no rhyme or reason to it
as long as you're covering both of these
indicators thoroughly and making sure
that when you detonate the malware you
can get an idea of the things that
happen on the operating system i.e host
and the things that happen on the wire
ie network and if you can get a good
idea of both of those you have really
really good information to go into the
later phases of analysis so without any
further ado let's get going all right my
analysts we are ready to get into our
basic dynamic analysis portion of this
course
so before we do that a couple of things
to think about
first thing to think about is that we
have a certain amount of notes now and
we should let this inform how we perform
our basic dynamic analysis
in other words from the strings that
we've pulled out we already have a bead
on a couple of potential indicators host
and network indicators so we'll be on
the lookout for things like this and
i'll show you exactly how to apply that
and what to look for here in a moment
but the other thing that we have to
worry about is making sure that our
tools are up and ready to go as far as
the detonation of this malware is
concerned so i want to start by doing
something here if we don't have all of
our tools up and running let's say we
arm this piece of malware and we say all
right it's time to see what this does
and we double click and we get a command
prompt window briefly and then the
malware disappears
and so
what just happened well we're not
totally sure right because we didn't
have all of our tools up and running and
ready to go
now one thing that this malware does is
that it reaches out to a domain and
tries to see if it's online and in a
sandbox without an internet connection
there's not going to be any domain for
the malware to contact and the second
part of the logic of this malware says
hey if you don't find a domain there go
ahead and exit out of the program and
delete yourself from disk and so that
can be very detrimental to our analysis
because what if that was the only copy
of that sample that we had on hand now
we've got to go track down the sample
again so it's important to make sure
that all of our tools are up and running
and ready to go so remember that we have
our remnux box over here that's serving
as our internet simulation or inet sim
capability and remember that we have it
set to be our networks dns server as
well so go ahead and on remnucks make
sure that you're running inet sim and
the other thing that i like to have
during the basic dynamic analysis
portion is a listening instance of
wireshark so go ahead and type in sudo
wireshark and when the wireshark gui
comes up you can go ahead and click on
the main adapter here and click this
blue shark fin icon and you can start
capturing packets there's not going to
be a whole lot going on remember that
this is a completely isolated network
but we can check this now by opening up
a web browser and we can go to
google.com
and remember inet sim will serve us the
default internet simulation page and if
we search for something like tcp port
equals 80 and click go we can see that
there is now
traffic being generated here so if we go
to something like h
http colon
slash free t-shirts dot info
we'll be able to see that request to
free t-shirts dot info and we can look
into some of the different headers in
wireshark to go find that so in any case
all we're really doing here is making
sure that our internet simulation
capability is up and running
and that we have our tools ready to go
so we can exit out of that and let's
open up the labs again we'll go back
into the basic static portion remember
that we're using the same sample here
and we'll bring this over to the desktop
infected is the password again
all right and we're moving out of basic
static into basic dynamics so what we'll
do is remove the dot malz extension and
change this to our executable format
now if we examine some of our notes from
the basic static analysis we already
have a couple of things that we can
drill down on to see if we can find more
indicators when we run the malware
itself so there are lots of things here
and we can kind of break these up into
the host based indicators and the
network based indicators now something
like a url right here so we see this
ssl-6582 data manager dot help desk
bros.local favicon.ico that would very
much be a network indicator or at least
a potential network indicator so why
don't we take a piece of this and we're
going to copy this favicon.ico right
here
and we're going to use the tools
available to us to identify more
information about the network
interactions that will be taking place
so let's go over to remnux where we have
our instance of wireshark running and
we're listening on our main interface
and what we want to do is take a piece
of that information and see if we can
search within wireshark and filter the
packets that are going to be coming into
the server
to identify more information about these
web requests so we're going to do
something like http dot request
and you can kind of see it right there
in the in the autofill dot full
underscore uri
and then
wireshark's display filters can do
things like contains or does not contain
or it can search for a string so we can
say something like contains and we can
put in the individual piece of
information that we're looking for which
in this case is favicon.ico nothing's
going to be shown yet because we haven't
detonated the malware so let's keep this
to the side right here
and we can go ahead and double click on
this
and watch wireshark for a network
indicator and wouldn't you know it we do
have one in fact so let's take a look at
what just happened when we detonated the
malware we did get a request to a web
uri that contains favicon.ico
so let's look at the different sections
in wireshark to see what what actually
just happened under the hypertext
transfer protocol header
it looks like there was a get request
for favicon.ico using mozilla 4 as a
user agent and the full uri actually
matches the one that we saw in our
strings output so we've got a pretty
good
correlation of indicators here we pull
the string out of the binary and we
searched for part of that string in
wireshark having set up this remnux box
to catch the internet traffic that's
outbound from our analyst workstation
and now we actually have a packet that's
headed out to this particular uri trying
to get favicon.ico
i'd say that's a very good set of
indicators so why don't we do this we
will bring this to the side and i'm
going to use green shot to actually
screenshot this
and we'll copy this down and we'll bring
this back over and we'll say something
like network
signatures
and we'll copy in that screenshot so
remember that we're after as many pieces
of data and information as we can
possibly get out of this binary and that
is a really good signature when we when
it comes to things like rule writing in
yara and sigma these kind of url
signatures are going to be invaluable
and eventually they'll probably make
their way into like an ip block list for
lots of different malicious urls
but for right now we can keep this as a
really good piece of information for
something that this piece of malware is
doing so we have detonated the malware
one time we have observed a little bit
about the initial detonation and maybe a
few things that happened during that
time but now we need to do something
very very important
at this point you don't know the full
scope of what the malware has done right
we might have a couple of network
signatures we might even have picked up
a host-based signature but you're not
sure if the malware has installed itself
as a registry key or it has installed
itself as a scheduled task or it's
deleted files or it's added files we
don't know any of that so what we have
to do now is revert back to our clean
known good state and so what we'll do is
that we will actually shut this down
and we're going to go back to our series
of snapshots here and we're going to say
we're going to go right back to this
basic dynamic pre-detonation we're going
to restore this and we don't have to
create a snapshot of our current machine
state and we'll go ahead and restore
and so now that that's back to being the
current state we can start up flare vm
again
and remember it's very important to do
this because we got to make sure that we
have a clean slate to run the malware
from given that it might have changed
things in the file system and the
operating system that we don't know
about yet
so at this point we're free to rearm our
binary and execute it again and this
time we'll use other tools to look at
the host based signatures so meet me in
the next video and we'll take a look at
those all right my analysts now we've
talked a little bit about network
indicators now let's pivot over to the
other half of the coin in basic dynamic
analysis which is host based indicators
so there are a number of tools that you
can use for this and one of the first
that i like to go to is a little tool
called proc mon you can go ahead and
just search proc mon and click on that
icon
and this is part of the sys internals
software suite
from microsoft and we will be using the
sysinternal suite a lot when it comes to
host indicators and it's something i
recommend that you try to practice and
get really really good with is all of
the tools in the system internal suite
so we can agree to the end user license
agreement and we are given this kind of
very busy looking ui
now the power of procmon is that it can
tell you information about certain
processes and what those processes are
doing at any given point and sometimes
if you couldn't tell from the amount of
information on the screen it is a lot to
cover
and so what i want to introduce you to
is the most powerful feature in procmond
which is this little filter icon right
here so what we want to do is click on
the filter icon and we can start to put
in filter criteria that will just give
us the information that we really want
out of this section of the analysis
now we don't know a whole lot about this
binary but we do know what the process
name is going to be and the reason we
know that is because it's the name of
the file so if we take this process name
and we're going to drop down this uh
drop-down menu right here and we'll go
to the process name which is right here
and you can say is and there are a bunch
of different criteria you can use so if
you don't exactly know it you might be
able to do contains but we do know
exactly what it is so we're going to set
this to is and then you can set this to
the name of the file when it detonates
which is malware.unknown
and then we click add
so when we click apply and ok to this
the filter criteria will set and now we
don't actually see any
events
yet
but that's okay because we haven't
detonated this piece of malware yet
so what we're going to do is double
click and run
and pay close attention to what happens
here and we can almost see it in
chronological order because we can sort
by time we can also sort by things like
path or operation and so what we really
get a good idea of is what the process
name is which we already know we also
get the the process id which is right
here we get the operation what exactly
is this process doing and we get the
path where in the file system or the
operating system is this interaction
taking place
now the operation column right here is
also one of the most important things
that we can look at so we can take a
filter criteria of operation contains
and what if we want to see everything
that has to do with files we can say add
to files and then we can look at okay
we've got create file we've got a query
name information file we've got read
file and we can expand this path field
here and start to take a look at all of
the interactions that are taking place
so a lot of these are going to be create
file or query file from some of the dlls
that are loading into the binary when it
runs
but some of the interactions here can be
quite interesting if we take a look at
things like well what are the files that
are actually being created by this
process
and if we scroll down far enough we can
actually find an indicator that
correlates with one thing that we found
earlier during our basic static analysis
remember that from the strings here we
found this file path that is c users
public documents and then this kind of
random.exe right here
so we could actually take that and apply
that as a filter and it turns out that
that's in here as create file and so if
we expand out the details we can see
that there was a successful file
creation of this file located in c users
public documents and then the name
well sure enough if we go to the file
explorer and we go into that path so c
we go to users we go to public and we go
to documents
well there it is right there so this is
another indicator that we've picked up
now this definitely wasn't here because
there's nothing in the public documents
uh directory by default and we can
actually test this hypothesis by
deleting this file and seeing if it will
spawn again if we run the malware again
and sure enough it does so we have
another indicator here so let's go ahead
and take another screenshot and we can
kind of set the stage here so that we
are highlighting this right here and
we're highlighting this right in here
and so what we can do is we'll move this
down a little bit to get a better
screenshot right there and let's go
ahead and we will take a screenshot of
this
and copy this to our clipboard
and we'll bring up our notes again
and for
our host indicators so we'll say
host indicators
we can paste this screenshot in and
maybe resize it a little bit just so
that it's a little easier to read
we're starting to make progress and
unravel what this malware might be
capable of now we know that it's
reaching out to a particular uri and we
know that it creates a file on the
desktop somewhere now remember this file
that we've created is going to be the
standard inet sim executable so remember
if we go to like
doesn't exist dot com slash evil dot exe
remember that inet same is going to
serve us up a binary that just says this
is the inet sim default gui binary now
we can kind of start to hypothesize
about what this piece of malware might
do if it downloads a file and lands it
in the file system from a remote address
we might be able to hypothesize that
this is like a malware dropper that it's
downloading something from another
location and dropping it to uh infect
the system with a second stage payload
so we're not going to know exactly what
this payload was unless we're able to go
to this particular url and unfortunately
we won't be able to do that but maybe on
another system that is internet
connected we can go see if this is uh
serving out something at favicon.ico
now something else i want to point out
is that this is kind of a little bit of
tradecraft the favicon is that tiny
little and i'll bring it up for you so
you can see the favicon is this tiny
little icon that's up here uh that
you'll see next to a website uh title in
maybe the tab like you see right here so
for inet sam it's got this little s-i-m
and it's a square now
cyber criminals and apts and malicious
cyber actors like to abuse this fact
because any time you go to a website
like this you are
inherently requesting the favicon.ico
and if it exists it's served up to you
so that it can render in the browser
right here and if it doesn't exist then
nothing happens it's just a 404. so we
see something like this that this
favicon.ico is being requested but
there's something being written to the
file system we just don't quite have
enough information to correlate these
two things so it looks pretty promising
to hypothesize that favicon.ico might be
the second stage payload it's requesting
to this web resource and writing it to
the file system so we've got plenty of
things to look at now as far as what
this malware might be doing so let's
move on with more host based indicators
all right now let's see if we can get
one more host base indicator out of this
piece of malware now remember at the
beginning i showed you that if inet sim
was not running at the time that this
malware was detonated it would actually
delete itself from disk and i'm sure
that there's something that we can drill
into to find how that actually takes
place so let's take a look at this one
right here cmd.exe it's got a ping
command it pipes the output to devnull
and then it actually does a delete
command as well so let's go ahead and
take this command and ctrl c and we'll
go back over to procmon
so when we open up procmon we'll go back
to the filters and we'll actually go to
the details filter so detail
and then we'll do contains
and we'll copy in that piece of
information that we took out of the
strings
and we will add this and we can also of
course do the process name
is
and then our piece of malware which for
this instance is still
malware.unknown.exe
so we can take the name of that ctrl c
copy and then add that as the criteria
again nothing will be showing up in
process monitor yet because we have not
executed it so remember that the
criteria for this piece of malware to
delete was to not have inet sim running
so we can think that maybe the logical
flow of the program might be something
like this if this piece of malware
detonates and reaches out to a given url
and that url does not exist go ahead and
stop what you're doing exit out of the
program and delete yourself from disk
and that can be kind of like a kill
switch for a piece of malware where if
the c2 domain for the malware is not
live anymore just exit out of the
program and and don't continue the
execution and delete yourself from disk
so let's go ahead and see if we can
coerce that to happen remember that we
have our inet sim box over here is
running right now and if we double click
on this the actual program will just
execute and the program does not delete
itself from disk but if we go over here
and we ctrl c and kill inet sim
we should now have the conditions
required to detonate this piece of
malware and have it delete itself from
disk if we double click on this we see
that the command box opens up and if we
pay attention to process monitor we
should see
a call to cmd.exe
the binary does delete itself from disk
and now we can drill down into the
details section of process monitor now
this is very interesting because if we
open this up the binary called to
command.exe to run the very string that
we saw earlier in our strings output
and it turns out that when you issue
this command it will delete itself from
disk after pinging for a count of one
so that is the mechanism for the
self-deletion of this binary and we now
have that as a piece of information so
again we can take our notes here
and we'll bring this to the side and we
will take a screenshot of this and we'll
put this into our host indicators for
our basic dynamic analysis so i have
just copied in this screenshot for our
host indicator and at this point we can
kind of now start to unravel the rest of
the program so we can say something like
this program execution flow if url
exists
download
favicon
dot ico run
favicon
dot ico
ico if i could type
if url doesn't
exist delete from
disk do not run
so we have now
done a very limited amount of reverse
engineering to what this program may
look like from a programmatic standpoint
we now know that if there is a
particular url which remember we
identified as this helpdesk pros.local
slash favicon.ico if that exists which
we simulated via using inet sim as our
internet simulation capability
then the piece of malware downloads
favicon.ico
and there's actually another part here
writes to
disk
named and then we have the name up here
which is
cr433101.dat.exe
and we can put that in here as well and
then run favicon.ico which on disk now
is called
cr4
and then there's another case here as
well if the url doesn't exist the
program stops what it's doing it does
not download favicon.ico it deletes
itself from disk and that's it so that's
our first
foray into basic static and basic
dynamic analysis we took a piece of
malware that we knew absolutely nothing
about we pulled some basic information
about it we used this basic information
to start to look at the different
network and host-based signatures and we
started to unravel what this program is
capable of
and now for the rest of the course every
time we come up against a new binary
that we know nothing about we'll do a
similar kind of methodology to start to
tease apart what the binary is actually
doing and what it's capable of
and so that wraps up our first set of
basic static and basic dynamic analysis
now at this point we might want to call
this something else so instead of just a
generic malware maybe this is now a
dropper
and instead of unknown why don't we call
this download
from
url
dot exe
and now we've more accurately classified
what this malware is capable of and what
it does
all right and that's our first set of
basic static and basic dynamic analysis
if you're sticking with me so far great
job you've you've learned a little bit
on how to take a look at these different
pieces of malware and how to apply tools
to identify what they can do and we're
going to go into more depth on different
methodologies to identify different
pieces of information about these
binaries so i'll see you in the next
video
and we're back all right if you are
joining me from the last video we have
looked at some of the network signatures
for this new unknown binary if you
didn't watch that one go ahead and make
sure you watch that one first because
this is part two in this little series
for doing the basic dynamic analysis on
this sample so go ahead and watch that
one but if you have already watched that
one keep on rolling with this one so now
begins the game of guessing what this
binary could be doing given that we have
a couple of key facts so we know that
it's made an http request out to a
specified server we know that it has
downloaded something that has been
served up by inet sim but in real life
could be some kind of second stage
payload but now we don't quite know
anything else at this point but we can
start to use these as base facts to
start to unravel the rest of the
capabilities but before we do any of
that we have detonated our binary and we
should revert back to a clean state so
we'll go ahead and do that and i will
cut to when the revert has succeeded all
right we're back and i have reverted and
we'll arm our binary
and set it back so that it can be
executed so let's take a look at our
notes and we have a potential file
download we know that inet sim needs to
be running or else we'll get this error
block
and so let's take another look at some
of these strings and see what we can
determine so if we have a potential
network indicator maybe we can start to
chase down other host indicators given
what we know about how it interacts with
the network and so while msd core lib
may not be the name of the binary as
it's written to disk we also happen to
have a file path here and so it looks
like app data roaming microsoft windows
start menu program startup so the
startup directory so commonly used to
put in programs to start when someone
logs in
and a very common vector for malware to
abuse
now could it be that msd
corelib.exe is written to the startup
directory that is a hypothesis that we
can put together and maybe we can test
that now one way that we could do that
is using procmon
what we can do is go run procmon
and agree to the license agreement
now we do have the name of our
executable so let's go ahead and copy
that and we'll go to the filters this
little filter icon right here and we'll
set this
to the process name
there it is i was looking for it but
is and then we can put in our rat
unknown.exe
and we hit add
and we hit ok now there won't be
anything here yet but that's okay we
haven't detonated yet and make sure we
can double check by going over to our
remnux box we can go ahead and stop
wireshark
we can make sure that inet sim is still
up and running and it looks good so
remember we're after host-based
indicators so we don't need to
necessarily worry about wireshark output
we've already captured that let's go
ahead and double click and run
and immediately we've got tons of
information here i mean there is just so
much going on here to look for
but remember that we meet the criteria
for detonation so we should not get that
pop-up box right we have it connected to
a fake internet resource that it's
drawing from now we can start to look at
the host space indicators and one of the
most useful columns of data that we can
filter on here is operation
operation has things like process start
registry key values that are opening
closing being read file creation so it
also has some information about tcp
sockets that are opened up during the
detonation of the malware so it can be
very interesting to go ahead and filter
on the operations here so if you ever
wanted to know maybe the different file
operations that are going on you can go
operation contains and then we can do
something like
file add this as criteria
and now we have in the operations column
things like create file query basic
information file and it looks like this
binary is querying information out of
tons of different dlls and that makes
sense right lots of different
capabilities that a binary might rely on
are in different dlls and this is still
going to be a lot of information but we
can start to cut down on the different
things that we're looking for by giving
different filter criteria
now if you recall there was one string
in this binary that could be very
telling about
what this binary may be doing from a
host-based indicator perspective now
let's go back to our notes and let's
scroll back up to the strings that we
have so remember this file path right
here the startup directory inside of app
data is commonly abused and used by
malware to either install itself as
persistent or perform something at
startup maybe install a second stage
payload have it run when someone logs in
so this is a very very juicy indicator
that we want to latch on to so from our
notes we're going to take our app data
roaming et cetera et cetera and one of
the other very interesting and useful
filter criteria here is the path filter
and we can add path contains and then we
can put in our file path here and click
add
and so we can actually filter off the
operation contains file because we have
another criteria that we're testing here
and hit ok
again if we run this we can see if
something happens inside of that file
path and it absolutely does now let's
take a look at these indicators because
this could be one of the key critical
pieces of functionality inside of this
malware we may have just discovered the
persistence mechanism of this piece of
malware so let's take a look and analyze
so we have ce users husky app data
roaming microsoft windows et cetera et
cetera et cetera it goes all the way
down to startup and that mirrors pretty
accurately the string that we pulled out
of the binary app data roaming microsoft
windows et cetera all the way down to
startup now it looks like it can cats
right at the app data right here so in
other words looks like it doesn't need
to know the first part of this full file
path it looks like it can dynamically
guess okay the user right now is husky
and this will be whatever your user is
on your box and then it'll say okay in
the app data directory drill all the way
down to startup for the husky user
and we can tell that because there is no
c users husky in the strings here it
looks like it determines that
dynamically
all right moving on let's see what it
actually does we can expand this details
pane right here and there's going to be
a lot of information here so let's go
ahead and maximize this screen and
expand this all the way out and we can
even just hover over it to get like a
tool tip here
so we're looking at the ms core
dll.exe right and so it looks like it's
using this as the name of the file that
it is trying to write to it looks like
it's giving right access to this
location
and it looks like our operation is
create file
so if you recall we did not make a get
request to the server for ms core
dll.exe
our get request was actually a little
bit different msdcorelib.exe
but it looks like it may be writing this
file to the file system under the name
of mscoredll.exe
which is weird for a couple reasons
right
first of all why are you calling
something that has a dll in the name an
exe this is an executable and this you
you would essentially think that this is
a dll a dynamic linked library so that
doesn't really make a lot of sense also
the fact that this is being written into
the startup directory in app data is
also pretty suspicious so we're going to
go ahead and take screenshots of this so
go ahead and grab these screenshots this
is all very very juicy information that
we want to hold on to
so we're going to say uh host based
indicators and throw that in right here
and we've got all kinds of information
now to look at here that mscore dll.exe
looks like it's pretty pretty suspicious
and hey why stop there why don't we
actually open up that startup directory
and see if it actually wrote something
because it says that it succeeded but
you never quite know until you check so
let's go ahead and grab this
we'll copy and we'll just go to any file
explorer window and go to the startup
directory and sure enough we've got
mscore dll.exe
if we double click on this remember that
this is the inet sim default gui binary
it does not perform any malicious
functionality but it does represent that
something was downloaded from the
internet and written to the file system
and it's now in the startup directory
meaning that if you log out and log back
in whatever is sitting right here is
going to be executed at the time of
login so that is a pretty tried and true
persistence mechanism for a piece of
malware and that is also something that
we want to put in our notes let's go
ahead and take a screenshot of that make
sure you get the full file path in here
we'll copy that to the clipboard and
we'll say
persistence binary and we will paste in
that screenshot excellent information so
far so we've got a web request out to a
specified server we have a web request
download of an executable that
executable is named something different
from what it was downloaded as and
written into the startup directory and
all of this is contingent on there being
a working internet connection to get to
some kind of web resource otherwise we
get an error message no soup for you but
we're not gonna stop there because
there's more to this binary and so we're
gonna do another round of analysis but
before we do that we should and you know
what i'm about to say reset your vm send
it right back to the
restore current snapshot to whatever
your predetonation snapshot was and hit
ok and i'll meet you back there
alright so we are back out we have
rearmed our binary and reverted back to
a queen snapshot and for the next set of
indicators that we'll get out of this
binary i want you to think a little bit
about when a host needs to make a
connection to some other host
how does it think about and know what
that connection is right
and so the host itself needs to
understand the concept of tcp if it's
going to make a tcp connection so there
are classes of functions that the
operating system needs to understand to
be able to perform that tcp connection
now from the host based perspective we
can actually pick up on some of these
indicators as tcp artifacts meaning that
maybe a socket opens maybe a connection
goes out and all of this is coming from
the host itself so when we talk about
network indicators and host base
indicators there really is a certain
subset of the host space indicators that
have to do with network signatures but
they're not quite out live on the wire
we can't really pick them up with
wireshark they're happening on the host
and that's where we should look for them
so one of those is going to be an open
socket for tcp connections on the host
and we're going to use a tool to see
this called tcp view
now i have installed the sysinternal
suite in my program files directory and
this was a function of the fact that
during the flare installation for this
course
it did not install the sysinternal suite
correctly so i installed it myself and
if you do not have the sysinternal suite
on your workstation you can grab it
right off the microsoft website it's
free and it's a very quick download and
i've included the instructions for that
in another video in this course i'll
link it in the resources so go check
that out now in any case let's take a
look at what tcp view can do
so when we open up tcp view we have the
window of all of the different types of
connections the state that they're in a
local address remote address and port
itself
and this is very important because you
can tie this all to a module name and a
process name so let's sort by
alphabetical order here so we'll click
that a couple times
and to make it very easy for us we'll
just take note of our process name which
is rat unknown and we can go ahead and
find that when we double click here we
should be able to scroll down and it
actually helps out by highlighting in
green when there's a new connection
established but we actually do end up
seeing the process name of rat
unknown.exe has a couple of tcp protocol
events associated with it so let's
analyze we've got rat unknown exe is now
in a listening state on all addresses
that
0.0.0.0 just means don't pick a specific
ip address just give me any ip address
so it's listing on all addresses at
local port 5555 this is a fantastic
indicator so let's go ahead and screen
cap it and we'll say tcp socket in
listening
state and there we go all right so we
have a socket open in a listening state
on port 5555
now we can go over to something that's
in the network
like our remnux box and we'll go ahead
and go to a new
tab
and we've got this wonderful little tool
called netcat which you can invoke with
nc
and netcat can act as the kind of swiss
army knife they call it of networking
tcp and udp connections and so now that
we have an open socket we have another
tool that we can use to interact with
this socket and so we will invoke netcat
with dash nv for no dns resolution and
verbose mode and we will type in the ip
address of our remote host in this case
which is our flare vm box and the port
that is now specified which has opened
up on five five five five
and it looks like when we make a
successful connection we are greeted
with what is certainly base64 encoded
information now remnux has a base64
utility that's built into the operating
system so what we can do is we can take
any string of interest that we'd like to
decode
copy this we can echo this right into
the terminal
and just paste it in between the two
sets of quotation marks and we will pipe
this to base 64-d
and when we hit enter on that we are
greeted with the base64 decoded text
which is what command can i run for you
alright so we've got a couple more
indicators here let's go ahead and take
another screenshot of this so we'll go
ahead and grab everything on the screen
here
we'll copy that to
our notes by saying base
64
encoded data
from socket on tcp 5555
and we'll throw that screenshot right in
there what command can i run for you so
that's pretty pretty interesting right
so let's start to look at the inputs of
this open socket now so you can send
information like
ipconfig and it looks like we've got
something in return here
so let's say that this is
the
encoded information so let's take a look
at what the decoded information
so let's paste this into
there and when we base64 decode it looks
like yes indeed we have command
injection capability from this that is
returned in base64 encoded format so
again very good to take a screenshot of
this because this has confirmed what the
initial report said which was that this
is likely a command injection or command
execution capable remote access trojan
we'll say something like command
injection capability
and we will paste in our screenshot
there that proves it
and of course we can always kind of
resize these if we need to we can go
ahead and you know open it up so that's
just a little bit easier to read but we
have a pretty good indication that this
is a remote access trojan it's able to
inject with commands and return
information by injecting and executing
on the file system and we can prove this
by maybe doing a few more uh we can do
id
and we'll go ahead and remove everything
from the line
and there we go we have the output of
the id command which looks like it does
indeed run and then maybe something else
i'd like to do is just kind of throw in
some random text here to see if it
handles certain exceptions and we can
take the exception here
and let's take a look let's delete out
our other base64 text and the system
cannot find the file specified
additional info requested command not
found asd asd asd so it does in fact
handle those exceptions so this looks
like a full-blown command execution
remote access trojan it opens up on port
5555 to the file system
it has command injection capability and
it also looks like it writes something
maybe not it writes itself to the
startup directory but it does look like
it writes something to the startup
directory so
at this point we've got plenty of
information to go off of to say that
this is a piece of malware we've got
network signatures we've got host-based
signatures and at this point we can call
this whatever we want so we'll go ahead
and call it ratcmd
socket.exe.mouse now back over on our
flare vm box we do have tcp view up and
running here but why don't we combine
this with another tool to see if we can
start to cross correlate and so we will
open up procmon one more time and we'll
go to our filter criteria and let's
filter for the things that we know at
this point we know our process name is
going to be rat unknown.exe
so we will say contains or it could be
is for that matter we'll open that up
and then we'll also filter for
the operation
contains tcp
and this kind of does something similar
to what tcp view over here is doing but
we can get additional information out of
this as well so let's go back over to
our remnux box and remember we have the
open command socket here so let's do the
id command we do get a callback from
that but let's look at what happens over
here
we open up the details section here and
it looks like we do have a successful
tcp receive and a tcp send coming off of
process name of
rat.unknown.exe
so in lieu of something like tcp view we
can use procmond to look at the tcp
operations which could include send
receive maybe the socket opens up let's
say let's go ahead and go to task
manager
and we'll find the
rat unknown which should be right around
here
we'll end this task end process
and then if we keep this we can see the
tcp disconnect
that's another indicator that we have in
the tcp operations section and if we
double click on this and run this rat
one more time we have all kinds of
information we've got tcp connect send
receive and so this goes to show you
that procmon can also be used to filter
on these operations super powerful super
important to look at the different types
of things that the process is doing on
the file system and the operating system
and now let's take one more pass here
let's open up our criteria to be a
little more broad so let's uncheck the
operation contains tcp
and here from the blank process monitor
screen we can go ahead and just click
the clear button if you have
extra information that you don't want
remember we're going to start fresh here
so let's go back over to remnux let's
issue another command let's do who am i
and we do get the base64 encoded
response here but what's more important
is to look over here on the host for
this and it looks like we have a lot of
information here but it does in fact try
to find the who mi.exe binary and so
that's interesting as well with this
command injection you can actually see
the the mechanisms for how the command
injection takes place and it looks like
it's a straight system execution it
looks for maybe a binary that's called
that whoimi.exe and in this case it
found it inside of system32 and it
performs whatever that binary is meant
to do and it returns the information by
tcp sending it back to the origin for
the client that's connected to this
command injection server so let's wrap
this up at the end of the day what does
this really look like when it comes to
malware well we can call this a couple
things this looks like a remote access
trojan it looks like it has command
injection capability but remember that
it opened up a listening socket on the
host that it infected
and there's a very specific term for
this this is actually a bind shell that
looks like it has command injection
capability
so we have bound port 5555
to the operating system and we say
anybody who connects here
on port 5555 can issue a command and
remember if we open up remnucks over
here
we can issue a command after we have
connected to this port successfully and
the command will be executed on the
operating system given that we took a
look at our process monitor and we found
that it will look for something like who
am i or maybe it opens up cmd.exe and
executes it that way it reads from the
output of that execution and it sends it
right back to the client that has
connected classic bind shell meaning
that we have to connect to it first
we're able to issue commands to it and
the command output is returned to us so
we can call this rat unknown we can call
this rat bind shell i think you can
really call it whatever you want but i'm
going to go ahead and call this rat
command shell.exe
and with our report we can now submit
that for additional analysis given that
we have performed the triage and the
basic dynamic analysis successfully it's
a great job there we have looked at a
piece of malware that's able to inject
execute and return the output of
commands on the operating system good
stuff all right analysts now we are
going to take a look at our new sample
for another round of basic dynamic
analysis
and so i would like you to
find the
rat.unknown.exe.mals sample which is
located in the basic dynamic analysis
directory and so first things first we
should take a look at some of the text
files that have been left in here so
let's check out the read me
analyst excellent work with the last
sample please take a look at the one in
this directory our ir team said it might
have command execution capability but
we're not sure please proceed directly
with basic dynamic analysis and
determine network signatures space
signatures command execution
capabilities if any and any other
findings from the reverse engineer team
okay great so we have our orders
so let's take a look we've got the
md5 sha-1 and sha-256 hashes already so
thank you to the ir team for pulling
those so that's one less thing that we
have to do
and we have the standard password of
infected as well all right so why don't
we
open up our notes to a new section and
we're going to call this rat dot unknown
dot exe
dot mouse
and we have our 7-zip file right here so
we can drag that right to the desktop
open this up we do our standard password
of infected
and we can open it up and drag the
sample right to the desktop now the
reverse engineer team has asked us to
proceed with dynamic analysis but we
will pull the strings and take a look at
some of the other static artifacts of
this binary just to aid us in that
effort
so why don't we open up a commander
window
and on the desktop we're going to run
floss.exe
and we're going to point it at our
sample but i have found that it might be
helpful to write the output of foss to a
text file so we can uh parse through it
and look through it without needing to
stay inside of the terminal and so what
we can do is write this to floss.txt
hit enter on this and it might take a
second but it should be going now and we
see that floss.txt has appeared on the
desktop so just give this a second
all right and at the completion of floss
we should get our terminal back and we
have floss.txt which we can open up
we're going to have a lot of useless
string information here some of these
are just not going to be very helpful
but that's okay
now do the diligent work of looking
through the strings here now eventually
if you've scrolled through the strings
and you've taken a look you might start
to find some things that might look
familiar so it looks like we might have
uh connection keep alive connection host
with some user agent information here
and then we start to get some very
interesting things we have internet open
w internet open url w
we have message box w so it looks like
these strings are actually making
references to windows api calls and so
these ones are interesting in particular
and we also have some very interesting
strings here which look like what
command can i run for you online no soup
for you
uh we've got a nim http client right
there so name is a language that malware
can be written in so it looks like it's
invoking the uh http library and we've
got it looks like an executable name
here so lots of very interesting strings
here so from right about here
up i think i'm going to take all of this
and put this into our interesting
strings section so strings
and floss output
and we will throw that in there and all
of these may be useful when we start to
do our dynamic analysis because if you
look here we might have a second stage
payload executable name it looks like we
might even have a url down here so all
of this is very helpful and it's stuff
that we will want when we go into our
basic dynamic analysis section
all right excellent so we have taken a
look at the strings and of course the
point of this portion of the labs is not
to focus on static analysis but static
analysis is of course very important to
be able to get a good read on the
indicators that we want to find in
dynamic analysis
all right so let's go right back to just
the open desktop here and we have our
rat unknown.exe.mals
and of course we can arm this by
removing the dot mal's extension and say
yes and we have an executable now
and so we can now do our initial
detonation and triage of this piece of
malware so let's go ahead and double
click on this and wait and just see what
happens
alright so that did take a second there
but if we just wait for the
malware detonation to take place we will
have this error box no soup for you all
right interesting so that's our first
indicator so we can go ahead and take a
screenshot of this and we can say that
for initial malware detonation we have
something that looks like this i posted
it twice there but that's okay we'll go
ahead and say initial
debt
and we've got a
an interesting message box here that
says no soup for you okay
like i said there's always more to what
meets the eye for this kind of malware
so we're going to go ahead and say that
the initial detonation looks like it's
not going to execute much now there
could be something happening in the
background here and you're you're never
going to quite know from just looking at
the malware as it detonates but that's a
very good indicator to keep and it also
was in our floss output there you
remember that we got the string for no
soup for you so it looks like we've
pinned down part of the execution here
is that under some kind of execution
conditions a message box pops up and it
says no soup for you alright so that's
good good to know but what else could be
happening behind the scenes here so
let's go ahead and play around with a
few ideas in the basic dynamic analysis
phase we want to get a good read on
host-based indicators and we want to get
a good read on network-based indicators
let's go ahead and make sure that our
inet sim box is up and running so that
if this malware is going to attempt to
call out to the internet it has a place
to go so we'll go right back to our pmat
remnucks box we'll make sure that's
started up and it will restore itself
and remember when you're starting up vms
and stopping them and suspending them
sometimes the networking stacks get a
little a little weird with that so all
you really need to do is make sure that
inet sim is running and then if
necessary you can go right back over
here to the pmat flare box and just make
sure that the dns server is set to the
ip address of that inet sim box so we'll
go ahead and make sure that we do that
right now so let's just ctrl c and stop
inet sim and then we can start it back
up just to make sure that it's got a
nice clean startup and we can go ahead
and go back right over to our pmat flare
vm box and just remember that we can put
in any kind of ip address or url here so
google.com should get us to the default
inet sim server page and it does
excellent alright so we know that upon
detonation of rat unknown.exe we have an
error box that pops up and we have some
kind of activity happening but we're not
quite sure and we're going to add in the
ability for this piece of malware to
reach out to the internet and receive a
valid response upon detonation let's go
ahead and see if we can coerce this into
giving us any more information
now remember over here in remnux we also
have wireshark that's available to us so
let's go ahead and select the correct
interface and hit the blue shark fin
icon right here to start capturing on
that interface and then with both of
these things running let's go ahead and
run
our binary and we can go right back over
to
remnux and it looks like we've got some
interesting information here
so we have used the combination of inet
sim as well as wireshark to pick up some
of this information and it looks like we
might have something of interest now it
looks like we've got plenty of
information as far as tcp packets that
are trading back and forth but the first
higher protocol that we can find is
usually the most interesting one so for
example this tcp handshake looks like it
is setting up the connection
but we also have this this http packet
here which is a higher protocol and
therefore might have more interesting
information for us so i like to go right
to the highest possible protocol that
can be parsed by wireshark and so it
looks like we have a get request out to
a uri here http colon slash serv1 dot
ec2 102 95 13 2
ubuntu dot local now this is a fantastic
indicator right here so i'm gonna before
i do anything else i'm going to go ahead
and grab a screenshot of this and make
sure that i can even open up the image
editor here
and within the image editor i want to
make sure that i draw attention to the
different things that are interesting
here so we have a potential uri and we
have a get request with a very
interesting uh user agent if you haven't
noticed that go ahead and take a look at
that that user agent and i don't know
about you but i've never seen one that
had that as a valid user agent before so
very interesting stuff and there's
another thing that's very interesting
here here at this http packet it looks
like we have a get request for msd
corelib.exe and that may be some kind of
second stage payload that could be some
kind of additional capability and we
don't quite know this yet but that's
very interesting so let's go ahead and
highlight that as well when we have our
highlights here we can go ahead and copy
to our clipboard and open up our notes
and let's say we're doing our wireshark
packet analysis and we can go ahead and
paste that picture right in and resize
it just to make sure that it fits nice
and well so when the binary has
somewhere on the internet to reach out
to and make a request to and by the
looks of it it's this uri right here
serv1.ec2 etc etc
this error message does not pop up
and in its place we have a get request
to that url plus the msdcorelib.exe
binary and again we don't have enough
information to make any determinations
about what this might be doing but it's
very very interesting information to
have and it's correlated with some of
the strings that we found earlier when
we ran floss against the binary it looks
like we have a bead on this string that
ends up being a url and we also have
this string and this string right here
so all very interesting information
now back in the wireshark output we're
going to take a look at a very
interesting feature and a very useful
one as well that uh wireshark has which
is the follow stream feature if you go
down you you can right click on any
packet in the wireshark capture and go
to follow and you might have some
different options here you can either
follow the tcp stream or you can follow
the http stream again i like to try to
follow the the higher protocol meaning
the one that is higher up in the osi
model and so the tcp stream of course
would be lower than http
and so we might get more readable
information more human understandable
information out of the http stream so
let's go to this get request of
msdcorewib.exe
and we'll go ahead and right-click go to
follow and go to the http stream if we
follow this http stream we see that
there is a get request to a particular
resource on the serv1.ec2
ubuntu local machine and so inet sim
responds in turn with its default binary
that it serves up and it looks like
there was a successful transaction so if
this piece of malware was not in an
internet simulated network meaning that
it doesn't have inet sim to talk to
perhaps it would go out to the actual
url that is located here and try to
download this file and so it looks as if
this has been written somewhere on the
operating system given that it has
successfully downloaded the inet sim
default binary and perhaps it's writing
it somewhere and that's very important
information because that could be a
second stage payload or it could be some
other kind of capability so it's
something that we're going to want to
track down now unfortunately there's no
guarantee that this is the actual name
of the executable on the file system
and so what can happen is that a
download from a web resource and the
writing to disk can be two very separate
transactions the data of the download
can be transmitted first and then
written to the file system with another
name so that's actually a common piece
of tradecraft among red teamers and
cyber criminals
it's known as dechaining or decoupling
meaning that you download a web resource
and write it to disk under a separate
name so we have this as a very
interesting piece of information we'll
go ahead and focus in on this and we'll
say
potential file download and we'll fill
in the msdcorelib.exe
all right so we have uncovered some
interesting information so let's go
ahead and move to the next video in
which we continue the basic dynamic
analysis of this unknown binary so meet
me there
all right everybody it's a great day to
take down another malware sample and
here we are back in flair vm now if you
have not done so already always remember
to revert your machine back to a clean
state
before you execute any more malware so
this sample will be located in the labs
go into the two dot basic dynamic
analysis section and this one is rat
unknown two unknown2.exe.mals the last
one that we did was unknown this one
will be unknown to dot exe dot mals
now as always we've got a little help in
the form of the hashes that we already
have here
we have the password of infected pretty
standard and we've got the readme from
the reverse engineer team it says
analyst
excellent work with the previous samples
you are really coming along with your
skill set
we found another sample on the endpoint
that looks similar to the last one give
it the triage treatment and let us know
what you find alright sounds great guys
so
we will go ahead and begin by
transferring over our sample and we'll
bring it onto the desktop with the
standard password of infected
so we have our sample on the desktop
ready for analysis
now we will start by doing a limited
amount of static analysis and so we will
pull the strings and look at the iat of
this binary we of course already have
the hashes and we could submit this to
virustotal if we wanted i have already
done so and it does not return any
results so it looks like this is a
custom fresh sample never seen before in
the wild
let's open up a commander shell
and we'll go ahead and change
directories to the desktop and we'll run
the floss utility
against rat unknown2.exe.mouse
and what we want to do for this is pipe
this out to flossout.txt
hit enter and we're going to let that
run for a little bit now as we're about
to open up the floss output here and
take a look at the strings that we've
extracted from the binary i hope at this
point we're starting to get into kind of
a rhythm or a methodology here where we
will
take the sample we'll take the hashes if
they haven't been provided we can upload
it to virustotal and then from there we
have a couple of activities that we can
do given that this is a portable
executable 32-bit or 64-bit for a
windows system so um it i hope at this
point that we're starting to develop
kind of our methodology here now
eventually at a certain point when
you've been scrolling through this and
you're taking a look you will see
certain things that identify this as a
nim compiled binary uh we have a lot of
libraries that are referencing dot name
extensions uh we have socket callouts
that kind of thing again nothing
definitive at this point we're just
pulling the strings eventually you may
get to the point where you see just a
couple of these that are kind of
interesting now we have a cmd.exe string
in here with the slash c flag which
means that it is able to run a command
and we've got a dot local here but it
really doesn't look like we have any
definitive urls or ip addresses or
anything like that and there's probably
a reason for that and we'll get to that
here in a second uh so the strings in
this case you can go through and try to
find some more information but there's
just really not a whole lot going on
but that's okay so that's really just
one part of the puzzle and if you find
yourself getting kind of bogged down and
looking at the strings and not being
able to determine much of what's going
on go ahead and move on to another part
of the analysis and remember those those
key pointers that i gave at the
beginning of the course remember to
never get too bogged down in some of the
finer details there actually happens to
be a reason why there are no ip
addresses or
urls in this particular sample and
that's kind of one of the points is to
make sure that not all the answers are
going to be immediately available every
time you pick a single part of your
methodology but it's much more about
drawing different threads together and
really painting a comprehensive picture
now let's load this thing into pe studio
all right and we can take a look into
the import section and see if we have
any on the uh bad bad list over here and
there are a couple but nothing really
stands out virtual protect might be on
might be flagged as kind of suspicious
here but virtual protect is used in a
lot of legitimate cases as well
um now of course
this kind of thing comes with experience
and you may not know exactly what an api
call is at any given point or what it
might be doing but i always recommend
that you break out the microsoft
documentation for each of these calls if
you're not familiar with them and
through practice and through kind of
getting familiar with with what malware
looks like and what regular programs
look like you'll get kind of a feel of
which ones of these api calls are worthy
of your scrutiny and which ones are
probably okay
uh but we can move right over to the
strings here and it looks like there's a
whole bunch but right off the bat we've
got a couple that are probably a little
suspicious connect select send
classified in the network group so this
is going to be kind of your socket open
socket close socket send which is
effectively a library to be able to work
with opening sockets opening a network
point of presence so that you can send
and receive data on a network and we've
got our socket call out right here in
string form
but in any case again when we look at
the strings here when we look at the
indicators that are coming out of pe
studio we don't see a whole lot going on
so
why don't we move right on to our
dynamic analysis and what we'll do for
our dynamic analysis always remember
that we're going to have remnucks
running in the background over here and
let's just have inet sim up and running
and we'll also have wireshark running as
well so we can capture all of that good
network traffic we've already kind of
deduced that there is a socket
capability here so we want to be on high
alert given that there might be some
kind of network indicators coming off of
this binary
all right so let's arm up
and always a good time to double check
that you have a good
snapshot to revert back to just in case
and we're going to go ahead and run as
administrator
and let's move right over to our remnux
box and let's see what happens and it's
it seems to be scrolling a little bit
but we do in fact have some information
here
and we've got dns queries coming out
let's take a look
and if we open the highest protocol here
which is our our dns protocol we can
open up the queries section and it looks
like we've got an a record looking for
aaaaaaa.kadusis.local
okay excellent now if you recall
in the strings of the binary if you
looked thoroughly enough you would not
be able to find any of these you might
have found caduceus you might have found
local but you would not have been able
to find all of these
and the reason for that there's actually
a couple reasons for that here i
employed a common malware tactic where
the strings are built at runtime during
the binaries execution instead of
compiled so in other words
there are some times when a malware
sample will have the url kind of hard
coded in the in the code itself as a
variable maybe the string variable is uh
domain name equals and then it is you
know free t-shirts dot info or something
like that or in this case aaa dot
caduceus.local
but there's a way to break up the string
so that it cannot be assembled unless
the binary is actually running and so
when you see these a's here this is
actually
concatenated at runtime so it goes
through basically a for loop and it says
okay add a until you hit i think there
are 20 here total
and then when you have that pass that
into this full domain record here and
then that is going to be your domain for
call out always be on the lookout for
that this kind of goes to show you that
the domain names the ip addresses
usernames passwords that kind of stuff
skilled malware authors will not always
hard code those into the binaries that
you're examining in fact more often than
not they're not going to be in there but
always keep a lookout because there are
still other indicators that you can find
in this case we had to go to dynamic
analysis to be able to pull out this
domain record so now that we have a
domain record what can we do with this
well i think the first thing that we
want to do is let's get our notes going
here
and we're going to call this
rat.unknown2.exe.mouse
and of course we could have had our
static notes in here but we're in the
dynamic analysis section at this point
so i'll just be recording notes for that
but i do encourage you to record all of
your notes that you're taking in this
and so what we can do is take a quick
screenshot here so let's grab a green
shot screenshot
and we'll actually get the hex dump as
well why not copy to the clipboard and
we'll throw this in we'll say dynamic
analysis
throw that picture in there
and of course we can resize this to make
it a little bit easier to see and so we
have an a record
uh dns
of uh a and i'll just do dot dot i think
there are about 20 of those dot caduceus
local
okay fantastic notice that there's no
http there's no even tcp at this point
um there's no other indicator of any
other network traffic going on we really
have a dns callout and then nothing else
we have some icmp that fails right uh
because it's looking for that um so
that's definitely interesting because if
there was kind of an http if there was a
web request opening up we'd probably see
that and then that would fail if there
was nothing to respond to it but it
looks like this one is just looking for
an uh a dns record
so
i want to show you guys a technique that
i have come up with in instances where
you are getting a domain call out or
maybe an http request and it's
effectively it's pretty similar to
keeping inet sim up and running but
instead of sending it to another box
we're actually going to send it to
ourselves now this binary right here
has a value
in it that says i am trying to reach
aaaaaaaa
dot caduceus.local
now what is stopping us from saying oh
caduceus.local is the box you're on
right here
and one way that we can do that is by
using
the hosts file which is a very simple
thing to do but it's actually good
enough to trick the malware into
thinking that it is connecting to its
home base server
so what we want to do here is we're
going to search for commander
but we're going to open it as
administrator because what we want to do
is edit the etsy hosts file on this
system so we'll do
nano which is built into flare vm by
default and we'll do c
windows
system 32 drivers
etsy
and hosts and you can of course tab auto
complete
and we'll launch into nano for the etsy
hosts file now this is exactly the same
as the etsy host file on linux so you
can specify an ip address and then
specify a domain record of where that ip
address will send and the local host
will read from this file first before it
attempts to resolve any other dns
records
and so what we want to do in order to
trick the binary into thinking that
whatever it's looking for is on the host
that it's currently on
we're gonna punch in 127.0.0.1
and just hit some spacebars until you
get to in line with the other ones here
although it doesn't really matter
but i like to keep things nice and clean
and we'll go right back over to our
wireshark capture and open it up down to
the queries section here and down into
this aaa caduceus local
and of course you can click on the name
field right here which is the d has the
value of the dns record we'll click copy
and we'll do the value right here so
just click copy and value and that's
going to copy in that aaa dot
caduceus.local
we'll head right back over to flair and
we can just right click right in here
inside of the terminal and that will uh
paste it in
so we have our record pointing at
localhost127001
in order to save this in nano we're
going to hit control hold down control
and hit o
it's going to say file name to write and
you can just keep it standard it's a
system 32 drivers etsy host keep that
standard it will say wrote 22 lines when
you hit enter there so again that is
hold down control and hit o
so just like that
and then you can just hit enter and then
to exit out of nano you're going to do
basically the same thing hold down
control and hit x
and we're back
alright so
now at this point
this binary is going to attempt to call
out to that resource that domain record
and if we have something on this host
that's going to be able to respond to
that traffic
we're effectively tricking the binary
into thinking that it's talking to its
home based server when instead it's
talking to us
so
nifty little trick pretty simple it's
effectively the same thing of what inet
sim and and some of the other internet
simulation uh capabilities are doing
all right so we're starting to unravel
the puzzle here but we do kind of have a
problem
we do know that it's attempting to reach
a dns record but remember as i said the
wireshark output does not really have
any other information it says that it's
pointing at a dns record but it does not
say a port uh it does not say any kind
of protocol
so we we've got a problem we don't
really know how this is trying to
connect to that dns record now what from
the host can help us out with
determining what that might be
why not procmon why don't we open up
procmon
and you see how we're kind of starting
to build out a methodology here and i've
already done so but you can open up the
filters here and we've done this a
couple times so you should be uh pretty
good at this now
we've got process name is rat
unknown2.exe and we've also got
operation contains tcp and we want to
make sure that we're catching any
network traffic from the host level that
we can find on this so we'll go ahead
and hit ok for this
we've got nothing in procmon's output
because we have not executed the binary
at this point so let's go ahead and run
and there we go we've got some call outs
here and
immediately we can actually determine
what's going on if we look at the path
column right here and it looks like
we've got from local to
aaa caduceus.local on https
so we can now take that and let's go
ahead and write in our notes we'll
definitely take a screenshot of this
and we're going to bring this right to
our notes and say potential
call out to
specified
dns
record
on https port
443 and that is four four three again we
don't know that for sure but we do have
a protocol that supports that from the
call out after we detonated the binary
while looking at it in procmon so we've
combined a couple of tools at this point
to try to pinpoint what this binary is
doing so at this point because the
binary thinks that its home plate server
is us let's go ahead and open up our
netcat
we'll dash nvlp
and we'll give it 443 given that
the binary is attempting to call out on
https
so let's see what we have
and it looks like we do have a
successful connection here
and we have in procmond a tcp connect
and we can take a look at the details
here
and it looks like yes this did in fact
succeed we now have an open socket to
our home plate server which we've
tricked the binary into thinking is us
so
at this point what else can we do to
determine more information well remember
that this is rat.unknown2.exe
so it's likely that this has some kind
of command injection capability but if
you didn't know that if this was just
unknown.exe now that we have an open
socket here what do you think would be
some of the first things that you would
do to determine what this binary was
doing i know that i would absolutely
throw in a who am i and see if i get any
anything back and it might not be
immediately but you did just see the
flash there and it looks like we're
getting some more information back here
we've got a couple more connects we've
got a tcp receive a tcp send and then
we've got an output of desktop slash
husky
so
let's take a step back and think about
what we have on our hands here where the
first
binary that we looked at that was
similar to this was a bind shell it
looks like we have the other half of the
coin here which is a reverse shell in
other words we have set up a listener
and when the binary was executed it
reached out to the listener it connected
to the listener and it opened up a
command shell and now we can input
commands like id
we look in the background here and look
at that how cool is that we see it
actually happening and boom it's got our
uh output right here alright so we've
got pretty good indicators right now
again screenshot screenshot screenshot
let's take another one right here
and we will say
reverse
shell
capabilities
and we'll throw the screenshot in there
and we can resize that a little bit
there we go perfect all right so so far
so good we've got a bead on our reverse
shell capabilities of rat unknown2.exe
now meet me in the next video and we're
going to continue the dynamic analysis
and we're going to take a look at a very
interesting concept that's very
pertinent to malware analysis looking at
the parent and child process
relationships that are going on inside
of this binary so meet me there and
check it out
all right we'll pick right back up from
where we left off this is part two of
the reverse shell so we're working with
rat unknown two dot exe so make sure if
you haven't seen part one go check that
out first uh but if you have keep on
rolling with this one and we'll pick it
up right where we left off
all right so so far so good we've got a
bead on our reverse shell capabilities
of rat unknown2.exe
so why don't we clear this out
and we'll take a look at the filters
and let's broaden our search again so
let's take out tcp and click ok
and let's just throw in another command
let's do id
and we should get something pretty
similar to what we saw with the bind
shell again this is going to be we've
got our tcp receive and remember that
the receive and send is going to wrap
this whole all everything else that's
going on with this binary the tcp send
and receive are going to wrap those and
it looks like again it goes kind of down
the list it tries to find something in
the current working directory that it
can execute and if not if it doesn't
find anything there it goes to system32
and it does find
command.exe now i want to take this time
to talk about something that is super
super important when it comes to
defenders taking a look at processes and
really even from a red team perspective
this is also very important for
operations as well
and this binary is a really good example
of the concept that i'm about to talk
about so procmon has a really awesome
feature right here called the process
tree and let's go ahead and open up the
process tree
so from explorer.exe we want to go down
a couple processes and find our
rat.unknown2.exe
right here so this is our parent process
of our actual malware but there's
something i want to point out here this
process is actually in turn a child
process of
explorer.exe if you're not familiar with
explorer you've probably uh at some
point in your life gone to task manager
and opened up details and maybe you've
gone to explorer.exe and done this
and then your friend maybe if you did
this and and pranked them they probably
were freaking out a little bit
but of course you can always just type
in explorer.exe
and start one up again and it's all good
so what was the point of that little
thing um your explorer.exe process is
the process that spawns all of the other
interactive things that you can do on a
windows system so this is like the big
parent process of all of the kind of
interactive stuff that you can work with
now let's take a look at procmond
procman is actually a
child process of this explorer.exe so in
procmond anything that proc mon has
going on for it inside of the operating
system it will be tied to this parent
process by uh pid right here
so often in logs you'll see something
like ppid which is parent process id of
2768 which would be explorer.exe
so when we talk about malware there's
always like i said more to malware than
meets the eye rat.unknown2.exe
has a process id of nine two four but if
you see these kind of grayed out images
here at certain points during the
execution of our program remember that
if we went back over to our main program
over here let's do like an ipconfig
right
so
what will happen here is that the main
process of rat unknown2.exe
is going to spawn a new process as its
child and that child process is going to
be cmd.exe in this case now what's
interesting is that you can see the
arguments of that child command down
here in the process tree and so you can
see cmd.exe is called for id right there
now this happens for all of the other
times that we have executed something
from this binary so the idea is that rat
unknown2.exe is the parent process and
is spawning these other child processes
for cmd.exe if you've ever seen some of
those very expensive very high-end
endpoint detection response uh products
and i won't name any here but you can
you probably know what i'm talking about
something they do really really well is
they graph out in visual form the parent
processes the child processes and they
identify if any of them are out of line
or seem kind of weird so in other words
if you have an unknown executable that's
spawning cmd.exe and that in turn is
spawning all manner of commands like id
or who am i or ipconfig
somewhere along the line you've got to
say some of this is is pretty suspicious
and that's kind of the idea of
parent-child process relationships and
so skilled malware authors will try to
break or de-chain also known as
decoupling this parent-child process
relationship as often as they can and
there are many ways to do that which
we'll get into a little bit later in the
course uh for right now remember that
the malware that we're dealing with is
quite naive it's quite um built not to
be sophisticated to be better for an
entry-level analyst to be able to study
but at some point we will get to some of
the more sophisticated malware but for
right now just know that
the process tree in procmond is a really
good way to see
from the main binary that's detonated
here what other types of information can
we get out of it as far as child
processes and what those child processes
are doing now the other thing to note
here is that you won't be able to really
see much of that information by just
filtering off the processname
rat.unknown2.exe
so what we can do is go to parentpid
right here
and we'll put in the pid for the rat
unknown.exe process which is 924
and we'll add that in and click ok
now we'll filter on anything that has
rat
unknown2.exe as its parent process and
when we do that we actually get a whole
bunch of other processes that are under
it and we've got all our calls to
cmd.exe here and we can actually just
pick out a few of them here we've got
our ipconfig looks like it queried and
found ipconfig in system 32 and was able
to do that
and so that is the idea so remember to
filter not just for the name of the
executable of what you're detonating but
remember to pick up the process id of
the main executable and set it to the
parent pid which is right here
when you set it to the parent pid
it will pick up any child process that's
coming off of the main one and that can
be super revealing as far as what the
malware is doing at any given point
hey everybody it's husky here i hope
that you're enjoying this five hour
release of practical malware analysis
and triage on youtube we're more than
halfway through the course look at you
go congratulations on that and hey right
now would be a good time to take a break
stretch out go for a walk drink a nice
big glass of water or maybe call a
friend and tell them how much they mean
to you
and hey while i have you remember that
the full release of this course is still
available on tcm security academy and if
you want four more hours of advanced
malware analysis techniques and
specialty malware classes then you can
go right to the link that you see on the
screen right now and purchase the course
and if you use my affiliate link i get a
little bit more of the profit and i
thank you for that anyway we're almost
done with our intermission here so
please enjoy this nice little boss in
overtune and i'll see you back in the
course
[Music]
[Music]
[Music]
all right my analysts i hope you're
ready for a challenge today it is now
time for the first challenge binary in
this course which is challenge number
one silly putty which is available in
the main labs directory go to 1-3
challenge silly putty
and just to set up the scenario it looks
like you're getting a binary from the ir
team who is saying that this is a
program used by the i.t admins at the
corporation
and they've been using it and they had
no problems until recently but it looks
like now it is popping up weird blue
windows and crashing sometimes so they
think that there might be something
going on with it and they want you to
take a look at it
now the way this challenge is going to
go take a look at the objective we're
going to do static and dynamic analysis
on this sample and extract some facts
about this malware's behavior and then
we're going to answer the challenge
questions that are down here at the
bottom
and of course these are the tools that
we are using that we have learned so far
in the basic static and basic dynamic
portions of this course so take a look
at these questions these are the ones
that we'll be answering for this
scenario crank up your favorite lo-fi
chill beats to dissect malware 2 and
have at it and try to make it as far as
you can but if you get stuck remember
that the answers directory has a readme
file with the answers for this challenge
but as i said try to get as far as you
possibly can without using that first so
go ahead and open up to the main lab
repo go into labs and right down here
1-3 challenge silly putty we'll go ahead
and open that up and right in here is
going to be your challenge binary in
this password protected 7-zip file have
a great time get after it and don't
forget that the answers are right here
if you get stuck so good luck
all right analysts i hope that you
enjoyed that challenge i hope that you
were able to answer at least some of the
questions and also i hope that you were
able to answer them all um and
regardless of if you were able to answer
all of them or none of them hey even
just getting in the ring getting in
there and taking a look at these
binaries and seeing how to you know pick
them apart and figure out how they work
you know that's commendable so great job
on that now if you're joining me from
the previous video this is going to be
the walkthrough for the first challenge
in the course which is silly putty and
i'm going to be following along with the
questions that have been provided uh so
just follow along with those and we'll
start there
so one of the first things that we need
to do is get the sha-256 some hash so
we'll go over to the desktop and just to
do this one i'm going to stay right in
the terminal and launch a powershell
instance all right so from a powershell
prompt i'm actually going to use the
hash getfilehash.com
and we'll pass it the algorithm
parameter and the algorithm in this case
will be sha256 and we can tab
autocomplete that and then we pass it
what we're trying to hash which is the
putty.exe
binary and so we do have the sha 256
hash and we can pull that and submit
that as the first answer the second
question what is the architecture of
this binary among other tools one that
we can go to to get that answer pretty
quickly is we could go right down to
utilities
and we can open up pe studio and pe
studio is actually going to have a lot
of this information as well so we could
just load in putty.exe into pe studio we
actually could get the sha-256 right
there as well but we do see that this is
a 32-bit executable as identified by pe
studio great
now if we were to submit this to
virustotal at the time of recording this
i did not receive any results from
virustotal for the sha256 sum uh that
may change as the course goes on if this
hash becomes known that it is a piece of
malware in the course uh it's likely
that that is going to change as well
but for right now there are no results
so we will be moving on describe the
results of pulling the strings from this
binary so this was intentionally made a
little more not necessarily difficult
but this pulling the strings out of this
binary was a little less helpful in this
instance than it usually is and i'll
explain why here in a second all right
so if we exit out of that powershell
prompt and go right back to the regular
commander prompt we can go back to the
desktop i'm going to use the floss
utility but i'm going to actually pass
it an argument of dash n and i did not
cover this in the course but the dash n
argument is actually very powerful and
it will try to cut down on any strings
that are of size n or less so in other
words if you want a minimum string
length of 8 you'll pass in
n8 and then we'll throw the executable
name in there for putty.exe always a
good idea to output this to floss.txt
for the output because it is a lot of
information and just let that run for a
little while because this is a rather
large binary and there are lots of
strings inside of it this may take a
long time
so while we let that run if we go back
over to pe studio there should be a
strings section in here and again there
are lots of strings in here but we can
take a look and we can also sort it by
the block list here
and we can take a look at some of the
strings and see if we can pick anything
out in particular but the reason that
this was a little bit more difficult
than it's been in the rest of the course
is that well this is putty.exe this is
not just some kind of like dropper
program or a very very small malware
program
if this has been provided to us because
it's been suspected to be malware it
appears that this is probably a
backdoored program i.e a program that
has legitimate functionality
putty.exe but has some kind of malicious
backdoor installed in it as well
and so if we pull the strings from this
we are really pulling the strings from
the binary itself and that includes all
of the other strings that are associated
with the binary's normal operations and
so we can look through the strings of
this but it's very difficult to pick out
something that could be malicious out of
that unless we look very very hard i did
this intentionally it's a very good
skill to have as an analyst and a
triager to not get sucked into one
particular part of a methodology and not
beholden to a very rigid set of
methodologies so i threw you a slight
slight curveball with this one i hope
you don't mind i hope you were able to
kind of think through it and reason
through it but in any case when we do
have the strings output we can look
through it but there's not a whole lot
going on and even later once you have
completed this challenge and you look
back with the strings that you're able
to find there's really not a whole lot
of correlation to be had
so maybe no luck on the strings output
that could be a dead end or if there is
some information in here there's just
too much to sort through there's too
much to try to figure out so there's got
to be better ways to ascertain our
information and as an analyst it's a
very critical skill to understand when
the time is right to move away from one
part of a methodology in favor of
another one
now if we look at the imports we could
either use pe view or pe studio which
we're already in here and we can go
right over to the imports and sort by
the block list here again and again we
suffer kind of from the same problem now
there are lots of different apis that
are imported in this in this program and
putty makes use of a lot of these
different apis for its intended actual
functionality so it may be
tempting to say delete file a or
reg key create reg key delete oh that
must be malicious and even though pe
studio identifies it on the block list
that doesn't necessarily mean that it is
in fact malicious i know for a fact that
if you put your credentials into putty
and it saves them it actually saves them
in the registry now whether that's opsec
safe or not that's another discussion
but the legitimate functionality of the
program makes use of these imports and
the same thing can be said for map view
of file and write file and shell execute
a all of these look like they may be
malicious but in fact are part of the
normal functionality of putty and that's
another point to consider that as an
analyst if if someone comes to you with
a program or an executable or a script
that they think is malicious you'll have
to make the determination if those parts
of that program are in fact malicious or
not and that can be very difficult to
determine so as for an iet analysis
we're still kind of stuck in the same
place that we were when we pulled the
strings and that is to say there may be
some information in here but it's just
too much to kind of effectively sort
through so
the real long and short of it is that
the static analysis of this challenge
binary gets us a little bit of
information but really not enough to go
off of and so one of the most important
parts is that moving to the basic
dynamic analysis of this binary is very
very important to be able to tell what
it's actually doing so we'll close out
of all this we'll get right back to our
desktop
and we will start our basic dynamic
analysis portion of the questions so the
first question asks us to describe the
initial detonation and so if we double
click on putty we in fact do get the
normal putty window here and ostensibly
we could put in anything we want we
could do 127.0.0.1
on port 22 and try to open that up and
it looks like putty is actually
functioning as normal and of course
there's no listening ssh on the local
host so it's going to fail but it looks
like this is just putty as it regularly
operates but if you double click this
again you do see it flash for just a
moment there you do see that there was a
blue window that appears as well if you
read the readme of the challenge binary
that was one of the details that was
mentioned to you by the ir team and so
that is probably something that we want
to investigate so let's start there
after initial detonation we have a blue
window that pops up and just normal
putty so we can annotate that now from
the host space indicator perspective
what is the main payload that is
initiated at detonation and what tools
can you use to identify this so with the
blue window that pops up we can maybe
take a couple of guesses as to what that
might be and one thing that comes to
mind is maybe that's powershell.exe
powershell.exe opens with a blue window
by default
and so what we can do is go to procmon
so we will open up procmon and i'll
bring it right down here and remember we
know the name of the executable so we
have something that we can filter on
just reset if there are any filter
criteria in there and we'll go ahead and
do process name contains putty
now let's go ahead and run this and we
will get a whole bunch of results but at
this point we do have a process id for
putty.exe
so why don't we take that process id and
filter on that as well and we'll use
that as the parent pid so the parent pit
in this case in my case is 4716 so i'll
put in 4716 and i will add that as
criteria
and then we'll have to filter off the
process name because putty is not going
to be its own parent process
but when we filter off that we actually
have the for the very first thing that
we can see here is probably one of the
most interesting parts of this entire
analysis and what we have is a gigantic
powershell one-liner
we see powershell running from the
command line with a hidden window and a
non-interactive window it's bypassing
the execution policy and if we go into
this one more time we can actually pull
out the script block that it's using and
i'll make this a little bit bigger so we
can see it a little bit more
powershell is creating a new object to
be able to handle a gzip stream so
that's commonly used in file compression
now one thing we can do is we can take
this whole block copy the whole thing
and we'll have to clean it up a little
bit so it might be a little bit easier
to maneuver around in something like
codewriter here
and we can just clean this up so we can
parse it out we have the powershell.exe
right here and then this is where the
script block starts
and what we can do is see this gigantic
base64 string which is converted from
base64 and given to the compression
object and so one thing that we can do
is grab this entire thing all the way
down to the two equal signs that's down
here
and we'll ctrl c copy that
and we can go over to remnux and we will
do an echo with two quotes we'll throw
that base64 blob right into the echo
here and we'll do two things here we
will pipe this
to
base64-d and we're going to redirect
that to a file and we don't quite know
what that file type is going to be but
remember that we saw the compression
object so we we assume that it's going
to be some kind of compressed file like
a zip file or a 7-zip and so if we use
the file utility against out
we see that it's a gzip compressed data
so why don't we open up the file browser
on remnux and we find out right here and
we can do extract here
and if we open this up we actually get
the full plain text decompressed and
decoded version of the payload that's
running when this payload spawns
and this can be incredibly telling so
this is kind of like a bonus because now
i didn't quite teach all of that in the
course but it just goes to show you that
there's always going to be more data
available to you than maybe you
initially think so that's just a neat
little thing that you can do don't worry
if you didn't find that treat that kind
of like a bonus
and now you know you can take the base64
encoded version of that and decompress
it and write it to a file and you have
the full plain text of the download and
execute cradle that is used in this but
let's say you did not make it that far
so to answer that question you can say
that the main payload at detonation is a
powershell one-liner that is running
some kind of base64 encoded and
compressed payload and remember it's
always okay to say i don't quite know
what this is doing but we do have that
as a data point now it's always okay to
say i found this and i'm not sure what
it's doing i need to research it more so
just as an aside there
so
we need to figure out the dns record
that is queried at detonation and so
what we can do for that is we can break
out something like wireshark
and make sure that we have wireshark up
and running there are also host based
indicators that we can use for this one
as well
and let's exit out of all of our putty
sessions and one more time we will open
up the putty session and see if we can
get any kind of information off the dns
queries and in fact we do we have this
dns standard query to a text record of
bonus two and let me open this up so we
can see it easier bonus two dot
corporate bonus application dot local
now this does not resolve at this point
because we don't have inet sim up and
running and we don't have any kind of
handler and response to this dns request
so what we would need to do
is we'll head right over to inet sim we
can get rid of that momentarily and we
can fire up i net sim
fire that up and of course always you're
going to want to check to make sure that
your internet simulation capability is
up and running so type in google.com and
you should get to the default init sim
page now that we have set up the
internet simulation capability this dns
record should resolve to something and
we're not quite sure what it's going to
do at this point
but we're going to go ahead and run this
one more time and let's see let's scroll
down a little bit more and see if we can
find some of the tcp traffic associated
with it
so from following the initial request
and response from dns to bonus to
corporate bonusapplication.local
we then have some tcp back and forth and
depending on how many times you've done
this you may see something in wireshark
that's a little unique to
setting up malware labs in general you
may see some spurious re-transmissions
this essentially means that wireshark
has seen these packets before and is
going to drop them and treat them like
they are not
pertinent what is still very interesting
here is the port number
and so this is communicating from
ostensibly an ephemeral port somewhere
and it's going to eight four four three
so we can imagine this may be our
callback port and to check that we can
take a look at something like tcp view
and so we will open up tcp view
and so if you filter on powershell and
you run it you do have to look pretty
quickly but there is in fact a
powershell going to remote port 8443
right there and it did just disappear
now if you missed that you can just do
that a couple different times and that
it will repeat its results so powershell
is sending a request to the remote port
of 8443
so it appears like this is setting up
some kind of remote communication and
we're not quite sure what that might be
so we do have the dns record and the
callback port number at detonation now
the callback protocol is in fact https
the interesting thing about this is that
we won't be able to initiate a callback
with this payload because we don't have
an x509 certification to be able to
answer and respond to the client hello
coming from the tls transaction we could
in fact try to do
that same trick that we've done before
in which we'll open up a commander
prompt we'll run it as administrator
and we'll drill all the way down to the
hosts file and change the host file to
the local host so i'm just going to do
that real quick and then fast forward to
when that is done all right so i have
set that up that the bonus two dot
corporate bonus application dot local is
pointing at the local host and we'll
save and we'll exit out of the host file
and for good measure i'm going to do an
ipconfig slash flush
dns to flush out the dns cache
now if we stop wireshark and start it up
one more time
now we will stop wireshark and now all
pertinent traffic is going to be headed
to the np cap loopback adapter so go
ahead and stop the listening session of
wireshark that you were doing and go
over to the npcap loopback adapter and
if we run this one more time we should
then see
response and request coming from the
host so that's good now the second part
of our little trick here to trick the
binary into connecting to us was to host
an ncat session on the listening port so
nvlp8443
in this instance which we know from
these transmission requests
and the unfortunate thing is that if we
fire this up and we launch putty and we
try to initiate a callback we're going
to get garbled junk now why does this
happen
so if we take a look at the wireshark
output we actually see why this takes
place
the first thing that happens is a tcp
initiate connect and which is responded
with the tls client hello now this is
the first part of the tls handshake and
it sets up the certificates that are
used to encrypt communication during tls
and https now unless we have a
legitimate tls certification to be able
to present when this happens we will not
be able to complete this transaction so
what we could do is try to do a who am i
here or something like that but that's
not going to work and so try as we might
unless we happen to have a tls
certification on hand we probably will
not be able to get a true reverse shell
spawned on our local host so
unfortunately that is the case
but we can in fact take this as an
indicator as well as put it in the
report and that wraps up the silly putty
challenge the final thing that i would
want to say is that the way that i
created this was actually via metasploit
and so if you happen to have a kali
linux machine on you and can put it into
the lab environment i will leave it as
an exercise to the viewer to find the
metasploit module that i used for this
and try to actually spawn a reverse
shell that will connect when you use
this putty.exe what you're going to need
is a little bit of the host file
manipulation to send it to cali what you
need to do is study the type of
powershell reverse shell that's used
here and set up something in metasploit
to catch that shell and spawn it and so
i will leave it as an exercise to the
viewer good luck with that if you so
choose to do it but if you decide not to
do that fantastic job with the challenge
i hope that you learned something and
we're able to put your skills to the
test so great job and we're going to
move on to the advanced sections of
static and dynamic analysis in this
course
so hang on tight because here goes
nothing meet me in the next video and
i'll see you there
all right my friends now we have come to
this point in the course in which we are
talking about the most technical of the
subjects that we will cover in this
course we are talking about advanced
analysis
now i want to start this off right
before we get any further it's worth
mentioning that this is probably the
most technical subject that we will be
covering in this course how this subject
relates to malware analysis but even how
it relates to cyber security and even
computer science in general there is so
much to this topic
that you can spend your entire career
getting really really good at the very
specific things that are covered by this
and now i want to make sure that we
measure this and scope this well because
my intention for this course is not to
make you the absolute master ninja of
the world when it comes to advanced
analysis assembly debugging decompiling
and all of that
what i want to set out to do in this
course is provide
an introduction
that is well measured
for the beginner audience
and so no course on malware analysis
would be complete without some amount of
information about advanced analysis but
my intention is not to inundate you with
information and make it frustrating to
learn these concepts what i want to do
is keep this practical i want to keep it
well scoped and i want you to walk away
with a few key concepts and key skills
that i think will lay the foundation for
you to study more about this part of the
field so with that out of the way
what are we talking about when we say
advanced analysis well again
like we had in the basic analysis phase
we have two major parts to advanced
analysis we have static
and dynamic
now the methods for these phases of
analysis are what separate them from the
basic static and basic dynamic analysis
phases in the advanced static analysis
we will of course not be running the
binary as identified by the static
nomenclature but the tools and
methodologies that we'll be using are
very different from the basic phase when
we are performing advanced static
analysis
and for this course we will be looking
specifically at the windows operating
system and windows portable executables
what we're really looking at is the
assembly instructions of a malicious
program azim
and we will be loading malware into
special programs called decompilers
and disassemblers
and so we will start with the
packaged compiled program that is given
to us by the malware author and because
malware authors are never kind enough to
give us the source code of their
applications we will use special
programs to reverse engineer these
compiled executables and recreate
something that will look very close to
their original source code and that is
advanced static analysis we will be
looking at the assembly instructions of
an executable and loading it into a
decompiler and a disassembler to extract
insight about how this program was
written and its logical execution flow
now on the dynamic side dynamic analysis
of course means that we will be running
the binary but the way that we'll be
running the binary is very special
we will be loading this into a debugger
now the important thing about a debugger
in the context of malware analysis is
that when we load the binary in it
allows us complete control over the
execution instructions and so debuggers
are actually used for lots of different
things if you are a software engineer
you'll use a debugger to see how your
program executes and maybe find problems
and and issues in it and of course
that's why it's called a debugger but
for a malware analysis perspective we're
going to be using the debugger to
investigate how the program executes and
have complete control over every single
instruction that's executed and between
these two phases we will uncover all
kinds of information about how this
binary was built how the logical program
flow is executed and what this binary
can do so before we begin let's talk
briefly about what assembly instructions
actually are and this may be one of the
most important concepts to understand
when we get into the advanced analysis
phase and the way i like to think about
this is that there are different levels
of computer languages there are things
that humans understand
and there are things that computers
understand
up here in the human realm we have the
high level languages these are things
that humans are familiar with like c c
plus plus python
other kinds of languages that have
evolved over the years to be human
readable now unless you've been coding
in something like c and c plus plus for
a while perhaps those don't really seem
very readable when we look at examples
of them they seem very cryptic and hard
to understand but they're actually very
abstracted
now when we talk about abstraction what
we mean is that there are very primitive
instructions and programming languages
that happen down here at the low level
things that are happening on the bare
metal of the central processing unit
and so abstraction is the idea that
humans don't really want to work with
all these ones and zeros all day so they
take patterns of zeros and ones and they
bring them up a level and they say okay
instead of a bunch of zeros and ones
that i have to code right on the bare
metal of the operating system because
who wants to do that i'm going to write
these very very low level instructions
like move
jump
xor
and those instructions are going to
represent the different patterns of
these ones and zeros so that i could
write a program in this and the computer
can understand it but i can work with it
a little more effectively
now as time went on we took these lower
level languages and abstracted them up
and up and up and up until we finally
had things that looked like human
language main
hello
world
now to us that looks a lot more readable
than move jump xor and a bunch of ones
and zeros and so that is the concept of
abstraction in action now when we think
about the assembly language what the
malware author will start with is the
high-level source code so they will
write a main program
and they will write a method that does
do evil
stuff
and the program will be written to do
whatever the malware is designed to do
when the malware author wants to package
that up into a program that can be
double clicked and executed by the
central processing unit they will use a
specific piece of software called a
compiler
now the compiler will take this human
language
syntax up here
and it will say all right i understand
both the human side of this programming
language and i know how to translate
that to something that the computer will
understand as well so what it does is it
takes these human words up here and it
translates them into patterns of bits
and bytes
that the computer can understand and so
when the operating system wants to
execute this program the compiler is the
thing that has put the human language
into form that the processor will
understand so when a program is compiled
it is brought from a high-level language
all the way down into the lowest
possible level language that there is
now where does assembly come into this
so assembly think of it as one level of
abstraction up from the lowest possible
language so assembly lives right about
here
and assembly language is the human
readable
cpu instruction
set
now what does that mean
so instead of kind of ones and zeros and
bits and bytes that are all the way down
here on the bare metal of the cpu the
assembly language will take the patterns
of those bits and bytes and translate
them into just a little bit more human
readable form and so assembly languages
look a little bit more like this move
e d x
e a x and we'll talk about what that
means here in a bit
test
e a x
e a x and then maybe something like j
and e
and then maybe like
a memory
location
now this may seem a little cryptic at
first and admittedly this is kind of the
crux of the issue when it comes to
teaching assembly is that it can be very
cryptic and kind of difficult to
understand but what i will say is that
language precedes understanding the more
that you kind of work with assembly the
more you'll start to be able to sight
read and manipulate these kinds of
instructions but the point is not to
understand assembly right now the point
is that assembly lives somewhere between
high level languages and the lowest
possible level languages and more
importantly for malware analysis when we
are given an executable that's nice and
packed up like this box
malware author is going to leave us a
nice packaged executable that just has a
bunch of cpu instructions
and we will not really be able to
understand those but what we can do is
use a disassembler
and translate those instructions into
things that we can understand
now i think that's enough explanation
for right now so let's move into the lab
and we'll actually see what this looks
like from a practical standpoint
all right so we've been talking a lot of
theory a little too much theory if you
ask me let's get practical here so i'd
like you to open up to the lab section
go ahead and find the 2-1 advanced
static analysis and we'll be working
with this first program right here
dropper.downloadfromurl.exe.mals
now if
dropper.download from url seems familiar
that's because it is if we open up the
readme
hi analyst this is a sample from earlier
your initial analysis identified that
this binary has the capability to
download a file from a remote host and
copy it to the file system open this
sample up in a decompiler disassembler
and take a closer look make sure to pay
attention to the api calls and how
they're being performed so to start our
advanced static analysis we're actually
revisiting a binary from earlier in the
course if we go back to the labs and we
go back up to the basic static analysis
one of the first ones that we worked
with was this
malware.unknown.exe.mals right here and
so this is the exact same sample and i
wanted to provide something that you'd
be familiar with remember that this
binary will take a url as an argument
and it will attempt to reach out to a
website and if something is there then
it will execute and if something is not
there it will delete itself from disk
with that having been said let's use
this as the first example of our
advanced static analysis we can bring
this right out to the desktop and we
don't actually need to arm this what we
will be doing is going to a program
called cutter
c-u-t-t-e-r you can go ahead and search
for that in the start menu
and so i've already opened it up here
but you probably will not have that so
once cutter opens up you can go to the
select button right here and navigate to
your desktop and find the sample that
we'll be working with
dropper.downloadfromurl.exe.mals
once that has been selected we can go
ahead and open this we will keep the
analysis to enabled and keep it at the
auto analysis or aaa level we don't need
to do any advanced options and we'll hit
ok now the first thing that you'll see
when you open up cutter is the dashboard
and the dashboard will have a lot of
familiar information it will identify
the architecture of the executable it
will identify some other things that
we've already found the md5 sum and the
sha 1 and shaw 256 hashes
and so there's lots of useful
information here but it's nothing that
we haven't really already seen now where
the disassembler slash d compiler shines
is over here we have a list of all of
the called functions that are in the
program and so what we'll do is we'll
double click on the entry point and we
will be brought to this screen now i
know that this looks very busy
and if you're looking at this and it
looks like a foreign language well i
mean it really is at this point if you
don't know what you're looking at you're
looking right now at the innards of an
executable program this is assembly
language it's the closest you can get to
the metal of the cpu without being an
actual electrical signal which is super
fascinating to me and one of the things
i love about assembly as kind of cryptic
and and hard to understand as it is
there's nothing to hide when you write
and read an assembly there's no
abstraction layers that somebody can
hide behind this is the absolute truth
of what's going on
on the operating system when a program
is called now this is some fascinating
stuff but i don't think we're quite at
the level that we can really understand
what's going on here but what i want to
do
is talk a little bit about how a program
is executed so when a program is written
there will be a central function called
the main function and that's the
function or method from which all other
functions or methods are run
and the disassembler will identify where
that main function is and so if we
double click on that we can actually
find where in the program per the
assembly instructions where the main
function is located and now we're
starting to kind of get acquainted with
how to use a disassembler and read
what's going on in here because remember
if you remember that binary from the the
early phases of basic static analysis we
actually start to see some things that
are familiar so we see an instruction to
push a string right here and see user's
public documents and then cr433101.exe
if you recall your notes from the basic
static analysis portion when we looked
at this program during basic static
analysis remember that this is actually
writing something to that location and
it's interesting that it shows up in the
disassembled output as a string
so again this information can be pretty
cryptic and hard to understand so i'd
like to introduce you to my favorite
feature in this tool which is the graph
function and the graph function is
incredibly helpful because it kind of
graphs out the logical flow of the
program now recall from the basic static
analysis example remember that this
program tries to connect to a specified
web url
and if that connection takes place it
will download something from that url
and store it in the c user's public
directory and then run that process and
on the other side of that if the program
tries to reach out to that url and
there's nothing there it will just
delete itself from disk and so we don't
even have to understand a whole lot
about assembly yet to understand that
that's exactly what's happening here
from the main function and so we see
some strings that we identify we see
that ssl dot data manager help desk
bros.local to favicon.ico that is stored
in the binary as a string somewhere that
string gets brought out to be used and
then it will call the api function of
url downloads a file remember that this
was the very api that we saw in the body
of the program during static analysis
and then the results of that call are
actually loaded into a special place in
the memory of the computer called the
eax the extended accumulator register
and we'll go a little more in depth on
that when we get to the advanced dynamic
analysis but in any case it tests the
contents of this location of memory and
then if the contents are one thing it
will jump to a location in memory and if
the contents are another thing it'll
jump to another location now we read
this as jump if not equal and then a
memory location and we see that the
memory location number right here
matches exactly the next graph block on
the graph so recall that we observe the
download from url function if it returns
something as valid it would execute the
rest of the program and if it didn't
return something as valid it would
delete itself from disk and we can
follow that because if we test the
contents of this memory register and
it's not zero it will go one way and if
it is zero it will go another way
and so without getting too far in the
weeds with all of these instructions and
what they mean this is a really good way
to visualize how a program is executing
and go to the graph representation of
how these instructions are actually
functioning because these instructions
are the very very low level very
primitive representation of the kind of
just big moving parts of the program we
will attempt to access a web url and if
we are able to access that web url we
will execute the rest of the program and
if not we will delete ourselves from
disk and so this is the principal use of
a decompiler disassembler it tells us a
lot of information about how the program
is executed from the very low assembly
level so right now we're in the graph
representation of the main method but if
we go down here to the decompiler
the d compiler will take the assembly
information of this binary and attempt
to recreate as close to the original
source code as possible and remember
that's just a function of the fact that
the assembly is a further abstraction of
the lowest possible level of the machine
code so what's stopping us from taking
that assembly information and
extrapolating it up to what could be the
original source code or at least
something similar and again there's a
lot of information here but we can start
to pick out strings and bits of
information that look interesting so if
we see this url download to file w is
the actual direct api call that we're
making to this ssl that manager help
deskpros.localfavicon.ico
so that is the exact parameter that's
passed to the url download to file api
call and we're able to recreate what's
close to the original source code of the
application now i'll leave it as an
exercise to the viewer look around a
little bit more in this application and
see if you can find some of the strings
that we pulled from the basic static
analysis let's see if you can find some
of the urls that you found in the basic
dynamic analysis and then let's see if
you can trace into this program from the
main method right here and see just the
couple of function calls that can be
called from the main method when you
look into that so go ahead and give that
a shot and meet me in the next video
all right now if you're joining me from
the last video we just took a look we
loaded up a binary into cutter and we
took a look at kind of the inside the
innards of the binary and looked at a
bunch of cryptic things that you know
maybe we didn't understand while we were
looking at them
and that's okay this part of the course
is all about building pattern
recognition right so the more that you
work with assembly at the at the low
level the more you'll start to see
patterns and the more you'll start to
see things and say hey i recognize that
i know what that does
now i want to cover a few of the x86
instructions and things at the assembly
level that will be very important to
understand this is not going to be an
exhaustive list by any means
but i do hope to clarify just a couple
of the things that we might be looking
at when we take a look at the inside of
a binary like that all right so for a
binary to execute in the x86
architectures there are really
three things and this is a bit of a
simplification but there are really
three things that we need to think about
for any of this to take place in the
first place we have the cpu instructions
we have the memory registers and down
here we have the stack and perhaps
you've heard of one or two or maybe even
three of these so we're going to cover
briefly what these are and what they do
and then i'm going to show you in a
practical sense uh what they kind of
look like at the assembly level all
right so first things first left side
cpu instructions like i've said before
when you write a high level language and
you say if something like this happens
do something like this and that's how
the program executes when the compiler
translates that into something that the
cpu can understand it needs to be
translated into
cpu instructions from a high level there
are about three types of cpu
instructions that we will cover there
are arithmetic instructions like
subtract there are data movement
instructions like move and then there
are control flow instructions like jump
so let's take a look at some of these so
we have things like m
o v j
m
p and then s
u
b move jump sub so those kind of
represent the three different types of
instructions in the instruction set now
the x86 architecture is little endian
which means that data is written
unintuitively from the right to the left
and so when you take a look at an
instruction in the x86 architecture the
instruction is going to come first and
then the destination is going to be the
next thing so when you see something
like move e d
x
comma
e a
x think that the instruction comes first
the source comes third and the
destination comes second so it's a
little bit out of order it's a little
strange so it's something you kind of
have to get used to that it's move eax
into edx not move edx into eax and we'll
talk about what eax and edx are here in
a second all right so we've got a
movement instruction so if you want to
move data around while the binary is
running you'll use something like the
movement instruction now the jump
instruction is a bit like if you need
the program to jump to a certain
location or another one so this is very
useful in logical branching so a jump
instruction might live right about here
and it will say jump to and then it will
have a memory location right here and so
if
something happens if there is a
conditional that is met you can use the
jump instruction to go to one part of
the program or another part of the
program now there are several iterations
of the jump instruction and there are
ways that the jump instruction will
function so we can look at something
like a j n z instruction which we read
as jump if not zero and so this happens
a lot in returning true or false values
and so we will go to one part of the
program if the value is zero meaning
that the thing that we are looking at
returned true
or if the value is false which would
return a one so if it's zero go this way
and if it's one go this way so jump if
not zero
now the arithmetic operations work
pretty much exactly how you would
imagine them to work you can subtract
numbers from other numbers you could
even subtract locations in memory from a
certain memory location we'll talk a
little bit more about that when we get
to the stack portion now there are also
some very important instructions here in
the way of push and pop now push and pop
are how we interact with the stack so
the stack is a special place in memory
that is kind of like a place that you
can hold information while you need to
access that information quickly so
it has been said that the stack grows
downwards so the stack will be assigned
a certain location in memory and the top
of the stack is going to be the highest
possible location and as the stack grows
it grows downward
so as things are added to the stack they
are added to lower addresses
so let's say that we want to call a
function and we need to set up the
variables of that function we will use
the push instruction to take those
variables and put them here into the
stack so we will push 0 we will push a
string and we will push the number 12.
and so we will push those onto the stack
and then there will be
memory assignments that have zero
that have the string that we pushed
and we'll have the number 12.
now notice how the stack is growing
downward so the first variable that gets
assigned to the stack is assigned to the
highest possible location on the stack
and then every other variable that gets
pushed onto the stack is assigned a
lower memory address now in reverse we
have the pop instruction now once we are
done with whatever we're doing on the
stack with these variables we can pop
them
off of the stack and so if we pop
the stack we remove the lowest part of
the stack that has a piece of
information on it and then we can pop
pop pop to get these variables off of
the stack and return the stack to the
way that it was before we move those
variables onto it and finally i'd like
to cover the call and the ret
instructions call
and ret
so the call and the ret instructions are
super important when we talk about the
subroutines and functions that the
program runs now let's think about how
this works with the special method that
we already covered the main method every
other function in the program is going
to be called from the main method so we
start at the main method and we trace
into the different functions in the
program so we had a function that was
check url
and so we will call the check url
function so we will call
check url from the main method and the
check url function will do whatever it
was designed to do
and then it will
return
and tells the world what it came up with
as a result
so if we think about the main method
as kind of like this arrow that's moving
forward
when the main method starts it will set
up a bunch of variables and then it will
call a function and the function will do
something and return to the main method
and then the main method kind of resumes
from right where it left off all right
so how about a metaphor for this
all right so let's say that i have
decided that i'm going to sit down and
start recording and i'm super excited
and super focused about it so the husky
program has entered its main method so
we're going to start up here
main
and we're rolling we're having a good
time we're writing course material but
then my partner emily comes in and she
says hey can you go to the store and
pick up a dozen eggs so right here at
this point when i break from the main
method i have called
the pick up
eggs
function
and so she has told me hey pick up a
dozen eggs and so i will pass in the 12
argument into pick up eggs now that's
important because that argument needs to
go somewhere so when the pickup eggs
function is called that variable of 12
for how many eggs i need to pick up is
moved on to the stack so we've got a
stack over here and we have put 12 onto
the top of the stack so i say okay great
so i go out to the store and i'm about
to pick up some eggs so i'm going here
and i'm traveling to the store but right
about here while i'm passing the store i
look up and i see that there is a cat in
a tree all right so at this point i am
actually going to break from the pickup
eggs routine and i'm going to call
another routine of save
cat
from
tree
and so actually i will break from this
routine and go into another routine and
at this point i am now two routines in
from the main call and so i always have
to keep track of what i was doing before
i split out to do the other part of the
function so while i'm saving the cat i
don't forget the fact that i'm out to
actually pick up eggs in the first place
and so i need to be able to go back to
wherever that pickup eggs function is
once i'm done with the save cat from
tree function and the way i do that is i
save the location of pickup eggs in the
e b p the extended base pointer
and so i will say okay because i need to
know how to get back to pick up eggs i
will save the location of pickup eggs in
the extended base pointer and i'll
return to that once i'm done saving the
cat from the tree
so let's say that i saved the cat from
the tree and all is right in the world
and once i'm done with saving the cat
from the tree i will return to the
pickup eggs function
right here and then i go to the store i
pick up the eggs i bring them back home
and then i am back into the main method
and once i resume in the main method i
can continue to do whatever else i
needed to do
and now the final thing that i want to
talk about here are the memory registers
now i want you to think the memory
registers a little bit like this
now i am a child of the 90s so
this is a good metaphor for me but if
you're not familiar with what you're
looking at that i just drew don't worry
about it this is a vcr tape
so a vcr tape was back in the old days
how you would watch a movie or something
like that and so the vcr tape had this
kind of ribbon on the inside of it and
the ribbon represented all of the data
of the movie with the audio and the
video that needed to be put onto the
screen for you to watch the movie and so
when i was a kid i would like grab the
ribbon from the inside and like pull it
out and like you know it would it would
kind of spiral out like this um so the
point is that there was tons of data
written onto this ribbon and it was kind
of this continual stream the two little
gears in the center here would rotate
and there was a little thing right in
the middle of the vcr right here called
the read head so what was the read
head's job well as the ribbon of the vcr
moved over the read head which we can
visualize kind of like this it would
take and remember there's tons of data
in here there's audio and visual and
stuff so as the tape moved this way over
the read head the read head's job was to
take the data that was on the magnetic
tape and actually display it to the
video and so i want you to think of the
memory registers a little bit like this
read head there are a bunch of memory
registers and all of them serve
different purposes but they all hold and
handle different parts of the data in
the binary at runtime now let's cover
the important ones we've already
mentioned a few of them we have the e
a
x which is the accumulator register the
e d x which is the data register the e b
x which is the base register
and then the e s p the extended stack
pointer the e
b
p the extended base pointer and then the
e
i p the extended instruction pointer and
now those of you that are familiar with
how to perform a buffer overflow may
recognize a few of these if you don't
recognize these don't worry about it at
any given point these memory registers
have a reading in them of a particular
memory address or location or value or
something like that and so the
interaction between the cpu instructions
and the stack is facilitated by these
memory registers if you want to have an
instruction executed it will be read in
by the memory registers and then brought
onto the stack if need be so that was a
bit of a crash course in assembly
instructions and what happens at the low
level when a program executes now this
is all a lot of information if you
didn't quite latch onto it first don't
worry about it this stuff takes time
remember as i said at the outset of this
video this is all about pattern
recognition so the more that you work
with this the more that you'll start to
recognize these patterns as they occur
alright so let's get back into the lab
and we will take a look at what this
looks like in the technical sense
all right and we're back in the labs now
remember we are inside cutter and we
have opened up
dropper.downloadfromurl.exe
now we opened this up before and i want
to just revisit this because now that we
have some of the terms clarified maybe
we can start to unravel some of the
functionality when we look at the
assembly level instructions of this
binary and again the point here is not
to walk away having known every single
little piece bit and byte of this
program remember to just take the key
functionality away we don't need to get
lost in the minutia here we just need to
see the big moving parts and i hope now
that we've covered the assembly cpu
instructions the stack and the memory
registers some of this should make a
little bit more sense so if you have not
done so already go back to the main
function so you can search for main down
here in the search bar and click on the
main function and if you're in the
disassembly output go ahead and move
over to the graph of the main function
alright so follow with me we're going to
step through the main function as we see
it in the assembly the first thing that
we see is that int main
with int arg c char star argv and char
envp now this is super cryptic and if
you don't code in c you might not know
what this is but when you set up the
main method the main method is always
past two arguments implicitly the arg
for count arg c and the arg for vector
are v and so what this means is that if
there are any arguments to pass into the
program at start they need somewhere to
be passed so they're passed into main
and arg c is the count the number of the
arguments so this could be like if
there's like an argument for source and
destination argc could be two and then
the arg v is the strings themselves that
are passed in as arguments so that is
the setup of that we have a whole bunch
of variables that are declared that we
don't necessarily know what they are at
this point remember we're reverse
engineering we don't have all of the
source code in front of us so when we
see variables like this we might not
care a lot to know what they are right
at the start we just might have to
unravel it and see where they go now we
push remember the push instruction we
push the value of the extended base
pointer onto the stack and remember that
if we ever want to get back to the main
function let's say that we call a bunch
of other functions from the main
function if we ever want to get back we
need to have the value of the base
pointer because if we don't have the
value of the base pointer we won't know
where to return to after we're out of
each of those other functions so we push
the value of the base pointer onto the
stack and say let's go ahead and save
that so that we know where to return to
next we do a few other things we move
the value of the stack pointer to be the
new base pointer and when you see this
push ebp move esp into ebp this is a
very common setup for calling a function
you're gonna see that a lot when you see
that calling convention and you start to
recognize it you're going to start to
see it everywhere so just understand
that this push ebp move esp into ebp is
just a way to set up a function call now
we do some other stuff that we don't
necessarily care about at this point but
then we get to this right here we're
going to push push push push push push 0
push 0 push 0 push 0 push string mozilla
5.0 hmm interesting okay so
after all of these are pushed to the
stack and we might not necessarily know
what these are yet we have a call to the
d word of internet open w
and this is an api call now recall from
the basic static portion when we looked
at this binary that this internet open w
is an api call that you're asking the
operating system hey i would actually
like to see if there is a resource at
this internet address so what you need
to do for that is pass it in some api
parameters one of those parameters is
going to be the user agent which we see
right here as
string.mozilla 5.0
and cutter actually does us a favor if
we want to go see where that is in the
program it gives us the memory offset
location right here and so we can
actually copy that and take a look at
that but for right now understand that
we are calling the api call and having
passed in these parameters now remember
if you don't remember how that function
actually operates all we need to do is
google it but let's take a look at
something here how many arguments are
pushed onto the stack right before this
api call is made one two three four five
now let's take the documentation of
internet open a the api call
and let's see how many arguments are
passed in one two three four five
interesting so we have a perfect match
up of the amount of data that's pushed
onto the stack and the amount of
arguments that need to be passed into
the api call for it to take place and
notice how only one of these has an
actual value the rest of these are zero
but the first one right here is lpsz
agent or the user agent pointer to the
null terminated string that specifies
the name of the application or entity
calling the win inet functions we see
this a lot in network traffic when you
see
like a browser that's opening up to a
web page and the browser user agent will
say hello i am mozilla 5.0 or i am
google chrome now one thing to notice is
how these variables are pushed in we
have zero zero zero zero string mozilla
5.0 but over here in the parameters we
have the user agent and then access type
proxy proxy bypass and flags and so the
point that i'm making here is that the
arguments to the api call are actually
pushed in reverse so the first one goes
in last and the last one goes in first
and this is known as an lifo a last in
first out system and the stack works as
an lifo system remember that things are
pushed onto the stack and then more
things are pushed onto the stack and
then they have to be popped off of the
stack in reverse order to return all
right so we have reverse engineered our
first api call that we have in this
program we have five arguments that are
passed in pushed onto the stack and then
the api call is called next up we're
going to do some more movement of
variables and then we call to this
function right here
now we can double click to actually step
into this function this is getting a
little more down in the weeds from what
we probably want to do so let's actually
use the back button here and we're going
to just hang on to this for a second we
call some kind of function and then we
push more arguments onto the stack now
the first string that we see here is one
of the arguments that's passed in as the
path to see user's public documents and
then the name of the executable that's
downloaded from the url
and then the next argument that we see
is actually the place that it's
downloaded from and remember just like
we saw up here when we have one two
three four five and then a call to an
api we have the parameters pushed onto
the stack and then a call to an api url
download to file w and so this api call
is making use of the arguments that have
been pushed onto the stack to execute
and remember in this case we are
downloading something from a url finally
we test the contents of eax against
itself and we jump if not equal j and e
and remember how we specified that the
jump is going to take us to one location
or the other and so that's a roll up
we've revisited the first call that
comes off of the main function in
dropper.downloadfromurl.exe
i hope that clarified a few things so
the first thing we did was we looked in
this and we didn't necessarily know a
lot what was going on we covered some of
these terms and then we just reviewed
some of the functionality of the program
after covering some of the assembly
instructions and conventions
and again just to reiterate this is
always all about pattern recognition the
more that you work with assembly you're
going to identify these little bits and
bytes that look familiar and the more
you're going to build out that knowledge
so i think that's good for where we want
to leave it for download from url.exe
we're going to move on to the next video
in which we're going to take a look at a
process injector at the assembly level
and see if we can identify some of the
big moving parts of that program as well
so meet me in the next video and we'll
cover that
all right analysts we are continuing
with our advanced static analysis now
let's go ahead and move over to the
2-1 advanced static analysis lab and
we're going to go into
malware.stagex0.exe.net
and let's take a look at the readme real
quick analyst we got one take a look at
the sample in the zip folder it's
definitely a dropper program but we need
you to break out the decompiler and
debugger and take a closer look we know
that it's trying to spawn a reverse
shell and we got to call back
successfully to our fake listener but
we're wondering how it's actually
working to do that exactly anything you
can find will help us determine how it
got here and how it works the ir slash
re team okay fantastic so we'll put that
to the side and so in the lab directory
we're going to go to 2-1 advanced static
analysis and we've already worked with
dropper download from url so we're going
to go into malware.stage0.exe.mals
and in here we of course have the
sha-256 sum and the password.txt and the
readme as well alright so what we want
to do is open this up and we'll put in
our standard password of infected
and we'll bring this right out to the
desktop now of course we want to do our
full round of basic analysis before we
get into the disassembly and
decompilation of this binary so what
we're gonna do we're gonna pause the
video right here and i want you to do a
full round of basic analysis and find as
many iocs of this program as you can
possibly find and then once you're done
with that resume the video and i'll pick
up from the end of the basic static and
basic dynamic portion and we will use
those iocs to perform the follow-on
advanced static analysis so go ahead and
pause the video right here and we'll
pick it back up right here after we
complete our basic round of analysis so
pause the video here
all right analysts we are back and we
are going to cover the indicators of
compromise and some of the data points
from the initial phase of basic analysis
for
malware.stage0.exe and so i would like
to say if you didn't find these
indicators that's okay we're going to
cover them right now but just make sure
that you go back and take a good look at
your methodology and make sure that
you're doing all the correct things from
earlier in the course the fundamentals
are still very important from here on
out because the fundamentals and what we
find in the basic analysis phase is
really going to inform how we perform
the advanced analysis phases as well but
in any case what do we find about
malware.stagex0.exe so there are two
principal indicators of compromise that
we probably want to track down with this
piece of malware now the first one comes
in the form and we'll just move this
right up here the first one comes in the
form of a file that is written to the
file system that wasn't there in the
first place when we run
malware.stage0.exe there is another
executable that looks like it's unpacked
from the first binary which is where
fault.exe that's w-e-r-f-l-t
dot exe now the second indicator that we
pick up and we'll have to look at tcp
view real fast to see this one is that
where fault
w-e-r-f-a-u-l-t actually spawns an open
connection for a brief moment on remote
port 8443
on the local host so it's opening up a
connection or at least attempting to
open up a connection on the local host
on port 8443 and that was
w-e-r-f-a-u-l-t so where
f-a-u-l-t dot exe so if we run this one
more time we might be able to see that
and there is the connection right there
from where fault.exe on the localhost so
that begs the question what is where
fault this one right here and then what
is this one right here which looks to be
like a misspelling of where fault so the
actual program w-e-r-f-a-u-l-t
is actually a built-in binary in windows
and generally when you have errors in a
program where fault will pop up and it
will say would you like to send more
information to microsoft about this so
if your computer crashes or some kind of
exception is hit where fault will
collect information about that and can
be used for further debugging purposes
but this right here is not where
fault.exe there's a misspelling here and
this is unpacked from the original
binary that we run so if we run this one
more time it appears at runtime so lots
of interesting information because we
have a network signature something's
trying to connect to the local host on
port 8443 and then we have a host base
indicator of a file that's unpacked at
runtime so what we want to do now is
we'll take this wirefold.exe we'll move
that right out to the desktop and we're
going to perform advanced static
analysis on this so let's open up cutter
again
so we will search for cutter and open
this up and then we will open up and go
to the desktop directory and we'll load
in wherefault.exe
and leave all of this default we'll do
the standard level of analysis for this
binary and we'll open this up
in cutter now we are immediately brought
to the entry point you may be on the
disassembler at this point but
of course go right over to the graph
view for maybe a bit of an easier view
and so what we need to do is step
through this program and identify the
key characteristics of what this might
be doing now remember that when the
operating system hands control of
execution over to the binary it will
always start at the main function so all
of the interesting parts of this binary
are going to be located from the main
function and any functions that take
place off of the main function
and so when we inspect what we see in
the main function during the advanced
static analysis phase what we come up
with is actually the classic pattern for
a create remote thread process injection
so let's break this down now process
injection is a common ttp for malicious
actors and effectively what happens is
that they will be able to open up
another process that's running on the
host and inject code right into that
process and have that code run inside
the process as if it was part of that
program in the first place and this is a
common evasion technique because the
code that runs inside the process has
all of the attributes and metadata and
lives inside of that process in the
first place and so it's very common to
see shell code for like a c2 agent or a
reverse shell being injected into
another process and that's a way that it
can hide out and mask itself from
detection now truth be told today create
remote thread is not very stealthy and
that's because the defenders over time
have adapted to look for it but when we
open up the main function of
werefaults.exe
we see that this is the classic pattern
for a create remote thread injection so
let's step through it and see if we can
identify some key characteristics here
now as we step through this always
remember to keep it light keep it moving
and don't get too bogged down in some of
the details so of course with the main
method we're going to have some
arguments passed in so pay attention to
the arg underscore ch because this does
come into play and in fact at one point
in kind of the preamble here it's moved
into the register eax so we'll keep that
in mind we go through a little bit of
the preamble here and then eventually we
get to a call to the d word open process
now this is an api call so let's we can
actually hover over this right inside of
cutter and take a look so when we look
at the open process api call there are
one two three parameters here and
remember that the three things that are
pushed onto the stack right before that
are going to be the three parameters
that are used by the api call so from
start to finish there is a value of 1x
ffff which is the desired access level
one argument before that let's check we
have the inherit handle or not and we
are not inheriting a handle from the
parent process because this is a boolean
value of zero which means it is false
and then the final one here and if we
hover over that again the final one here
is a d word process id and that is the
contents of eax now where did we see eax
before it turns out that the value of
arg ch is passed into eax so you see
right here move d word arg ch into e a x
move dword rch into eax and then down
here eax is pushed onto the stack and so
what does this mean we are opening a
process and the parameters we're passing
in are saying give me all access to this
process and the process id is going to
be the argument passed into main so
argch ends up being the process id and
so as we move down we then get to the
move eax into edi instruction now
remember that eax was the process id of
the thing that is passed into main up
here as rch now basically this program
is given a process id it loads it into
eax it uses that to open up access to
the specified process that's been given
as an argument and then it takes that
same process id and loads it into the
edi register now it's basically just
holding on to that in the edi register
for right now because it's about to use
it again and that's going to be in the
virtual allocx api call so if we hover
over this we'll take a look and we see
that there is the first parameter that's
passed in is the h process the handle to
the process well basically what we're
doing is giving it the number of the pid
that we used in the open process phase
so we are requesting the handle to a
process to open it up to be able to
access it and do things inside of it and
then we're giving that to an api call
that's going to allocate memory inside
of that process now let's keep going and
we're going to move to our next api call
and work backwards from what we see so
we have another api call of write
process memory and what do we need for
this the first parameter that we need is
the handle to the process which is the
one that we've been using this whole
time which was passed in remember at the
start of the program we need a base
address we need the size of the buffer
and we need the number of bytes written
so let's take a look we look at edi
which has the contents of the process
handle remember that in eax we had the
process id and we're just loading that
right into edi right here and then we
use it again in this api call the esi
has the base address of this process and
the eax has something very special it's
got the lp buffer and if we count we
have one two three arguments from the
top and that's one two three arguments
is going to be the lp buffer now what in
this case is the buffer so we have to
scroll up a little bit to find that
because that's set up a little bit
earlier but now we might understand what
this could actually be doing and so
that's set up as a variable at the very
very top of the program so what does all
this mean well let's rewind a little bit
we are opening up a process which is
specified by the argument that's passed
into main we are allocating an area of
memory inside of this process with the
rights to be able to write into that
memory we are actually taking those
bytes from the lp buffer variable and
writing them into that process in the
section of memory that we've allocated
and the next api call here is going to
be the grand finale of create remote
thread and so if we go down to create
remote thread we see that it does have a
bunch of parameters being passed into
the api but there are really only two if
you look at the instructions here there
are really only two that are actually
pushed onto the stack for work so that
is the first parameter and the second
third fourth parameter so one and four
are the ones that we want to look at so
let's hover over create remote thread
and the first parameter is the handle to
the process which we've been working for
so the second third and fourth is going
to be the start address so the start
address is going to be where this thread
begins its execution and so the value
that's in esi currently is what we need
to look at because that's what this is
actually going to be executing if we
click on this it highlights where esi
was last used so we trace up a little
bit and we find push esi was used during
the write process memory section and
this actually ends up being the base
address of what was written into the
process so what we're saying is when you
create a remote thread you're going to
create a thread inside of a remote
process and i do that by handing it to
you from the arguments of the main
function and you're going to go to the
contents of esi right now which is the
lp base address so the base address of
the data that i've written in during the
virtual alloc x and write process memory
api calls
and so when all is said and done what is
the real
bottom line of what we're doing here we
start by handing this program a process
id it takes that process id and it opens
up that process with the level of access
required to actually be able to write
into that process
it then allocates a section of memory
with read write execute permissions it
then writes the contents of a specified
variable into the allocated memory and
finally it starts a thread in that
remote process and tells the thread go
to this address which is the address
that we allocated during the write
process memory call and execute whatever
is there and so what ends up happening
is that this is a common way for shell
code to be injected into a remote
process because you can write your shell
code into the body of the program and
then copy those bytes into the remote
process write them into memory and then
execute them with a new thread via the
create remote thread api
so we'll actually minimize cutter here
and now i want to show this with one of
the really really powerful tools that we
can use during dynamic analysis we're
going to go down here and look up
process hacker 2 and so just type in
process hacker 2 and i'll show you kind
of how this works in real time so
remember that where fault.exe is calling
out to the local host on port 8443 so we
can open up a commander prompt and we'll
get a netcat listener up and running
with nvlp8443
so we will listen on all interfaces for
8443 and take a careful look at process
hacker
move this down a little bit and watch
what happens when we execute this
program we will execute the program and
immediately where fault.exe is spawned
in a suspended state so while that
spawns in a suspended state the rest of
the program is kicked off the pid of
wherefault.exe which in this case was
4000 is handed back to the unpacked
program werefolt.edu
and so when wordfault is executed it
takes the process id of wherefault.exe
which is 4000
and let's follow along it opens the
process up by passing it in the process
handle of 4000 and then it allocates an
area of memory inside of that process it
writes the bytes of the shell code that
it's using into that process and then it
creates a remote thread and executes the
shell code and we get a reverse shell
back so if we go over to process hacker
and we open up this where fault this is
a completely legitimate completely
normal application but if we go right up
here to the memory tab let's go ahead
and see if we can find our area of
allocated memory now remember i said
when this area of memory is allocated
it's allocated with full read write
executable permissions and that's going
to be very out of the normal for a
process like where fault.exe so if we go
up to the protection column here and we
sort this twice we can sort by all of
the different types of protection and
usually they're going to be read execute
permissions because that's like the
normal operation to have an area of
memory just have read and execute
sometimes they're read write just to
make sure that you can move data in and
out of memory as needed but there is one
in here sneaky sneaky that's read write
execute and if we go into the read write
executable section of where fault.exe we
see the bytes of our shellcode have been
written into this process so what i've
highlighted right there in the hex
output is the actual bytes of the shell
code and when this is run in memory by
the remote thread it spawns the reverse
shell over here now this is getting a
little more on the dynamic analysis side
but i think it illustrates the idea of
this create remote thread pattern of api
calls that we just saw in the static
analysis over in cutter so i'd like to
just take some time to take a look at
this and so that's it that is what a
basic create remote thread process
injector looks like from an assembly
level and if you followed along with me
thank you and great job that's a super
interesting thing to be able to look at
at the assembly level is a process
injector in action
all right and that is our module on
advanced static analysis now we're going
to move into the advanced dynamic
analysis section of this with all of the
knowledge that we've accumulated with
the previous section and we're going to
look at how we can combine all of the
different streams of information and
tools that we've been using during the
advanced dynamic analysis portion so
meet me in the next video
hey analyst all right we're back and we
will be finishing up our four phases of
analysis section with the final part
here we're going to put it all together
with advanced dynamic analysis
now the principal difference between
advanced dynamic and advanced static
analysis is that we will be running the
program that we're analyzing but
we will be running it inside of a very
special program this program is called a
debugger
and the debuggers that are built into
flare vm are available when you go to
the flare
directory right here
second folder down from the top is
debuggers and we can open that one up
and we have a few to choose from
and we will be working with these two at
the bottom here for this course we'll be
working with x32 debug and x64 debug
so let's go ahead and open up to x32
debug and just get comfortable inside of
the debugger terminal
so if we maximize this we can actually
just kind of resize the screens here and
we don't have any information in here
yet but once we load a program into this
debugger there will be plenty of
information to look at one thing i would
like to point out is that if we go up to
options we can go to theme and they do
in fact have a dark mode and that's what
i will be working with and you can also
go up to options and look at the
appearance settings and if you go over
to font you can actually make the fonts
a little bit bigger and i'll do that for
you guys so it's a little bit easier to
read and there we go so we still don't
have anything in the debugger yet but
let's talk a little bit about what a
debugger actually does
so when a program is run remember that
when you double click on an executable
the operating system says hey we need to
execute this program let's hand control
flow over to this program starting at
its entry point and have that program
perform all of the remember at this
point machine code instructions uh that
are required to run the program and then
return control back over to the
operating system
now that's what happens when you just
double click a program to run it now
when you load it into a debugger a
debugger acts as a broker between you
the end user and the operating system
while a program is running and so in
other words you will be able to have
complete control over every single
instruction that is actually completed
while you are debugging a program now
debuggers are not used just in malware
reverse engineering they are also used
in software engineering as well
and so a debugger can be very helpful to
step through the source code of your
program and see where your variables end
up and and maybe find some problems uh
with the control flow execution but we
are not doing that with source code
we're doing that with the assembly
instructions of a program so let's
actually go to the lab directory we'll
open up to labs and we'll go down to
advanced dynamic analysis and wouldn't
you know it we're using dropper download
from url.exe this is the same exact
sample that we used in basic analysis
and the same exact sample that we used
in advanced static analysis and we're
going to finally build on all of the
knowledge that we accumulated with that
and debug this piece of malware
we put in our standard password of
infected and we can bring this right to
the desktop so we are
ready to go
so we'll go ahead and maximize the
debugger we go up to file and we're
going to go to open
and then navigate to the desktop and
we'll switch down to all files
remember that we have not armed this yet
so we still have the mlz extension and
we will double click on that
and even though it has the malz
extension if you load this into a
debugger the debugger will know how to
work with it alright so there's
definitely a lot going on here and this
can look a little bit scary but we're
actually well primed to understand what
we're looking at here because we went
through the advanced static analysis
section
so over here on the left side we have
the cpu window and the cpu window has
all of the instructions that are
available in the program and if you
remember from the cutter section this
looks a whole lot like the disassembled
output from cutter and in a lot of ways
that's exactly what it is
it is the assembly instructions that the
program will execute
now over here on the right this is
different we didn't see this in cutter
but this is probably one of the most
important parts of a debugger and the
program these are the memory registers
remember that in our advanced static
analysis section we talked about how the
memory registers are a little bit like
the read head of a vcr player and so
they will have a reading of the
program's memory locations at any given
point during execution and we see a few
of the ones that are important here we
have eax ebx ecx edx we've got the ebp
the esp
and then right down here we have the eip
the extended instruction pointer and so
if you're not familiar with the extended
instruction pointer this is going to be
the memory location of every instruction
that's going to be executed next while
we're running our debugger so this is
the thing that points to the
instructions and says go ahead operating
system execute those instructions and
tell me what happened so it's super
important to follow the eip now down
here on the bottom right we have the
stack and so any value that's pushed or
popped from or to the stack is going to
be represented here in the stack as a
memory location and the contents of that
memory so we will watch the stack grow
and shrink as the program executes and
then down here in the bottom left we
have the hex dump output we're not going
to use the hex dump so much we're really
going to focus on the other three
sections first all right so control of
the debugger let's talk a little bit
about how we move around inside of a
debugger we really have just a couple of
controls to consider when we're using
the debugger they're going to be the f
keys so you're going to use f2 f7 f8 f9
and if you go up to the debug section
we'll actually get a readout of what
these f keys do so f9 is going to be run
if you run your program it will execute
as if the operating system is executing
the program f7 is step into f8 is step
over we will talk about the difference
between those two here in a bit and f2
is going to be a very very helpful
instruction which will set a break point
and we'll talk a little bit about what
break points are here in a moment so
let's go ahead and just run the program
hit f9 once
and we will see down here at the bottom
paused in three break point entry break
point at dropper download from url exe
entry point so with one press of f9 we
have entered the entry point of this
program
so we are sitting where the operating
system will enter into this program and
say okay go ahead and execute these
instructions and now if we were not in a
debugger at this point the operating
system would go ahead and just continue
to execute those instructions but
because we're in a debugger we are now
at the point where we can control the
exact instructions that are going to run
when this program is run now this is a
bit of a one-way street because as you
execute the instructions you can go
forward in a debugger but you can't
exactly go back you can't go back to the
instruction that you just ran
unfortunately so think of this like a
one-way street if we hit f8 just one
time we move down to the next
instructions now notice on the left-hand
side that the e-i-p is noting where we
are in the execution flow of the program
and it's telling us what's happening
inside of these instructions for this
instruction we are jumping to a memory
location dropper download from url and
if we open this up a little bit more we
see that we are jumping to
f7146f f7146f
if we hit f8 one more time we see that
we have actually moved to
f7146
in the memory location of the program
and now we are pushing 14 onto the stack
so let's hit f8 one more time and we see
down here in the stack we have pushed 14
really 1 4 onto the stack all right
excellent so we see how this is going we
can hit f8 we execute instructions that
are in front of us and then whatever
happens to those instructions is
reflected in the outputs of either the
memory registers or the stack itself now
we're about to get to a call instruction
so let's go hit f8 one more time and
where now our eip is resting on this
call instruction if we hit f8 one more
time we will step over this call
instruction and that means
step into the program execute everything
this part of the program is doing and
return me right back out so we can hover
over this and see what is actually
accomplished during this call but if we
hit f8 we don't step into the program to
see what it's doing we step over it we
allow the debugger to assume that
whatever is inside of that call is just
going to run and then we move on to the
next instruction now
let's hit f7
and if we hit f7 we see that our eip is
resting on this next call which is going
to call to the memory location
f71792 and we can see that right here
but
if we hit f7
one more time
whoa where did we go we actually called
to the memory location of
f71792 and we are now inside of that
call now i'll refer to this as taking
the call if there's a call instruction
i'm going to take the call by pressing
f7 and stepping into it and once we step
into it we are now telling the debugger
okay show me every instruction and run
through each of these instructions that
happens inside of this call function
remember that there will be a call from
a certain function that's going into
another part of the program it does
whatever that part of the program is
designed to do and it returns a value
out to the real world so to recap f8
will step over and that means that any
time it hits this call it will jump
right over it and assume that everything
inside of that call has been executed
and on the opposite side f7 will step
into the call and then we can see
whatever is happening inside of that
call itself so we're probably a little
lost at this point just because we were
going over just the controls of a
debugger so let's go ahead and go right
up to the upper left here and hit this
restart button and remember how i said
that a debugger is kind of a one-way
street you can always restart the
program and go right back to where the
operating system hands over control
and that's different you can't exactly
go back a couple of instructions so if
you if you step over an instruction you
want to go back tough luck you gotta go
back to the start and find it again but
there's another thing that we can do to
make this a little bit easier so let's
hit f9 from the start here we're now at
our break point for the entry and so the
program is very nice and sets us up with
a break point right at the entry but
let's actually make our own break point
so let's hit f8 a couple times and let's
say that we get to this call right here
and we say i wonder what's happening
inside of this call i'm going to set a
breakpoint here so that every time i run
the program i can just stop right on
this call and then step into it step
over it and just kind of play around
with it and see what happens
the way to set a breakpoint is f2 hit f2
on any given instruction that the eip is
currently on and you will set a
breakpoint you could also click right
here on this little breakpoint enabled
button and it'll put this little red dot
right next to that instruction so to set
a breakpoint f2 or click on the little
red dot right here now what does a
breakpoint do let's restart the program
and we will hit f9
one time will bring us to the entry
point
and hitting f9 one more time will hit us
to the first break point that we have
set now you can set as many of these
break points as you want we could set
one here let's set one here let's scroll
all the way down here and set one here
let's set one here and
after i've set these breakpoints now
every time i hit f9 it will land me at
that next breakpoint if it's going to be
executed in the flow of the program so i
can keep hitting f9 and it will just
jump to the next breakpoints so
breakpoints are super super useful to
help you understand the control flow of
the program and to be able to control
exactly what instructions are executed
when
and so the name of the game during
advanced dynamic analysis is to find the
most interesting instructions that are
executed because there's a lot of junk
in here there's a lot of stuff that we
don't care about we need to find
the most interesting instructions that
are executed and set break points on
them and then step into those
instructions and see how they are
functioning and so in the next video
we're going to take this program we're
going to run through it until we find
interesting instructions set breakpoints
on them and see what we can find so meet
me there
all right picking right back up from
where we left off so right now we're
kind of in the middle of the program
here and we can go ahead and return to
the start by pressing the restart button
so let's go ahead and do that now the
other thing that we want to do if you go
over to this tab right here with
breakpoints we can go ahead and see all
of the breakpoints that we have and we
can see where in the memory on on
exactly which address those breakpoints
are set and so we can actually just
remove these breakpoints because we're
not going to need them right now we need
to start at the beginning of this
program and set breakpoints in the
interesting locations for where we want
to determine what the program is doing
so go back to the cpu tab right here and
that will get us back to the main cpu
view
all right so like i said the name of the
game
is to find the interesting calls inside
of this program set break points on them
and then step into those break points
and see what else the program is doing
now you can hit ctrl f2 as a handy
little shortcut to restart the program
so let's restart the program
now if we restart the program one press
of f9 gets us to the entry point
if we press f9 one more time
the program hangs it sees that we've got
dll loaded some other stuff happens and
the debugger stops so if we hit f9 two
times what we are doing is executing the
program completely and then the program
exits and returns out of the debugger
and then the debugger it basically has
nothing no information to go off of so
let's restart
so where exactly does this program
execute so what we can do is hit f9 one
time go to the entry point and then
start hitting f8 until we notice
something happen and so eventually at a
certain point this program is going to
hang once we pass one of these call
instructions and we're not quite sure
where that's going to happen but it
happened right there so eventually when
we hit this call instruction it hangs
for a moment and that's interesting and
we're not exactly sure what's going on
there but i'm going to go ahead and set
a breakpoint there so let's hit f2 right
on that we can highlight this one this
call to drop or download from url.exe so
we can right click and we can select
follow in disassembler
we can follow in disassembler and we can
see that this is the part of the program
where things start to happen now
remember from the static analysis both
the basic and the advanced static
analysis remember that we had some api
calls that were happening inside of this
program this program opened up a handle
to a url that was out on the internet
somewhere and one of two things would
happen if the handle returned true if
there was a website alive at that url
one thing would happen and if it
returned false another thing would
happen and if we see we start reading
into these instructions we can see that
the code starts to look pretty familiar
to us so it looks like we've actually
found our main method and so if we find
this call to dwordpointer
w remember that's the api call that we
were using to open the handle to the url
now remember just like in the advanced
static analysis section let's count back
on and see what's pushed to the stack
right before this api call we have a
push to one memory location that looks
like if we drag this over a little bit
it looks like the memory address f73288
is holding mozilla 5.0 recall that for
the internet open w api call we need the
user agent and the rest of the arguments
that are pushed onto the stack can be
zeros
now actually let's go ahead and
minimize that and let's go back into
cutter
and we can start to cross correlate
tools of course we're going to use dark
theme here
and we will select the exact same
program that we're currently debugging
and we'll load that right into cutter
and open it up and hit ok now let's do a
side by side comparison so we're going
to go ahead and find the main function
so we'll type in main we'll find this
main function here
and then we're going to find the exact
same api call that we're looking at
inside of the debugger and let's
actually put this on one side and this
on the other side so it's nice and easy
to see
and so right where i've highlighted
inside of the debugger we have the call
to the api of internet open w and right
over here in the output of cutter we see
that in the assembly instructions we
have the exact same thing now the memory
location is actually live inside of the
program because this is running now now
in cutter this is static analysis of the
binary is not running and so even though
we have the call to the api here it's
not loaded into the operating system and
available to actually be run but over
here in the debugger we actually have
the memory location inside of the binary
to execute this program which is f73288
so with these two side by side we can
actually look at what's happening inside
of the cutter output and what's
happening inside of the debugger and
it's actually exactly the same thing see
where i have highlighted in the debugger
right now we are making a call to the
internet open w api call
and one two three four five arguments
are pushed to the stack right before
this happens now where have we seen this
before if we go over here and what i'm
highlighting in qatar right now on the
left side we have the call to the
internet open w api and we have one two
three four five arguments pushed to the
stack before this happens so let's go
ahead let's set a breakpoint
so if we scroll over we'll select the
exact precise location in memory where
these arguments start getting pushed to
the stack
and we'll hit f2 and we'll set a point
right there and so let's restart the
program
and we'll hit
f9
and we'll hit f9 and right now we've hit
the break point where we've started to
step into the main part of this program
let's hit f9 one more time
and then let's hit f9 one more time and
we are now at the location where these
arguments start getting pushed to the
stack right before the internet open w
api call is made
so let's minimize cutter
so let's first make sure that inet sim
is up and running and if we go over to
remnux i do have inet sim up
and let's go ahead and open up wireshark
and now this is the idea of
cross-correlating different tools with
the debugger because we can control the
exact flow of the program we can start
to see exactly when these indicators of
compromise start to spring up so let's
watch as our arguments are pushed right
onto the stack so pay attention to the
stack down here in the bottom right
corner
we will hit f7 and we push a zero onto
the stack we will hit f7 and we push
another zero onto the stack remember
that these are the arguments being
passed into the parameter f7 f7 we push
two more zeros onto the stack but now
we're about to push one of the
parameters that actually has something
on the stack we hit f7
and if we will maximize this for a
second we see that this argument is now
on the stack the argument is pointing to
the memory location and in that memory
location we have the string mozilla
5.0 now if you recall the documentation
for the internet open w api call the
argument that we just pushed onto the
stack is the argument for the user agent
string so we're saying to internet open
w we want to open up a handle and we
want to have the user agent of that
handle be mozilla 5.0
so let's bring this back over to the
side
so we have set up our api call of
internet open w if we press f7 one more
time we will jump into this api call and
at this point the program will simply
set up all of the things that it needs
to do to set up this api call and then
returns back to the main part of the
program so to recap we set a breakpoint
right here we watched our arguments get
pushed onto the stack we watched the
user agent string get pushed onto the
stack and then we called the api call of
internet open w when we stepped into
this call it performed everything that
it needed to do to perform that api call
and came back out
and now we can move down to this next
call which is another interesting call
that we have inside of this program so
after we've made that api call we are
now moving more data around to prepare
for another call
so let's move down here we take another
call and then we start pushing more
arguments onto the stack so starting
right here we're pushing more zeros and
then a few more arguments onto the stack
so let's see what happens we'll hit f8
f8 and we've pushed two zeros onto the
stack but we also start to push some
memory locations we push two of those as
arguments
and remember what are we setting up to
do well if we make this a little bit
bigger
we see that this next call that eip is
currently sitting on is a call to url
download to file w now we've pushed all
of the arguments that we needed for this
call right here and so if we hit f8
what's going to happen is this api call
will be executed and we will perform the
download from the url so watch carefully
in wireshark because
all i need to do is hit f8
and it looks like we've got http traffic
tcp traffic and http traffic coming from
our host to inet sim and it looks like
we've got our telltale get to
favicon.ico and remember that in this
program download to url we are getting
favicon.ico and writing it to the file
system now notice where eip is currently
resting
we are currently on an instruction of
test eax against itself test eax eax
so test is going to set a flag in the
memory registers if the ended result of
these two registers is zero
and so if we go over here we see that
there are flags of the registers that
are set to one or zero based on
different results now if we test the
contents of eax and do a logical and
against itself and that result is zero
this flag will set now read the contents
of eax the contents of eax right now is
completely zeroed out and the reason for
that is because url download to file w
will return true or false based on what
happened in the execution of the program
we made the api call we downloaded
something we got our favicon.ico right
here
and then the api call says hey i
succeeded so i'm going to go ahead and
set the contents of eax to zero
and then the next instruction is saying
all right now test the contents of eax
against itself so let's go ahead and hit
f7
and now we have a zero flag which is
right here a zero flag set to one the
zero flag is set to one because we
tested the contents of eax which was
completely zeroed out and it said hey
we've logically ended eax against itself
and there was nothing in eax so we're
going to go ahead and set the zero flag
and now we go to the jne instruction so
jump if not equal so jump if not equal
is going to evaluate the zero flag and
say if this flag is not set i am going
to jump to another location and in this
case that location is f71142
now we could go take a look at what that
is but we're not actually taking that
jump because the zero flag is currently
set
but something interesting i want to
point out is that because we can control
exactly what happens inside of the
debugger we can actually click on this
zero flag and we can set it by double
clicking it we can set it back to zero
and now we will actually end up taking
this jump call if we hit f7
and we can see that by hitting f7 and
we've now jumped to the location f71142
so always remember the point of this is
that while you're running the debugger
you have complete control over this
program you can patch instructions you
can set the flags so that jumps are
taken or are not taken you have complete
control over this binary while it's
inside of the debugger but we didn't
actually want to take that jump call so
let's hit restart
and i'll minimize this to make it easier
to see
and we hit f9 we hit f9 we hit f9 and
we're back to where we started pushing
those arguments onto the stack so let's
follow through that one more time
this time we'll hit f8 we push a bunch
of arguments onto the stack and we call
internet open w we do some more work and
we call another api call we push a few
more arguments onto the stack and
remember watch wireshark here let's
scroll all the way to the bottom
remember keep your eye on wireshark
this is the location where wireshark
actually shows that we are making a
request to our webpage we test the
contents of eax which is currently
zeroed out
and we will not take this jump because
we had a zeroed out eax
so we go immediately to the next
instruction and now we are pushing more
arguments onto the stack to prepare for
this next call which is making a call to
internet open urlw
let's go ahead and pass right over these
next calls here because we want to get
down to this one which is calling shell
execute w remember that the one two
three four five six
parameters that are pushed onto the
stack right before this call to shell
execute w are the arguments that are
needed for this api call and ostensibly
if we hit f8 right now this shell
execute api call would take place so
let's actually set a breakpoint there
we hit f2 and we set a breakpoint
and now that we have a point on this
let's actually open up procmon
and again the name of the game here is
using the debugger to control the flow
of execution while simultaneously
looking at other tools and extracting
insights about exactly when certain
parts of the program execute their
functions so we'll do process name
contains
download from url and we will add that
in as a criteria and we'll filter on
that and so now
if we hit f8 one more time we should see
some activity over here from our
download from url executable that's
inside of the debugger so always
remember that you can combine these
tools because you can use the debugger
to control exactly which instructions
are executed and then you can look over
in procmon and see oh okay so once that
shell execute w api call was made i have
a whole bunch of results in procmond
that show me what's going on and if we
scroll all the way down to the bottom
here we have a call to
see user's husky desktop ping 1.1.1.1
and then it pipes that to the contents
of devnet and then it executes the
cr433101.dat.exe which is in the public
documents directory
so let's open up to public documents and
we will go to this pc and we go to the c
drive
and we open up users and we go to public
and
documents and remember this
cr433101.dat.exe is the thing of
interest so if we delete that
let's go ahead and restart the program
and we'll keep an eye on the contents of
the public documents directory
and let's see if we can determine
exactly when that file is written to the
file system
so we hit f9 a few times we get to our
breakpoints where things are pushed to
the stack
we hit f8 and we make our first api call
internet open w we hit f8 and we make
another call
we push more arguments to the stack and
right here should be the time that our
file appears on the file system because
we're making the url download to file w
call so let's hit f8
and there we go
it looks like
cr33101.dat.exe appears on the file
system when that api call is made and
now let's maximize the screen just to
bring it on home let's see how this
program executes and finishes out let's
hit f8
we make the call to internet open url w
we keep hitting f8 we push our arguments
to the stack and we hit that shell
execute and we hit f8 one more time we
xor eax against itself
and then we make another call and we hit
finally hit this return instruction
when we return we are now on the we're
basically exiting the program at this
point we're wrapping up we're going to
make just a couple more calls we push
esi and then we make a call to jump and
exit
and so with that call to jump in exit if
we take that call and hit f8 we will
finish execution of the program
so i know that was a lot of information
but what i want you to take away from
this is that the debugger is extremely
useful for being able to control exactly
what instructions inside the program
should be executed you have complete
control over it and then you can take
things like procmon and wireshark and
look at the file system and triangulate
exactly when these malicious activities
are taking place on the file system or
the network signatures are happening to
download something from a url or write
something to disk or run some kind of
command so that's our primer our crash
course on debugging incredibly powerful
so meet me in the next video and we'll
start our second challenge in this
course which allows us to combine all of
the skills that we've built up to this
point so meet me there all right
analysts another day another sample
let's go ahead and open up to the lab
repository and go find
2-3 challenge sicko mode and this is
going to be our second challenge binary
now let's go over to the repo readme
which is available on the get page
and we'll scroll down and let's look at
the scenario brief challenge two second
mode analysts this specimen came from a
poor decision and a link that should not
have been clicked on no surprises there
we need to figure out the extent of what
this thing can do it looks a little
advanced perform a full analysis and
send us the report when done we need to
go in depth on this one and determine
what it is doing so break out your
decompiler and debugger and get to work
the ir team
all right and we set up our objectives
we're going to perform static and
dynamic analysis on this malware sample
and we're going to extract facts about
the malware's behavior and we'll use
these facts to answer the questions that
are in the scenario below so these are
the questions that we'll be looking at
and we are going to employ every tool
and methodology and tactic in our
arsenal at this point so we will be
doing all forms of basic static basic
dynamic and to the extent that you're
comfortable a limited amount of advanced
static and advanced dynamic analysis and
so go ahead and break this binary open
take a look at the questions in here see
how many of these you can answer
and remember if you get stuck we always
have the answers directory right here so
you can go in and take a look at those
answers so challenge two sicko mode this
one's fun i had a lot of fun putting
this one together so good luck remember
the answers are always right here in
this directory if you get stuck but good
luck and meet me in the next video for
the walkthrough
hey everybody all right we're talking
about challenge 2-3 sicko mode so we'll
be covering the answers for the sicko
mode binary this is the walkthrough
video so if you have not done so already
go ahead and try to complete the
challenge and answer the challenge
questions but if you have completed that
or if you got stuck go ahead and
continue with this video
so sicko mode
is a binary that is the first challenge
that's introduced after all four phases
of analysis are taught in this course
and so the idea is that by this point
you should have a pretty good
methodology for the basic phases of
analysis
and have just kind of gotten your feet
wet with the advanced phases of analysis
and so i wrote this binary specifically
to support the learning in that regard
and the idea is that it's very helpful
during the analysis of the sicko mode
challenge binary to combine different
phases of analysis so in other words
you'll start with basic static and basic
dynamic and then you'll break out cutter
and the debugger and you will combine
the different tools and methodologies to
get the insights out of this binary now
there were a few curveballs in here and
i'll point them out as we go so let's
jump right in
we're going to go down to 2-3 challenge
seko mode and we open up
unknown.exe dot 7-zip
with the standard password of infected
and we will bring unknown.exe right to
the desktop
and so we will start by doing our normal
round of static analysis so we'll launch
into a power
shell prompt
and we will do all manner of things that
we need to do for basic static analysis
so get file hash and then algorithm we
will pass it in sha 256
and then desktop unknown.exe
we'll take this file hash annotate that
in our notes submit this to virustotal
at the time of recording this of course
there are no results for this binary so
i'll start following along with the
challenge questions and we're going to
talk through each of them one by one
so question number one what language is
this binary written in so from an early
analysis perspective we can get this
pretty quickly by using floss against
the binary and of course i already know
the answer to this so i'll go ahead and
put in
what the answer is the binary is written
in nim
and the way we can tell that is by
flossing the binary and identifying a
lot of the strings that indicate that
this binary is importing nem libraries
and is using three particular methods
around the main method we have nim main
we have nim main inner and nim main
module and so binaries that are compiled
in nim they have about three prelude
method calls before they get to the main
method and so you'll see that really the
only thing you can surmise here is that
unless there was a lot of effort by the
malware author to
change a lot of these strings to make it
look like this was compiled in nim which
is an unlikely scenario we see all
manner of things that indicate that this
is a nim binary
uh name imports tables http client that
kind of thing and we have all the method
calls that have nim as a prefix so
pretty pretty straightforward at that
point uh next question we need to
determine the architecture of this
binary so this was interesting because
if you go to what you would normally do
and use something like pe view
you'll load up pe view and you'll load
unknown.exe into pe view and it says
this version only provides a limited
view of 64-bit files now it's worth
mentioning one of the curveballs of this
challenge is that this is a 64-bit
binary and we really haven't introduced
a lot in regards to 64-bit analysis so
my point here is that this challenge
could still be completed even if you
don't know anything about 64-bit
binaries all you needed to do was focus
on the big moving parts and focus on
combining the other phases of analysis
with the advanced static analysis and
advanced dynamic analysis when you break
this thing open in cutter and the
debugger the very fine details of this
binary look a lot different instead of
eax there's rax instead of eip there's
rip so if you get sucked down into the
weeds with this binary you might have a
pretty hard time determining what's
going on but all of the big overarching
moving parts are the same so we'll get
into that a little bit more as we go
along but this was one of the indicators
that this is going to be a bit of a
curveball you're not working with just a
32-bit binary we're working with 64-bit
which we haven't really learned a whole
lot about so we need to kind of think on
our feet here but that's okay so let's
get out of pe view and actually go into
pe studio
and pe studio does have support for
64-bit binaries and we'll throw this
right in here and we take a look this
could also be part of our initial run of
basic static analysis where we load this
into pe studio so in any case the answer
for that question this is an x64
architecture binary for a 64-bit cpu and
we can find that out by loading it into
pe studio
and if we inspect it at the assembly
level we'll notice that there's a whole
bunch of stuff that we don't really that
we've never really seen before now the
next question assumes that we have
continued through the static analysis
phase and we've started to perform basic
dynamic analysis so when we
move to do basic dynamic analysis we do
have our inet sim instance up and
running
so the next question is under what
conditions can you get this binary to
delete itself so this is a self-deleting
binary and there are a couple of
instances written into the code that
will make this delete itself from disk
so the first instance is that if this
executable runs and it cannot make a
callback to its first
callback domain
it will close the handle to that url and
then delete itself from disk
and so if we have inet sim up and
running and we'll actually open up let's
open up wireshark as well so we can see
this happen in real time
listen on the correct
adapter so if we have inet sim up and
running and we double click on
unknown.exe if we go over to inet stem
we'll actually start to see the
exfiltration of the data occur which
we'll cover a little bit here in a
second
so the the point is that if you have
init sim up and running you won't be
able to determine that this binary can
delete itself from disk until after the
x alteration routine is completed
but
if we ctrl c and stop inet sim and we
start getting these packets that say
that the binary can't communicate with
its callback domain we go back over here
and we see that unknown.exe is gone now
it's deleted itself from disk and we can
actually let's go ahead and watch that
happen again
unpack unknown.exe
standard password of infected we bring
this right out to the desktop and again
initsim is not running at this point
let's double click it thinks for a
second
and then it is gone poof deletes itself
from disk so that is one of the
conditions in which this binary will
delete itself from disk the other two
require a little bit more on the
advanced analysis side and i'll just say
what they are right now
we actually kind of just saw one uh if
the executable is interrupted in the
middle of whatever it's doing so we're
not quite sure what this executable is
doing right now but if we interrupt it
if we kill inet sem in the middle of its
routine it will delete itself from disk
and then the final criteria here is that
if there's ever an exception hit or if
the executable finishes and exits
without error code it will also delete
itself from disk now moving on to the
next question does the binary persist if
so how this is kind of you need to be
able to determine when something is not
doing a particular function with this
question and if you search around if you
look with procmon or any kind of tool
that can determine host-based indicators
you could take a look at the registry
for this one but really when it comes
down to it there are no persistence
mechanisms in this binary and the idea
there was to use tools like procmon
and run the binary and look and filter
on the criteria to identify if there are
any host-based indicators happening if a
file is written to disk into a registry
key anything like that there are no
persistence mechanisms for this binary
now next up we need to determine the
first callback domain for this sample so
let's get our sample back out to the
desktop
and we'll throw remnux and flare vm to
each side of the screen so we can see
this a little bit more easily so when we
have unknown.exe out on the desktop
and we do have to start inetsim back up
we'll go back over and we will clear out
our output from wireshark
and go ahead and start listening again
so we need to determine the first
callback of this binary so for basic
dynamic analysis we're going to get a
back here when we double click and we
look through the tcp handshake that
happens and then there's the first http
packet that comes across and let's open
up the header for the http packet and
take a look
we have http colon
update.ec12-4-109-278-3-ubuntu
20-04.local so this is just big gross
long
url that's in use and it kind of looks
like an aws instance not quite but it
kind of looks like one
we've got a user agent of mozilla 5.0
so this is our first callback
information let's go over to the strings
output and instead of grepping for nim
let's actually grep for this url so i'm
going to go ahead and copy the value and
i'll throw this right into the floss
output and grep for it
and if we grep for this it's not going
to be in the output of floss and so that
was another bit of a curveball here in
that the strings of the binary don't
contain this first callback information
so the initial callback domain was not
in the strings but the exfiltration
domain was so if you were not paying
attention you might have jumped right
over the initial callback domain and
thought that the exfiltration domain was
the first callback that was mentioned so
if we go down to maybe one of the first
exfiltrations so here is an example of
the binary exfiltrating and so our uri
here is http colon
cdn.altimeter.local
feed and then there's kind of like a
parameter in the post field so you may
have said oh that must be the first
callback domain because that's where
this exfiltration is taking place but
that's not the case it's actually a
different one and this binary is
splitting web requests between its first
callback domain and the actual
exfiltration domain
but we'll get to that here in a second
but to answer the question the first
callback domain is http colon slash
update.ec12 etc etc and that was not
present in the strings of the binary as
we can see trying to grip for it and it
comes up empty-handed
under what conditions can you get the
binary to exfiltrate data so we've
already kind of answered this if you go
back to the binary and let's actually
kill inet sim and the binary should
delete itself from disk here in a second
because ion and sim has stopped in there
it goes so let's clear the output of our
wireshark and start listening again on
the same interface and get inet sim up
and running
so the idea is that we need to determine
how this binary is able to exfiltrate
data and under what conditions well we
already kind of know that so the answer
to this question is that the binary must
contact the initial domain that we just
found of
update.ec12-4 etc etc
if it makes a successful connection to
that url it will then start to
exfiltrate data and the data that it's
exfiltrating is cosmo.jpg
now if it does not connect to that url
it will close out the handle to that url
and then delete itself from disk
now the next question is the
exfiltration domain and again remember
this is different than the initial
callback domain so if we do our callback
one more time we get our tcp
handshake opens up and then our http
requests and the first one that comes
across the wire that we can read
is to
update.ec12 etc etc ubuntu.local
and so that is our callback domain but
then we scroll down and like we saw
earlier we have a response and then we
get to the first http request that
indicates that there is data being
exfiltrated let's open this up to see it
a little bit easier and our full uri
here is http colon
cdn.altimeter.local
and then it is posting to a specific uri
which we'll get to here in a second so
again these two domains are different
there is a callback domain and then an
actual exfiltration domain so the next
question is what type of data is
exfiltrated the file is cosmo.jpg but
how is the files data transmitted and so
if we open up to our wireshark output
we're going to the feed uri so like a
feed page and there seems to be a
parameter of post equals and then this
has a big block of text inside of it so
if we check between these different
requests to this page we see that this
data is different every single time one
thing that you can use to form a
hypothesis is that the data from
cosmo.jpg is being read in by the
malware in some way
and encoded or maybe encrypted and then
used with this get request to this
exfiltration domain
now it's interesting because this is a
get request it's not like we're actually
sending any data into the website itself
like posting a form or anything like
that but even by virtue of the fact that
this post equals right here is going to
be filled in with this big block of text
that text is still going to be present
on like the web logs of wherever this
web server exists so even though this
isn't really a post request in the true
sense of the word you're still sending
data to the website by making a get
request to it and that data can be
scraped on the back end of that website
by whomever is using it to exfiltrate
data so at this point we're not quite
sure what's going on with this post
equals in terms of is this encoded is
this encrypted but we do know that this
big block of text is being sent after we
hit go on this binary and it's being
used in a get request to this
altimeter.local uri so those are facts
that are worthy of note and we'll keep
moving on now for the final few
questions we're going to move into
advanced analysis and so we will go back
over to flair and we'll just take a look
at some of the final questions in this
challenge and we'll see if we can use
some advanced methodology to solve them
so the next question up is what kind of
encryption algorithm is in use so the
way that we can determine that there are
a few ways to do this one of them is by
looking at imported libraries and even
the string references of the imported
libraries so if we go back over to
commander so by carefully reading
through the floss output we can find
something that has to do with rc4 and so
even though that's not enough to prove
that rc4 is the algorithm in use that is
something that we can start to track
down when we move into the advanced
dynamic and advanced static analysis
phases
and so with the output when we grep for
rc4 we do in fact have a method call to
the 2rc4 method and we also see that we
might have another library import right
here with rc4.nim.c
now again in basic static analysis and
by inspecting the strings there is not
enough information to go off of at this
at this point so we really do need to
correlate that with advanced methodology
so when we go over to cutter and we load
this in we can go ahead and look for the
2rc4
method inside of the binary
and we'll go over to graph u to get a
better view of this so if we look in
here we do have the 2rc4 method call now
we need to go back out to wherever this
2rc4 method call is invoked from
and so after a little bit of looking
around we find that the steel stuff the
sim.steelstuff method inside of the
cutter output
is going to have a call to the 2rc4
method and so if we follow this down
eventually we get to the point where we
get into this loop that starts right
here and then as we go down through the
loop we see that the information however
this binary is bringing information into
the program it eventually will try to
encrypt it with rc4 now with that having
been said the next question is trying to
locate the key that's used during the
rc4 encryption routine
and actually the earlier phases the
dynamic analysis phase might actually
help us a lot more than looking through
the assembly instructions of this binary
so if we open up procmon
and we'll go ahead and filter we will do
process name contains
unknown
and we'll include that and then we need
to look at operation
is create file
so with process name contains unknown
and operation is create file we'll go
ahead and filter on those two criteria
and so we do have output from the last
time that we ran it but we're going to
go ahead and just clear out that output
and then we will run unknown.exe one
more time
and so we get a nice clean output to
look through here and if we scroll down
we see that one of the things that
occurs during the execution of this
program is some kind of create file
operation to see userspublicpassword.txt
so let's go track this down we will go
to
c
users
public
and we have password.text right here so
if we open this up we just have the text
seco mode and this is the password for
use in the encryption routine
now the final question here is what is
the significance of houdini
so we've already kind of covered this in
a way houdini is the method call used by
the binary to delete itself from disk
and if we type in houdini into cutter to
search for it for the method call itself
we find that this is actually written
into the program as houdini but to know
what the significance is of this we need
to know where this is used so let's go
back to the main method
and notice that in a nim binary there
are really kind of three main methods
here that we have to deal with we have
nim main we have nimm main inner and nim
main module and the one of most interest
to us is going to be nim main module so
if we go to nim main module we can kind
of just check really quickly to see
where houdini is used so we see that
houdini is invoked in the instance where
after we check the kill switch url we
will test the contents of al the lower
bits of the eax or rax in this case
register
and then we jump if not equal to so if
the zero flag is not set we're going to
jump over to call houdini and then we
jump to the end of the program which
returns out of the main method
so that's one instance where houdini is
called and that correlates to what we
found earlier in that if we check the
kill switch url and we can go into this
method call and understand a little bit
more about what it's doing but from a
high level if we check the kill switch
url and it does not return true then
we're going to call houdini and exit the
program
now another instance of houdini can be
seen right here
and so if we move down a little bit if
we check the kill switch url and it
returns true we do a little bit more
work and we go over here and we test the
contents of rax if rax does not set the
zero flag then we go over and we perform
what i consider to be the main routine
in this binary which is unpack resources
and steel stuff but on the other side of
that we call houdini and then
interestingly enough either one of these
paths will lead back to the last
instance of houdini which is right here
so that correlates again with what we
said earlier
if the binary is interrupted at any
point it will call houdini in this path
of the execution flow
and even if unpack resources and steal
stuff complete successfully it will also
call houdini and delete itself from disk
there as well
so that is the significance of houdini
and so from a very high level we check
the kill switch url and if we don't get
a good result we delete ourselves from
disk if we do get a good result we kick
off the main part of this binaries
routine which includes unpack resources
and steel stuff if at any point we get
interrupted we call houdini and delete
ourselves from disk and then finally at
the end of either of those instances we
will call houdini and delete ourselves
from disk and that concludes the
walkthrough for the sicko mode challenge
well hey everybody we've made it to the
end of the five hour release of
practical malware analysis and triage on
youtube i thank you for coming along
with me in the course and i wanted to
give this to the community as a gift
because of just the support and the love
that i've received from the community it
has been my personal and professional
honor to be your instructor for this
course now if you have made it through
the five hours on youtube and you're
hungry for more i would like to remind
you that practical malware analysis and
triage the full course the whole nine
hours is available on tcm security
academy for a purchase price of 29.99 us
dollars and now
if you have made it through the youtube
section
of the nine hours we have completed five
and that would land you right about here
at the end of the sicko mode walkthrough
and you can see there is tons more
content in this course we go into
specialty class malware we talk about
maldox and shellcode c-sharp we talk
about mobile malware sandboxing
automating analysis and we also do
something very important rule writing
and report writing to tell the world
what we found during our analysis
and so if you'd like to purchase the
course there is tons more content to
discover in this course so please go to
the tcm security page and find practical
malware analysis and triage and of
course the links of those have been in
the description and throughout the
course i thank you again
please let me know if you have any
questions feedback comments concerns
memes malware samples you can send them
to me in my inbox
i always love to hear from students and
i love to help you out on your journey
and wherever you go from here please
remember take care of yourself take care
of each other i'm happy you're here and
the world needs you that's it take care
[Music]