Cybersecurity
news,
in
Europe
at
least,
is
currently
dominated
by
stories
about
“VMWare
ESXi
ransomware”
that
is
doing
the
rounds,
literally
and
(in
a
cryptographic
sense
at
least)
figuratively.
CERT-FR,
the
French
government’s
computer
emergency
response
team,
kicked
off
what
quickly
turned
into
a
mini-panic
at
the
tail
end
of
last
week,
with
a
bulletin
entitled
simply:
Campagne
d’exploitation
d’une
vulnérabilité
affectant
VMware
ESXi
(Cyberattack
exploiting
a
VMWare
ESXi
vulnerability).
Although
the
headline
focuses
directly
on
the
high-level
danger,
namely
that
any
remotely
exploitable
vulnerability
typically
gives
attackers
a
path
into
your
network
to
do
something,
or
perhaps
even
anything,
that
they
like…
…the
first
line
of
the
report
gives
the
glum
news
that
the
something
the
crooks
are
doing
in
this
case
is
what
the
French
call
rançongiciel.
You
probably
don’t
need
to
know
that
logiciel
is
the
French
word
for
“software”
to
guess
that
the
word
stem
ranço-
came
into
both
modern
French
(rançon)
and
English
(ransom)
from
the
Old
French
word
ransoun,
and
thus
that
the
word
translates
directly
into
English
as
ransomware.
Back
in
the
Middle
Ages,
one
occupational
hazard
for
monarchs
in
time
of
war
was
getting
captured
by
the
enemy
and
held
for
a
ransoun,
typically
under
punitive
terms
that
effectively
settled
the
conflict
in
favour
of
the
captors.
These
days,
of
course,
it’s
your
data
that
gets
“captured”
–
though,
perversely,
the
crooks
don’t
actually
need
to
go
to
the
trouble
of
carrying
it
off
and
holding
it
in
a
secure
prison
on
their
side
of
the
border
while
they
blackmail
you.
They
can
simply
encrypt
it
“at
rest”,
and
offer
to
give
you
the
decrpytion
key
in
return
for
their
punitive
ransoun.
Ironically,
you
end
up
acting
as
your
own
jailer,
with
the
crooks
needing
to
hold
onto
just
a
few
secret
bytes
(32
bytes,
in
this
case)
to
keep
your
data
locked
up
in
your
very
own
IT
estate
for
as
long
as
they
like.
Good
news
and
bad
news
Here’s
the
good
news:
the
current
burst
of
attacks
seem
to
be
the
work
of
a
boutique
gang
of
cybercriminals
who
are
relying
on
two
specific
VMWare
ESXi
vulnerabilities
that
were
documented
by
VMware
and
patched
about
two
years
ago.
In
other
words,
most
sysadmins
would
expect
to
have
been
ahead
of
these
attackers
since
early
2021
at
the
latest,
so
this
is
very
definitely
not
a
zero-day
situation.
Here’s
the
bad
news:
if
you
haven’t
applied
the
needed
patches
in
the
extended
time
since
they
came
out,
you’re
not
only
at
risk
of
this
specific
ransomware
attack,
but
also
at
risk
of
cybercrimes
of
almost
any
sort
–
data
stealing,
cryptomining,
keylogging,
database
poisoning,
point-of-sale
malware
and
spam-sending
spring
immediately
to
mind.
Here’s
some
more
bad
news:
the
ransomware
used
in
this
attack,
which
you’ll
see
referred
to
variously
as
ESXi
ransomware
and
ESXiArgs
ransomware,
seems
to
be
a
general-purpose
pair
of
malware
files,
one
being
a
shell
script,
and
the
other
a
Linux
program
(also
known
as
a
binary
or
executable
file).
In
other
words,
although
you
absolutely
need
to
patch
against
these
old-school
VMWare
bugs
if
you
haven’t
already,
there’s
nothing
about
this
malware
that
inextricably
locks
it
to
attacking
only
via
VMWare
vulnerabilities,
or
to
attacking
only
VMWare-related
data
files.
In
fact,
we’ll
just
refer
to
the
ransomware
by
the
name
Args
in
this
article,
to
avoid
giving
the
impression
that
it
is
either
specifically
caused
by,
or
can
only
be
used
against,
VMWare
ESXi
systems
and
files.
How
it
works
According
to
CERT-FR.
the
two
vulnerabilities
that
you
need
to
look
out
for
right
away
are:
-
CVE-2021-21974
from
VMSA-2021-0002.
ESXi
OpenSLP
heap-overflow
vulnerability.
A
malicious
actor
residing
within
the
same
network
segment
as
ESXi
who
has
access
to
port
427
may
be
able
to
trigger
[a]
heap-overflow
issue
in
[the]
OpenSLP
service
resulting
in
remote
code
execution. -
CVE-2020-3992
from
VMSA-2020-0023.
ESXi
OpenSLP
remote
code
execution
vulnerability.
A
malicious
actor
residing
in
the
management
network
who
has
access
to
port
427
on
an
ESXi
machine
may
be
able
to
trigger
a
use-after-free
in
the
OpenSLP
service
resulting
in
remote
code
execution.
In
both
cases,
VMWare’s
official
advice
was
to
patch
if
possible,
or,
if
you
needed
to
put
off
patching
for
a
while,
to
disable
the
affected
SLP
(service
location
protocol)
service.
VMWare
has
a
page
with
long-standing
guidance
for
working
around
SLP
security
problems,
including
script
code
for
turning
SLP
off
temporarily,
and
back
on
again
once
you’re
patched.
The
damage
in
this
attack
In
this
Args
attack,
the
warhead
that
the
crooks
are
apparently
unleashing,
once
they’ve
got
access
to
your
ESXi
ecosystem,
includes
the
sequence
of
commands
below.
We’ve
picked
the
critical
ones
to
keep
this
description
short:
-
Kill
off
running
virtual
machines.
The
crooks
don’t
do
this
gracefully,
but
by
simply
sending
every
vmx
process
a
SIGKILL
(kill)
-9
to
crash
the
program
as
soon
as
possible.
We
assume
this
is
a
quick-and-dirty
way
of
ensuring
all
the
VMWare
files
they
want
to
scramble
are
unlocked
and
can
therefore
be
re-opened
in
read/write
mode. -
Export
an
ESXi
filesystem
volume
list.
The
crooks
use
the
esxcli
storage
filesystem
list
command
to
get
a
list
of
ESXi
volumes
to
go
after. -
Find
important
VMWare
files
for
each
volume.
The
crooks
use
the
find
command
on
each
volume
in
your
/vmfs/volumes/
directory
to
locate
files
from
this
list
of
extensions:
.vmdk
.vmx
.vmxf
.vmsd
.vmsn
.vswp
.vmss
.nvram
and
.vmem -
Call
a
general-purpose
file
scrambling
tool
for
each
file
found.
A
program
called
encrypt
uploaded
by
the
crooks,
is
used
to
scramble
each
file
individually
in
a
separate
process.
The
encryptions
therefore
happen
in
parallel,
in
the
background,
instead
of
the
script
waiting
for
each
file
to
be
scrambled
in
turn.
Once
the
background
encryption
tasks
have
kicked
off,
the
the
malware
script
changes
some
system
files
to
make
sure
you
know
what
to
do
next.
We
don’t
have
our
own
copies
of
any
actual
ransom
notes
that
the
crooks
have
used,
but
we
can
tell
you
where
to
look
for
them
if
you
haven’t
seen
them
yourself,
because
the
script:
-
Replaces
your
/etc/motd
file
with
a
ransom
note.
The
name
motd
is
short
for
message
of
the
day,
and
your
original
version
is
moved
to
/etc/motd1
so
you
could
use
the
presence
of
a
file
with
that
name
as
a
crude
indicator
of
compromise
(IoC). -
Replaces
any
index.html
files
in
the
/usr/lib/vmware
tree
with
a
ransom
note.
Again,
the
original
files
are
renamed,
this
time
to
index1.html
Files
called
index.html
are
the
home
pages
for
any
VMWare
web
portals
you
might
openm
in
your
browser.
From
what
we’ve
heard,
the
ransoms
demanded
are
in
Bitcoin,
but
vary
both
in
the
exact
amount
and
the
wallet
ID
they’re
to
be
paid
into,
perhaps
to
avoid
creating
obvious
payment
patterns
in
the
BTC
blockchain.
However,
it
seems
that
the
blackmail
payment
is
typically
set
at
about
BTC
2,
currently
just
under
US$50,000.
LEARN
MORE:
PAYMENT
PATTERNS
IN
THE
BLOCKCHAIN
Click-and-drag
on
the
soundwaves
below
to
skip
to
any
point.
You
can
also
listen
directly
on
Soundcloud.
The
encryptor
in
brief
The
encrypt
program
is,
effectively,
a
standalone,
one-file-at-a-time
scrambling
tool.
Given
how
it
works,
however,
there
is
no
conceivable
legitimate
purpose
for
this
file.
Presumably
to
save
time
while
encrypting,
given
that
virtual
machine
images
are
typically
many
gigabytes,
or
even
terabytes,
in
size,
the
program
can
be
given
parameters
that
tell
it
to
scramble
some
chunks
of
the
file,
while
leaving
the
rest
alone.
Loosely
speaking,
the
malware
does
its
dirty
work
with
a
function
called
encrypt_simple()
(in
fact,
it’s
not
simple
at
all,
because
it
encrypts
in
a
complicated
way
that
no
genuine
security
program
would
ever
use),
which
goes
something
like
this.
The
values
of
FILENAME
PEMFILE
M
and
N
below
can
be
specified
at
runtime
on
the
command
line.
Note
that
the
malware
contains
its
own
implementation
of
the
Sosemanuk
cipher
algorithm,
though
it
relies
on
OpenSSL
for
the
random
numbers
it
uses,
and
for
the
RSA
public-key
processing
it
does:
-
Generate
PUBKEY
an
RSA
public
key,
by
reading
in
PEMFILE -
Generate
RNDKEY
a
random,
32-byte
symmetric
encryption
key. -
Go
to
the
beginning
of
FILENAME -
Read
in
M
megabytes
from
FILENAME -
Scramble
that
data
using
the
Sosemanuk
stream
cipher
with
RNDKEY -
Overwrite
those
same
M
megabytes
in
the
file
with
the
encrypted
data. -
Jump
forwards
N
megabytes
in
the
file. -
GOTO
4
if
there
is
any
data
left
to
sramble. -
Jump
to
the
end
of
FILENAME -
Use
RSA
public
key
encyption
to
scramble
RNDKEY
using
PUBKEY -
Append
the
scrambled
decryption
key
to
FILENAME
In
the
script
file
we
looked
at,
where
the
attackers
invoke
the
encrypt
program,
they
seem
to
have
chosen
M
to
be
1MByte,
and
N
to
be
99Mbytes,
so
that
they
only
actually
scramble
1%
of
any
files
larger
than
100MBytes.
This
means
they
get
to
inflict
their
damage
quickly,
but
almost
certainly
leave
your
VMs
unusable,
and
very
likely
unrecoverable.
Overwriting
the
first
1MByte
typically
makes
an
image
unbootable,
which
is
bad
enough,
and
scrambling
1%
of
the
rest
of
the
image,
with
the
damage
distributed
throughout
the
file,
represents
a
huge
amount
of
corruption.
That
degree
of
corruption
might
leave
some
original
data
that
you
could
extract
from
the
ruins
of
the
file,
but
probably
not
much,
so
we
don’t
advise
relying
on
the
fact
that
88%
of
the
file
is
“still
OK”
as
any
sort
of
precaution,
because
any
data
you
recover
this
way
should
be
considered
good
luck,
and
not
good
planning.
If
the
crooks
keep
the
private-key
counterpart
to
PUBKEY
secret,
there’s
little
chance
that
you
could
ever
decrypt
RNDKEY
which
means
you
can’t
recover
the
scrambled
parts
of
the
file
yourself.
Thus
the
ransomware
demand.
What
to
do?
Very
simply:
-
Check
you
have
the
needed
patches.
Even
if
you
“know”
you
did
them
right
back
when
they
first
came
out,
check
again
to
make
sure.
You
often
only
need
to
leave
one
hole
to
give
attackers
a
beachhead
to
get
in. -
Revisit
your
backup
processes.
Make
sure
that
you
have
a
reliable
and
effective
way
to
recover
lost
data
in
a
reasonable
time
if
disaster
should
strike,
whether
from
ransomware
or
not.
Don’t
wait
until
after
a
ransomware
attack
to
discover
that
you
are
stuck
with
the
dilemma
of
paying
up
anyway
because
you
haven’t
practised
restoring
and
can’t
do
it
efficiently
enough. -
If
you
aren’t
sure
or
don’t
have
time,
ask
for
help.
Companies
such
as
Sophos
provide
both
XDR
(extended
detection
and
response)
and
MDR
(managed
detection
and
response)
which
can
help
you
go
beyond
simply
waiting
for
signs
of
trouble
to
pop
up
on
your
dashboard.
It’s
not
a
copout
to
ask
for
help
from
someone
else,
especially
if
the
alternative
is
simply
never
having
time
to
catch
up
on
your
own.
About Author
