This presentation exposes the current threat model of execution stalling malicious code, and multiple pointers to relevant academic research in analysis. I presented these works to a weekly Security and Privacy reading group. The academic proceeding can be found here: www.syssec-project.eu/media/page-media/3/hasten-ccs11.pdf

1. The
Power
of
Procras-na-on
Detec-on
and
Mi-ga-on
of
Execu-on-­‐Stalling
Malicious
Code

2. WARNING
• The
views
presented
in
this
presenta-on
are
my
own
and
do
not
express
the
views
of
the
Johns
Hopkins
University.
• The
content
presented
in
this
presenta-on
was
extracted
from
mul-ple
academic
conference
proceedings.
• Most
pictorial
references
were
shamelessly
collected
from
the
internet
and
presented
without
reference.
If
you
find
your
image
and
wish
to
request
that
I
provide
a
reference,
please
email
me
at
the
address
provided
on
my
website:
michaelrushanan.org.

3. Selec-on
Purpose
• Why
did
I
select
this
paper
to
present?
– It’s
an
arms
race…
sort
of.

4. Stall-code?!
Totally ingenious, I have no idea what
sort of beautiful mind could have
thought this up to thwart our
dynamic analysis!!!!
At
a
very
well
known
security
lab…

5. I hope no one notices my 10k
lines of copied and pasted GetTickCount
calls… no one taught me about those
loop thingies.
GetTickCount()
GetTickCount()
GetTickCount()
GetTickCount()
Meanwhile,
at
the
evil
malware
lair…

6. Selec-on
Purpose
• Proverbial,
“Catch
me
if
you
can…
and
publish!”
– I
am
very
interested
in
this
sort
of
work
and
it’s
placement
as
security
research.
– The
analysis
of
malware,
the
mi-ga-on
of
analysis,
the
improvement
of
both.
– The
economical
model
of
malware
and
security,
but
that’s
my
least
favorite
;).

8. Talk
Outline
1. 50-­‐
View
of
Paper.
2. Background;
to
include
Previous
Work,
History.
3. Summary;
to
include
Key
Points
of
the
Paper.
4. Conclusion
and
Thoughts.

10. 50-­‐
View
of
Paper
• Malware
is
not
going
anywhere.
– To
maintain
profitability,
directly
dependent
upon
survivability.
–
To
increase
the
probability
of
malware
survivability,
malware
authors
need
to
introduce:
• Addi-onal
techniques
for
iden-fying
emulated
and
virtual
environments.
• Crea-ng
non-­‐malicious
branches
of
computa-on
that
obfuscate
the
intent.
• Complicate
everything!

11. 50-­‐
View
of
Paper
• Dynamic
Analysis,
thus,
is
not
going
anywhere!
–
To
face
the
increasing
complexity
of
malware,
we
must
rely
on
dynamic
behavior-­‐based
analysis
techniques.
• Execute.
• Monitor.
• Record
and
Report.

13. Background
• What
is
malware?
– Prefix
mal
=
bad.
– Malicious
soware…
the
kind
you
try
and
talk
your
mom
into
not
downloading.
– Profitable
incen-ve
for
the
bad
guys.
• What
is
malware
used
for?
– [Botnets]
Spam;
the
number
one
being
erec-le
dysfunc-on.
– [Click
Fraud]
Perpetrate
web
fraud.
– [Trojans]
Steal
personal
informa-on.
– “Nefarious
tasks”
…
e.g.,
ANNOY
YOU.

14. Background
• What
protects
you
from
malware?
– An--­‐virus
scanners.
• Problem
with
the
tradi-onal
an--­‐virus
scanners?
– Sta-c
implementa-on;
implementa-on
as
follows:
• Discover
new
binary
in
the
wild,
test
for
malicious
intent.
• If
malicious,
create
a
signature
on
the
malware.
• Push
to
a
networked
database.
• Clients
update
their
local
signature
database,
scans
for
malware
matching
signature.

15. Background
• Signature-­‐based
An--­‐Virus
Scanners:
AV
Start
Input
New
Binary
Is binary yes
Make Signature
malicious?
no
Push to Net
DB Net
Client Updates
Local DB Local
Client Scan on
Signature
AV
Stop

16. Background
• What
about
Dynamic
Analysis?
– Malware
authors
got
smart…
use
encryp-on
and
obfusca-on
(<
crypto
cool)
to
thwart
the
above.
– Shi
to
run-me
behavior
analysis
of
malware.
• How
is
this
analysis
possible?
– Dynamic
Analysis
Systems
(e.g.,
Anubis
in
this
paper).
– Sandboxing,
Emula-on/Virtualiza-on
(Qemu,
Vmware).

