[Music]
yes two o'clock let's start just in time
very welcome to this afternoon session
and i'm very happy to be able to welcome
archaean hollop from cisco he's a senior
security analyst with the
cisco umbrella
intelligence uh
threat intelligence team it is yeah
and it's always nice to have an umbrella
cisco otherwise especially in this
rainy city
there'll be a five-minute
opportunity for questions and and
answers in the end of the presentation
but
take it away jim
uh hello everybody and uh
welcome everyone
thank you all for coming
as
moderator mentioned i work for cisco
umbrella as a senior security analyst on
the threat intelligence team
and today
i'll talk about a few recent attacks uh
where the end result was ransomware
and uh we'll talk about where dns was
involved in these attacks and how we can
use that knowledge to
improve our security using dns as a
additional layer of security
so
to start
we want to talk about the data gathering
so in this example the perfect place to
collect data is within the recursive dns
in in the case who is getting data from
the recursive dns we will work with two
data sets one will be coming from our
users sending the queries to the
recursive dns server and the second one
will be from upstream authoritative
servers
with first data set we have the
opportunity to identify
compromised systems common and control
callbacks
and so on we also can write specific
algorithms that to identify some
specific data that we want to identify
with our observations with the second
data set we can get insights into newly
staged malicious infrastructures
and the malicious components that actors
use to attack the networks
so today the main focus will be the dns
tunneling adoption by quite few
malicious actors and the different
utilization of this technique both for
common and control and data exfiltration
so dns tunneling isn't entirely new
technique it's been around for quite a
while it's been used for legitimate
purposes
however what we
worry about as the network owner is
something like i.t policy avoidance
guest wi-fi abuse or some
you know similar activities but what
even more important is that we witnessed
an increase in use of this technique by
multiple threat actors in the ransomware
space
uh they were involved in high profile
attacks including supply chain
compromise
as well as ransomware
so whenever we talk about using dns as a
cover channel
for
either common and control communication
or data exfiltration we talk about data
encoding
data can be encoded in multiple ways and
transferred through dns channel in
probably million different variations
and that's the exact reason why it's not
easy to detect with common security
controls it's highly
customizable and thus requires somewhat
complex approaches in detection
so in a few examples that i showed you
we've seen that the same data was
encoded in either
long
sub-domains
of the domain which controlled by
malicious attacker or smaller chunks of
the
smaller sub-domains but exactly same
data was exfiltrated both in the first
and the second examples
so let's actually look at some of the
recent ransomware attacks that you know
i personally dealt with
ransomware today is greatly different
from ransomware from five
six years ago at that time ransomware
actors just used you know male spam with
direct
access to the ransomware payloads and
the goal was to infect as many users uh
and then get you know as many payments
as possible
however uh you know recently it changed
greatly to a more sophisticated kind of
like apt-style approach
today ransomware is a result of the
multi-stage attack
and if we look at the schema we see that
dns involved in many places of this
attack dns tunneling is also can be
involved in many stages of the attack
we've seen it being used for initial
access by the loaders and we've seen it
being used by the post exploitation
framework and i think the
uh utilization of the cobble strike
framework in uh recent attacks give a
big bump to the use of this technique by
malicious actors
so the first example we will look at the
chachiret it has been observed to
deliver
pisa aka mespinosa ransomware
it actually utilizes two protocols for
c2 communication one is http based ip
common control channel and second one is
dns
the however the primary uh channel that
it relies on is actually dns tunneling
which uses txt queries txt or text
records were originally intended to
allow domain
owners to add additional data
within the dns request
such as domain ownership or network
or server information and since you can
pack somewhat large amount of data in
this record it start being utilized by
malicious actors uh over and over
so uh chachi is pre-configured with a
list of c2 domains
as well as ap addresses for failover
http cnc protocol the domains are
encoded in obfuscated binary
and the dedicated function will carry
out sort defuscation to identify the
domain to the round of a random ship
challenge
so
when the domain is identified chachi can
now initiate the connection to a situ
infrastructure
rather than implement the completely new
dns stunning protocol for the purpose of
communication malicious actors used
of the shell
reverse
dns based reverse shell component which
called the cha shell
however they are not using it completely
as it comes of the shell they modified
it because
they all know that you know one way
we build our defenses is that we look at
the open source tools or of the shell
tools that let us do something like a
reverse shell and then a lot of the
companies and security products will
have that detection built in by default
however if you modified it a high no
you if you modified it it become a lot
more
complex and it's different enough to
bypass those origin
detections
so uh
now char shell operates as the common
and control channel rather than a
reverse shell itself
and
it the way it does it is that all of the
data that malicious actor want to send
back and forth is serialized into the
protocol buffers before encrypting
using the symmetric encryption
this encrypted data is then hex encoded
and packed into the txt query the
response to the txt query is also
subject to the protocol buffer
serialization encryption and hex
decoding
so another thing that
chacharet authors modified within the
shell is that uh
parts of the message that they use uh to
operate uh as a common and control
channel
so
the main point of the of
this particular message is the chunk
data
those are the messages that
will be encoded prior to
serialization of the data
into a protocol buffer
and it will be performed in two steps
step one will involve base64 encoding
the data and then it will be passed to
the function that performs sore encoding
using a hard-coded string
so you can imagine that with this
approach the end result that we see on
the wire as the dns request going back
and forward looks just like some kind of
dji-based
command not necessarily common in
control but
from a lot of the advertising networks
uh things like cdns
the way data is encoded is very similar
so without knowing what actually is
encoding within that string it's really
hard to determine if that some kind of
malicious communication or just regular
communication by you know one of the
browsers trying to fetch information
from one of the cdns
however and
the end result of the pisa
of the chacheret activity
is the
pisa or
mespinosa ransomware payload
so next thing is the
timeline of the quantum ransomware in
this case it started with someone in the
affected network opening a male spam
which contained an iced id loader
and as we can see it took only four
hours for the malicious actor to
initially identify that you know their
payload was executed
then get into the network establish the
access get through the entire network
via lateral movement identify the
information they needed to launch the
encryption and within four hours the
quantum ransomware was deployed and took
the entire network hostage
what's important on this slide is that
we can see that the cobalt strike
framework was used in multiple parts of
the attack chain it was uh used as a
common in control
uh
by the common control to be injected
into the network and then it was
executed on the server where it
performed both lateral movement and the
end up
operation payload which was a quantum
ransomware
and the reason why we see uh cobalt
strike being used quite a lot is the
possibility of the dns based beaconing
their dns based beaconing isn't
different from what you would expect
from the dns standing operation it
starts with the infected machine which
sends a dns request to the local dns
server and then it goes upstream up to
the point where it reaches the
server controlled by the actor when the
actor got their beaconing out to their
server they pretty much have the full
control of the
end point and then they can carry out
all kind of malicious activities but
what we usually see is that profiling of
the network comes first so they want to
identify what kind of network they have
access to second one is depending on
what kind of network the tools will be
deployed a lot of the tools i embedded
within the kobold strike framework and
then when they
identify all of the weak points of the
network they perform the lateral
movement they
exfiltrated the data to use it in the
double extortion schemas which means
that even if you don't want or you can't
pay for the
decryption of data or you have a really
good ir and backup
solutions you still can lose the data
that the malicious actor got access in
the first place and then the data can be
either weaponized against your company
or against that affected network or it
can be sold on the darknet forums for
monetization purposes
uh
within the last two years from the
ransomware attacks i witnessed we
identified that 78 of them were using
kobe strike framework in most of them
dns beaconing was utilized and the
reason is that once again there is like
no http based communication so it
directly bypasses a lot of the security
controls
second is that
the beacon can be
configured with mulable c2 configuration
so you can deploy multiple beacons
within the same frame within the same
network right and see which ones were
actually blocked so they would never get
out to the exim server or the ones that
actually got out so when you see the one
that actually made it you know what kind
of in encoding or multiple c2
configuration you need to use to carry
out the rest of your
malicious activity
so next we want to uh have a good
understanding of how the beacon is
configured so the start of it will be
uh the
type of the payload and we see that this
is a dns based beaconing the second one
is the malicious domain which actor
actually has the full control of and
then we have a set of
different configurations that will
that can be used by the malicious
attacker depending on which ones are
more or less likely to be detected
within the network
so this is an example of the multiple c2
configuration as we can see
the
different settings for
those fields that i mentioned on the
last slide at the bottom of the slide
they look completely different in this
one right and it's not really something
that you have to use out of the box it's
something that you can modify yourself
so you probably have millions of
different configurations that the
malicious actor can use and
you can't really design a standalone
signature for you know to include all of
them so you have to uh you know have
different approaches to identify this
kind of malicious traffic be able to
detect it and stop it
so next we can see a wireshark view of
the cobble strike dns traffic
as you can see all of the data
just
using the dns protocol
right here
right and then in this case they are
kind of like for
demonstration purposes uh
they were used like all types of the
encoding uh but in uh usually what you
see in the real attacks is that this is
just the initial then they see which one
actually getting through and then they
will use the one that is uh you know
more reliable and uh requires uh less
activity on the wire to be able to stay
undetected as long as possible
so uh here we can see the dns beacon
queries and replies based on the
using the a records as their main mean
of the configuration
and
at regular intervals
which you can determine in the settings
so it's not one you know set and go so
you know that if you're dealing with a
cobble strike beacon you kind of expect
it like every two seconds or every three
seconds no they actually can modify it
within the you know standalone or they
can modify it with the each iteration so
once again even like uh you know some
kind of like time series analysis can be
defeated by
a complex enough uh design dns beacon
however in this case we see that the
first
response will always be an a record and
that's needed to determine what kind of
uh data payload will be used because
even with the cobalt strike framework
you can't overcome some of the basic
features and one of them is that initial
identification of the buffer of the data
that will be used in the attack
without knowing the buffer data you
can't really carry out the rest of the
actions however if that one passed
and you know if you deal with any kind
of the network traffic analysis that
that's pretty benign you just see
one dns request and you see an ip
address what you will kind of expect
from a normal dns resolution what you
might miss is actually that tells the
team server how big chunk of data it
needs to expect to decode it
and in this case
uh
they are using the a records and then if
we look at the
subdomain structure
the origin the start of the the first
sub domain will be the beacon uh
identification of the idea they call it
and this one is actually
needed for team server to identify which
beacon is actually being able to get out
of the network so once again you can
deploy multiple
beacons and then based on the id which
you get on your team server you will
proceed with the proper communication
method
so next one is the possible dns beacon
replies so here we can see that you can
choose any modes
that are
configured by default and either dns dns
with txt records something that
charshell was using or
quad a records
next we'll take a a closer look at one
of the
txt query records
it's very familiar as i mentioned before
it will start with the first response
which represented as the ip address but
after a series of the encoding and
decoding on the team server it will
identify the buffer of the data which
team server expected to get from the
compromised network
i noticed that
the start of the query now is just api
api tells the
or whatever
subdomain they choose
for
txt based communication will be
under understood by will be understand
by the
team server and then they will expect
txt records to contain the data that
they need to decode on the team server
so the value of each txt record is the
base64 string that
needs to be concatenated before decoding
in this case it's only 64 bytes but it
can go
up all to 128 bytes
and then
it needs to understand how to
concatenate the data and also it needs
to avoid caching by the local dns
resolver so to overcome them they
implement a
counter which you can see as the uh
in this case one two three four like
second level sub domain it will be
increased every time and the sequence is
increased and then on the team server
you just put them in the right order to
get the full message
next one is
and
usually what we've seen is that
malicious actors love to rely on the txt
record just because how much data you
can put in a single message however a
lot of the products are able to identify
uh encoded
you know
data in the txt messages and that
communication will be blocked so the
next attempt will be
you know dns a queries
so in this case once again the first one
is the ip which represents the amount of
data that will be
communicated on the wire then we have a
label which in this case is cdn
to show that
the
payload will be within the
a record
and then
the
the rest of the sub domains will be
kind of the same what we've seen in the
first one where you have the
counter the bid identification and the
data which will be encrypted within the
a record
and the last one is the
quad a or no this one is actual beacon
sending results to the team server with
the dns output
and uh
in this example that the query starts
with the
top label post of the
post and then
all of the
and and the data will be transmitted
with once again a unique hexadecimal
counter just like any other queries
we've seen before
and then at the end of the
at the bottom of the screen we can see
how the name breaks down
uh on the team server so the post is the
type of the query output we expected 140
will be transmitted data
the
another
subdomain is the counter and random
number then our beacon id and then the
domain chosen by the operator
so this is great now we have the idea
how different
malicious tools are being
utilized within the attack framework and
how their dns traffic
looks
so in this case
we want to apply several approaches the
first one is kind of like white listing
approach that's where we want to block
any domain that we don't really have any
prior knowledge about as you can imagine
this is very complex
approach if you just put it in place and
you know just let it run it will acquire
tons of fps and your customers probably
will be crazy
however if you have a good understanding
of your network and you know what
critical parts of the network
have specific
dns based activity
you can apply it to the segmented
networks and then only block it to let's
say you have a server which only purpose
have updates for you know several uh
software stack that it uses right so
while you can study it and identify
those uh regular dns requests anything
that will be derived from that or
different from what you've seen before
will be blocked and passed for the
expansion and inspection can be done
either by automated engines or you can
actually escalate it to your stock
analyst who can make you know a much
more informed decision
so with this approach for example
we got a domain that was identified as
newly seen and then we pass it for the
inspection to our sock analyst so what
usually sock analyst does it looks at
the open source intelligence one of the
biggest repositories of such
intelligence is virus total but in this
case uh virus total has no idea what
this domain does and what it represents
so it just marks it as you know no
security vendors flagged it where is
visited and 11 days later and we can see
that only i believe eight different
vendors flagged that domain as malicious
however during our investigation when we
visit the domain we were able to
download the file we run files through
virustotal once again and we see that
well three engines are able to detect it
as malicious which means that if you use
any other engine in your network and
your user actually visited that domain
most likely that payload was able to
execute and now you might have problem
in your network
and if we run that
payload through the
sandbox we can see that it is actually a
bazaar
bazaar backdoor payload which is often
associated with the ransomware attacks
so this kind of the category we
developed and called it as newly seen
domain in cisco umbrella you know you
can just call it new new domains or new
domains for your specific
segment of the network
and it can be incorporated into more
broader analysis right so if you have
some kind of the chip engine which makes
a decision what to allow what to block
uh something that being downloaded
launched or retrieved from this kind of
newly seen domain
should probably be blocked and inspected
either by automated engines or by a
stock analyst to have a much better
decision-making process
so the next step is actually design the
detection for the dns tunneling
so
as we've seen before with uh out of the
box solutions uh not that many of them
actually designed to identify malicious
payload within the dns record so you
have to build something that will be
able to identify it just with the data
on the wire that you can get from the
dns query
so you can use three different
approaches right
uh one approach is uh
uh what we call the reactive right so
you collect the logs from your
recursive dns
uh resolver or you know any other means
that you like more to uh you know to use
and then you run a series of your
algorithms that will detect which
domains are more or less likely to be
dns tunneling
while you are not using it proactively
so some communication can get through at
least you can identify that something in
your network exhibits this behavior and
you can launch a propriet
the right way of the ir
however uh the
better way to
do that is what we call a real-time
blocks however real-time blocks will
require some kind of the security
solution
or the actual reserve resolver to be
able these decisions uh you know on the
fly so what you do is that after you
inspected let's say open source tools or
some proprietary tools or you know any
kind of like dns tunneling data set you
can derive your signatures and a set of
rules that are triggered when a specific
combination of uh
data is seen
in the dns a query or within the dns
resolution
so this is somewhat
complex because it required the prior
knowledge of your good data and your bad
data
in our case we design it kind of like a
modular approach where you have a set of
rules that easily expandable and it also
can work a little bit better with a
little bit more complex
identifications something like
a markov model so you can deploy an
algorithm that looks at the data which
being run within the
query resolution pattern and then try to
predict how
big of a chance that that particular
data is a contained actionable
actionable data in terms of
if it can can contain payload
so if you would tasked with designing
this kind of defense
where do you start so as i mentioned
before the best uh
the best place to start collecting the
data is your recursive dns resolver
and then what you want to do is that you
want to go out there identify the open
source tools for
you know either gene essex filtration or
common and control
uh common control using the
dns as a cover channel right so you run
the tools you collect the data set that
you will be analyzing the second
approach that you want to do is uh
identify encoding techniques would it be
base 64 base 32 and then you want
to be sure that whatever you're
designing not just looks at the
subdomains but also looks as a different
query characteristics would it be q type
like txt srv mx or cname and then with
that data set you apply some
informational
theory trying to identify encoded or
encrypted data and then make a decision
so in the case with cisco umbrella the
way we
actually implemented this kind of
protection is within the resolver so
what we did is that
you know we had this they call it like
smart cache for a while but basically
it's just the technology that let us uh
cache frequently requested dns records
and then build the pairs of the request
and the response
and then when some of the trigger rules
are
actually within the resolver are
triggered the resolvers start looking
not in just one pair of the
resolution
query response it actually looks at the
whole session of them and as it looks at
the session it can apply more and more
deeper inspection uh would it be based
on the behavioral characteristics of the
pattern or the signatures that we
implemented
and when one of the resolvers is
actually able to identify such
uh
which means able to identify dns
tunneling in the process it actually
flags it blocks it and then puts it
upstream so it can go to the whole fleet
of the resolvers everywhere in the world
so
being able to identify maliciousness at
the gns layer is amazing
however malicious actors and their ttps
are consistently evolving and to be
protected from the ransomware you have
to apply
approach where you look at your network
layer by layer and then at the proper
layers you apply proper security
controls and make sure you can detect
all of the ttps that are used by
malicious actors
uh you know either using your own threat
platform or open source intelligence or
the knowledge that gathered by your sock
team
and now i will take your questions
thank you archer
[Applause]
yes we have a microphone over there and
one here
who will
ask the first question
i have five minutes
time enough for
a couple of questions anyone
well if you don't have any questions
right now you can
follow me on twitter i believe
my twitter handle should be somewhere in
the marketing
and
yeah you can reach out on the twitter
probably will be the fastest way and i
can answer any questions you might have
after some time
yes
okay
let's
thank you once more give him an applause
for this
interesting presentation
right thank you very much for having me
you