17. Background
• If
I
were
malware,
what
would
I
want
to
do
to
thwart
dynamic
analysis?
1. Determine
if
I
were
in
a
sandbox
or
emulated
environment.

19. Background:
Emulator?
“Anacks
on
Virtual
Machine
Emulators”

20. Emulator?
• EASY
malware
anack
on
vm’s:
refuse
to
operate
maliciously
;).
• MODERATE
malware
causes
the
VM
to
fail.
• RESEARCH
WORTHY
breakout
of
the
VM
and
do
some
damage!

21. Emulator?
• VM’s
not
fully
transparent
as
it’s
not
their
intended
use.
• Detec-ng
VMWare:
– B/C
Vmware
relies
on
underlying
hardware
of
execu-on
of
instruc-ons,
it
relocates
sensi-ve
data
structures
such
as
the
Global
Descriptor
Table
while
making
a
Local
Descriptor
Table
(which
Windows
doesn’t
usually
do).
So
look
for
non-­‐zero
LDT.

23. Background:
Red
or
Blue
Pill?
“A
fispul
of
red-­‐pills:
How
to
automa-cally
generate
procedures
to
detect
CPU
emulators”

24. Red
or
Blue
Pill?
Red-­‐pill
=
1. One
or
more
machine
instruc-ons
that
return
par-cular
informa-on
about
the
system.
– E.g.,
the
address
of
the
interrupt
descriptor
table.
2. Machine
instruc-ons
that
behave
differently
when
executed
in
a
real
system
vs
emulated
system.
– E.g.,
Under
IA-­‐32
Architecture,
the
x86
instruc-on
for
or
of
the
value
in
register
%bh
with
value
in
memory
0x04(%ebx)
stores
result
in
the
wrong
mem
address
while
being
emluated
in
Qemu.

25. Red
or
Blue
Pill?
• High
Level
of
how
Red-­‐Pill
Genera-on
is
done:
– Access
to
both
physical
and
emulated
environment.
– Some
sampling
of
the
input
space
over
all
possible
CPU
start
states.
– On
random
data
(though
same
for
both
environments),
run
input
on
our
CPU
states
(think
finite
state
automaton).
– Compare
successful
paths
to
one
another,
return
1
if
emulated
0
if
not
emulated.

26. Red
or
Blue
Pill?

27. Red
or
Blue
Pill?
• Obvious
heuris-cs
to
this
model:
– While
genera-ng
poten-al
red-­‐pills,
you’ll
want
to
discard
unreliable
pills
that
do
not
determinis-cally
report
the
same
output
on
a
repeat
itera-on.
– Your
CPU
is
an
oracle,
it
will
be
used
to
determine
if
some
sequence
of
bytes
(the
input)
is
a
valid
instruc-on.
– The
en-re
model
is
trial
based,
so
you
may
feed
invalid
bytes
into
the
model.

28. Red
or
Blue
Pill?
• Actual
Data
reported
in
the
paper:
– 2973
(29k?)
red
pills
detected
for
Qemu.
– Tested
red
pill
implementa-ons
against
online
malware
scanners
such
as
Anubis.
– Exci-ng
because
Anubis
is
a
product
of
the
paper,
as
Hasten
is
an
extension
of
it.

30. Background:
Anubis
“A
View
on
Current
Malware
Behaviors”
• Anubis
is
a
dynamic
malware
analysis
plaporm
that
executes
submined
binaries
in
a
controlled
environment.

31. Anubis
• Keeping
Anubis
simple:
– To
perform
analysis:
• Public
web
interface
to
submit
binary.
• Emulated
environment
to
observe:
– Window
API
calls.
– File
System
ac-vity.
– Registry
ac-vity.
– Network
Traffic.
• Outputs
a
report
that
compiles
analy-cs
captured
from
the
above.

33. Background:
Inspector
“Inspector
Gadget:
Automated
Extrac-on
of
Proprietary
Gadges
from
Malware
Binaries”

34. Inspector
• Purpose:
automa-cally
extract,
from
a
given
binary
executable,
the
algorithm
related
to
a
certain
ac-vity
of
the
sample.
• Define:
Gadget
– “stand-­‐alone
component
that
encapsulates
a
specific
behavior;
specifically
an
algorithm
within
a
malware
binary.

35. Inspector

37. Background
[REMEMBER
THIS
SLIDE?]
• If
I
were
malware,
what
would
I
want
to
do
to
thwart
dynamic
analysis?
1. Determine
if
I
were
in
a
sandbox
or
emulated
environment.
2. Implement
Execu-on-­‐Stalling
Code;
or
stall-­‐
code.

39. Summary:
Stalling
Code
Now
we
have
come
full
circle,
back
to
The
Power
of
Procras-na-on.
The
problem
in
this
paper
is
as
follows:
Malware
authors
have
caught
on
to
dynamic
analysis,
and
are
ac-vely
working
to
evade
it.
Such
evasion
techniques
include
the
technique
of
stalling
code.

40. Stalling
Code
• What
do
anackers
want
to
exploit?
1. Time.
The
-me
that
a
system
can
spend
to
execute
a
single
sample
is
limited.
Malware
authors
know
this,
and
as
such
they
can
cra
their
code
so
that
execu-on
takes
much
longer
inside
the
analysis
(emulated)
environment.
Even
Bener
–
that
same
code
will
execute
quickly
on
a
host
system
that
is
not
emulated!

41. Stalling
Code
• Contribu-ons:
– First
approach
to
detect
and
mi-gate
stalling
code.
– Real-­‐world
system
implementa-on
(Hasten
which
is
an
extension
to
the
dynamic
analysis
tool
Anubis).

42. Stalling
Code
This
is
horrid
in
the
emulated
environment
because
GetTickCount
is
monitored,
thus
invoking
a
pair
of
log
func-ons
for
each
call.
Thus
logging
called
60
million
-mes
~
10
hours
stall.

43. Stalling
Code
• Hasten
Modes
of
Opera-on:
– Monitor
Mode:
lightweight
observa-on
of
all
threads
of
the
process.
Measure
the
progress
of
each
thread,
and
id
execu-on
in
stall
region.
– Passive
Mode:
Detects
slow
progress;
record
informa-on
about
the
code
blocks
in
ques-on;
build
par-al
control
flow
graph
(CFG)
of
the
non-­‐progressing
thread;
whitelist
code
in
the
stalling
region
(to
include
all
code
in
the
loop
body),
and;
turn
off
detailed
malware
introspec-on
for
these
regions.
– Ac-ve
Mode:
Interfere
with
malware
execu-on
by
using
CFG
to
id
all
nodes
associated
with
condi-onal
jumps
that
are
part
of
the
stalling
loop
and
have
one
successor
node
that
is
not
part
of
the
whitelisted
region,
and;
flips
the
condi-onal
equality
and
exits
the
loop
(inconsistencies
can
and
will
occur).

44. Stalling
Code
Monitoring
Mode
Specifics
• Monitor
the
progress
of
a
running
program
by
inspec-ng
the
system
calls
that
it
invokes.
• Aer
a
thread
has
been
scheduled
for
-me
t,
the
system
employs
five
detectors
to
evaluate
the
system
calls
that
have
been
observed.
• If
>
1,
then
switch
to
passive
mode.
*
This
is
dependent
on
your
selected
t
value;
large
t
are
more
resistant
to
short
repeated
behavior
and
small
t
is
faster
detec-on
of
abnormal
ac-vity.

45. Stalling
Code
1. Too
few
successful
system
calls.
(insufficient
progress)
2. Too
many
successful
system
calls.
(overhead)
3. To
many
failed
system
calls.
(overload
b/c
full
logging)
4. Too
many
iden-cal
system
calls.
(GetTickCount)
5. Too
diverse
system
calls.
(Randomized
system
calls)

46. Stalling
Code
• Passive
Mode

47. Stalling
Code
• Ac-ve
Mode
– Men-on
tain-ng.

49. References
• Clemens
Kolbitsch,
Engin
Kirda,
Christopher
Kruegel.
The
Power
of
Procras-na-on:
Detec-on
and
Mi-ga-on
of
Execu-on-­‐Stalling
Malicious
Code.
• Ulrich
Bayer,
Imam
Habibi,
Davide
Balzaro},
Engin
Kirda,
and
Christopher
Kruegel.
A
View
on
Current
Malware
Behaviors.
• Roberto
Paleari,
Lorenzo
Mar-gnoni,
Giampaolo
Fresi
Roglia,
Danilo
Bruschi.
A
fispul
of
red-­‐
pills:
How
to
automa-cally
generate
procedures
to
detect
CPU
emulators.
• Clemens
Kolbitsch,
Engin
Kirda,
Christopher
Kruegel,
Thorsten
Holz.
Inspector
Gadget:
Automated
Extrac-on
of
Proprietary
Gadgets
from
Malware
Binaries.
• Peter
Ferrie.
Anacks
on
Virtual
Machine
Emualtors.
• Min
Gyung
Kang,
Heng
Yin,
Steve
Hanna.
Emula-ng
Emula-on-­‐Resistant
Malware.

50. Thanks!
Ques-ons?