(angelic synthesizer
pad fades in) (low-pitched hum crashes
and then fades out) (audience applauds) - So I'm Josh Bryant,
like you said, I'm a Director of Technical
Account Management at Tanium. - And I'm Robert Falcone,
I'm a Threat Researcher over at Palo Alto
networks on Unit 42. - And today we're gonna
talk about web shells. Why web shells? Well, this is what U.S.
Cert had to say about it a few years ago. They've been around
a really long time, probably since the
creation of the web, and the tactics are just
getting better and better and we're finding
more and more of 'em. - Yeah, so, this is what we're
gonna be talking about today, is these web shells, okay? There's so many out
there, it's unbelievable. So you can go to
Github repositories and find hundreds of these
just easily accessible. And they range dramatically
in capabilities. But the reason why
they're really important is because of the
access that they provide to the web server. Whether it be running
commands specifically, uploading, downloading
files, that kind of thing. And like I said, they're
very easy to obtain, so in a lot of cases, actors
don't have to build their own. So, the one web shell
that we're gonna be talking about today is
not one of those web shells that you can freely
grab off the Internet. This is a custom-built web shell that an adversary was
using, they developed it to be used in their
campaigns in the Middle East. And me and my colleague
named it TwoFace, because of the
unique design which they used to develop it. - And as Rob was
mentioning, this is the one that I showed at this
very conference last year, however, at the time, I
couldn't find a name for it. I could've sworn, I can't
possibly be the first one to come across this,
still probably wasn't, we just happened to be
doing the same research from a couple different
angles at the same time. And we're able to come
together to kind of update this and give you guys
some new information. - Yep, so I named it. It's a silly name,
but it was named because there's two
layers to it, okay? The first layer is a loader. It does, its whole
big responsibility is to install the second layer, which is the TwoFace payload. And we're gonna talk
about this in detail going through this talk. So, what's the loader? Like I said, its purpose is
to install the second layer, which is the payload. But, what they did was,
the actors actually took their loader code
and appended it to legitimate content
on that web server. In this case, I chose one
that was a news article on an IIS server,
but what Josh and I are gonna talk about
throughout this presentation, they also appended it to error
messages on Exchange servers. So they're really focused
on Exchange servers. Okay, so the loader, the
actor, when they wanna start interacting with the web shell, they send a specific POST
request to the loader, which installs the
payload, that second layer I just mentioned. As you can see on this slide, this is where all the capability
exists for this payload, for this web shell. It's pretty capable,
upload, download files, execute commands,
timestomp files. You can even run SQL queries
on remote SQL servers. But one thing I
should focus on here is that you have to
authenticate to this web shell to actually be able
to use this thing. So you can't just
find this web shell and start interacting with
it without that password, which is really important. So, how does the actor
actually interact with this web shell? How did they construct the
POST request to the loader to install the payload? Well, the actor will
provide a 64-byte key, which is fairly massive, right? The loader will actually
manipulate that key with a key salt, so
that's pretty clever, and then the result of
that is gonna be used to decrypt the embedded
payload web shell, and then that's saved
to the web server. And, so that's
the whole process. And I felt like that,
you really need to see it to believe what that process is. So I made a demo video, okay? Like I said, we're gonna talk
about Exchange primarily, but they also had
one sample that I'm gonna show you right now
that ran specifically on IIS. So for simplicity, I
just chose that sample, and I set up an IIS server just to show you how it works. - Yeah, it's important to
note that IIS is a dependency of Exchange, so there's not
too much of a difference here. - Yep, so here I'm just
showing you in this video, I just set up a
simple web server, and I'm showing you
that this web server, the only thing
that's hosted on it, is the TwoFace loader
that I named TwoFace.aspx, right there, okay? We're gonna hop over
into the browser and just browse to it, okay? And what you're gonna see
is something very similar to what you saw on
the slides there, you're gonna see a news article that was meant to be
on that web server. There it is. But, if the actor wanted to
actually use the web shell, they're gonna have to
instruct the loader to install the payload, so I wrote a script to be
able to do that myself. So here's the key
that's required to install this
particular payload. So I'm gonna run my script,
which is gonna craft the correct HTTP request,
which is gonna send the key over with the
filename to drop it to. There it goes. The TwoFace loader
responded back, saying, yep, I
installed the payload. And we're gonna hop back
over to the IIS server. I'm gonna show you that this
new file called drop.aspx is gonna be on the
IIS server as well. There it is right there. So if we navigate to
that in the browser, that's where you're gonna
see the functional web shell for TwoFace right here. It's a little bit
different than the one you saw in the slides, but
very similar variation. So right now I'm trying to
just run a command, whoami, in this web shell. It didn't work, 'cause
I had to authenticate. You can see that that
bar at the top is red, and when I authenticated
it turned green. And now I run the whoami
command and it worked perfect. So we're gonna talk about
TwoFace in-depth coming up, and exactly what the actor
was running command-wise. So when you see us talking
about running commands and doing things using
TwoFace, think of the actor actually interacting with
something like this, okay? So, from a hunting perspective, how did we go about
hunting TwoFace and the web shells themselves? As a threat researcher, I
rely a lot on YARA rules and other kind of
detection signatures, so we had to write them, right? But the whole purpose of
the two layers for TwoFace was that the loader
layer's very obfuscated. It's difficult to detect. So, what did we have to do? We had to figure out how
to detect the payload that's embedded
within the loader. So, how did we do that? Well, we took a look at the
actual decryption mechanism within the loader, and we found, this is how they
applied the key salt to the 64-byte key, and then
they used that resulting value as the key to decrypt
the embedded payload. And I don't know if
there's anyone in here that studies ciphers,
but this is probably the weakest cipher in the
history of cryptography. They're using addition
and subtraction, so we can easily
just reverse that, and we wrote a simple script
to do a crypto attack on it, and we were able to
find the 64-byte key, and then we were able
to write some YARA rules for the payload, because we
now have the cleartext, okay? So, from a threat researcher,
that's how I went about digging through our content,
by writing YARA signatures, or YARA rules, to hunt
for these payloads. - Alright, now that we
have seen a little bit about what web shells
are, how they work, and how this attacker was using
it, it's time to go hunting. And if you've maybe
been living under a rock for the past few
years, or haven't gone to a few other conferences,
you may have missed the fact that attackers
think in graphs. When I go hunting, I wanna
think like a bad guy, so I need to think in graphs
to be successful in my hunt. So let's look at how an
attacker might get the web shell on to the target, on
to the Exchange server. So here I've created
a couple different attack graph scenarios. The first one I call here
is the Attacker's Hope. This is how the attacker
wishes it worked. It's plausible but not likely, it may also be how
your management might think this
type of attack works. So here our admin uses
Domain Admin everywhere, he's never heard of
credential hygiene. He just logs in with
his Domain Admin cred, so everybody gets in, in fact if you all look under
your seats right now, you've all got Domain Admins. So now our attacker
is going to attempt to directly compromise
the Exchange server. He's gonna try a few
different techniques. This is standard for implanting
any kind of web shell on any server, however,
these techniques tend not to work on Exchange servers. There's no SQL in Exchange, so SQL injection's
not gonna work. There might be a
remote file inclusion, that's probably not gonna work. You might have some
cross-site scripting. Again, plausible, probably
not gonna do anything. Might have local file
inclusion, they're gonna try it, probably not gonna
work in this instance. Our most likely culprit is
gonna be remote code execution. I could not find any remote
code execution vulnerabilities in Exchange itself,
there have been some in the underlying
IIS in the past, but if you have a fairly
up-to-date system, unlikely here as well. But here they're gonna use
the remote code execution, get access to the
Exchange server, and because our Domain
Admin uses creds everywhere, he's gonna go ahead and
run Mimikatz, not a virus, and dump creds and then use that to gain access to the
rest of the environment. So now let's look at a
more likely scenario. Here our attacker starts
by sending an email to their target. Our user here loves
email, loves attachments, needs to enable macros,
and because they just love to run macros,
they go ahead and run it. Now our attacker has
gained a foothold into the environment, but they
need elevated permissions. This scenario, we're
a little bit better at our credential hygienes,
we haven't exposed our Domain Admin creds
to this endpoint. So it's gonna cause a little
havoc, induce a Help Desk call. Our Help Desk just
wanting to do good here logs in with their admin
credentials on to this box, allowing our attacker
to gain access to a file server
that the Help Desk just happened to be
admin of as well. However, he was not
an Exchange admin, so we're kinda going in
a roundabout path here to make our way to
the Exchange server. Here our attacker finds a
misconfiguration in Exchange, he didn't have to exploit
any vulnerabilities here. He's able to directly
access the file system, and drop the web shell payload
on to the Exchange server. So from there, because Exchange
is 99% of a Domain Admin, he doesn't even need to bother
trying going after that. Remember, Domain Admin is
never the goal of the attacker, he's after the data. Exchange is a high-value target, it stores a lot of
information in it, and from there he can
modify other groups and objects in AD to
give himself access to these other sources of
data that they're truly after. So some time later,
our security team gets a virus alert
because one of the tools got uploaded to
VirusTotal and we finally got some signatures on it. So our security team comes in, and he just cleans up
everything that he got a virus alert on, because
they're not really doing any true threat hunting
here, they're just doing that reactive stuff where they're
just responding to alerts. Now you'll notice
that there's one thing on this slide that our
security guy didn't find, and it's that web shell
hiding on the Exchange server. Which brings us to our
last scenario here, which I call Return
of the Attacker. Because we missed the web
shell on the Exchange server, our attacker can
immediately come back in, and now he's a little mad
and wants better access than he had before, so he goes
after the Domain Admin creds this time and regains complete
control of the environment. - So, Josh gave some
really good scenarios there with the attack graphs. I'm gonna actually talk about
a little bit of the commands that we saw during my team's
research efforts on this, in regards to what
the adversary did with their access
to that network. So, I really, really wanted
to make a pew-pew map, so we're gonna start talking
about, geographically, where the actors were carrying
out these activities from. And it just gives a
little bit of a high-level insight into what
they were doing. So, going back to June 16, 2016- - Pew!
- I know this is, I know this is timely and
pertinent information, but back on June 16, we
saw the first activity from this specific
adversary on this network. And what they did was, you can
see that little orange server down in the bottom-right
corner here. That is our Exchange
server, okay? And what the adversary
did on June 16 was, they actually used
legitimate credentials to log in to Outlook,
specifically OWA. And they actually used
an IP address from Iran, from all places. - So this kinda lines
up with the scenarios that we're just going to. Obviously they had already
obtained credentials into the environment,
they weren't exploiting something on the
Exchange server first, they're using what
they got to get in. - Yup. The next day, they also
logged into the Exchange server from the same IP address, and then the next
day, on June 18, that's when we start
seeing this adversary using the TwoFace
web shell to interact with the Exchange
server specifically. Fast-forward a couple
months later in September, we saw this adversary
log in, I'm sorry, use TwoFace to run six commands from an IP address in France. And then again, from France,
running 16 commands in March. And then, I really wish
we had pew-pew noises. - Pew-pew!
- 61 commands they ran in April, and then
finally in May 2017, we saw the last activity,
which was 10 commands run from an IP
address in Germany. So you can see that
this threat group has at least the
foresight to know that some sort of forensic
analyst is gonna see where all these activities
are coming from, and to try to cloak where
they're originating from. So, let's kinda
dig into each one of those dotted lines there, what they did with
their access, okay? So, like I said, on
June 16, they used legitimate credentials
to log into OWA. So what did they do? So they immediately opened
up the address book, and they looked through 15
different distribution lists, and over the course
of a couple hours they looked through 81
different user accounts, okay? So that's pretty interesting,
why did they do that? Well, what they
did was, they used one of those
distribution lists that at this organization was
called Network Support, and they sent an email to them. The subject was
Network Team Support. Now, we don't know what
the attachment was, and we don't know what the
content of the message was, but if you think about
that distribution list and the people that are probably
on that distribution list, they probably have some
pretty decent access to the rest of the network. - [Josh] What better way
than to phish your target by making the email come
from with inside the domain? - [Robert] Yep, pretty clever. So unfortunately, we don't
know how they did it, but that is likely what
they did right here. So, I said again they logged
into the Exchange server the next day, but this time
they didn't do anything with emails or
anything like that. They actually went
and downloaded what they called the offline
address book from Outlook. So they used Outlook to
just download this file that contains the address book, probably for some offline
processing or data retention, so they don't have
to keep interacting with the Exchange server
to look through these- - [Josh] Lot of
valuable information they can get out of here,
so it's gonna have not only the email addresses of
everybody in the organization, it's also gonna have
any external contacts they had stored in there. But phone numbers,
addresses, office locations, and possibly some of their
organization structure. They can see who's
a manager of who depending on what
attributes they've populated on these accounts. - [Robert] Yeah, and imagine
doing data exfiltration as an actor using
something like Outlook, that's pretty awesome. So, the next day is when
we saw the first activity using this web shell, okay? So, remember I said
that there was a loader and a payload layer to TwoFace. In the top-left
corner of this slide you can see this
URL, error2.aspx is the file that they're
interacting with. - [Josh] That's a
legitimate page in Exchange, that's the actual error page
that Exchange 2010 uses. So they're appending the
code to a legitimate file on the server to
act as their loader. - [Robert] Yep, and then what
they're doing with that loader is they're using it to install
the payload at error3.aspx, and, I mean, if there's an
error2.aspx that's legitimate, there's probably an error3.aspx
legitimate file as well. - [Josh] Right, if you're
not paying close attention, this is something
that you might miss. Especially if
you're not familiar with the application itself and
what's supposed to be there. - [Robert] Error3
doesn't exist, does it? - It does not exist.
- Okay, good. So, with this access,
they run one command, and one command alone, and
it's this whoami command. So we actually think
that they just did this to see what account
they had access to, or if the TwoFace payload-
- Fun fact, that account would be system.
- Yes, it is definitely system.
- 'Cause this runs in the system contacts. - [Robert] So, now, they
know that their web shell is successfully deployed, and
they don't do anything else, they just kind of,
they don't do anything. So fast forward about two
months, two and a half months, we start seeing this
adversary use the web shell to do some more
interesting stuff, okay? So the first that
they do is they upload this executable, m64.exe,
using the web shell, and then they run it with
very specific parameters. Now, if you look at
those parameters, you can probably
tell what this is. This is Mimikatz. - [Josh] Yep, and if you've
never seen somebody run Mimikatz on an Exchange
server specifically, if run and running
OWA, it's pretty much like cracking open
a credential pinata. There's credentials spilling
out all over the place. - [Robert] Yep, so,
and what they did was they outputted this information
into a text file, 01.txt, and then they exfiltrate
that data using the web shell by using the type command. And in Windows, that just
displays the contents of a file, they copy-and-paste it
from their web shell to their own system,
and they've exfiltrated the credentials, so
it's pretty clever. Then they clean up after
themselves by just deleting the text file, the executable,
and the TwoFace payload from the server to
clean up their tracks. Okay, jump six months into
the future to March 3, 2017. This is where we
start seeing them doing some pivoting activity
using the web shell. So the first thing that they do is they run this
net group command looking for Exchange
Trusted Subsystem. - [Josh] And that's a
really powerful group. That is what makes an Exchange
server pretty much 99% of a Domain Admin,
that group has rights to do almost anything
in Active Directory. It typically is only gonna
have the Exchange server computer objects as a member. If you see anything else besides an Exchange server computer
object in that group, that means something's wrong. Sometimes organizations will
put people in there by mistake, but definitely
worth investigate. - So what that command does, is it gives you a list
of all of the hostnames for Exchange servers
on the network, okay? So what the actor did after that was they just started
trying to find where Outlook's
content is being hosted for OWA and those
kind of services on these remote
Exchange servers. - You can kind of
tell that they knew exactly what they
were looking for here, because they're enumerating
a very specific path. This indicates that their
target was Exchange 2010. - Yep, and so what they did was, when they found that path,
they uploaded another web shell to the current web shell
called Exchange.aspx. Then what they did was,
they just timestomped it to match the same timestamps as a legitimate
file in Exchange. And this one specifically
was Exchange.asmx. - Yeah, asmx is a legit file, that's where the
Exchange web service is, kind of like an API
interface for Exchange. And, pretty clever,
it's one letter off in the extension, so again,
something you might miss, especially if you're just
looking through some log files. - Yep, so, after
they timestomped it, what they did was that's
when they started doing their lateral movement. They used the copy command,
that's all they did, they just copied
that new web shell over to the other
Exchange servers that were, which
were discovered using that net group exchange
Trusted Subsystem. - Yep, and that Exchange
Trusted Subsystem has to be a local administrator
on every Exchange server in order for
Exchange to function, so that's how
they're very easily able to laterally move between all the Exchange servers
in the environment. - Yep. Finally, before they ended
their activity here in March, they just delete the
payload, the TwoFace payload, and they move on. They come back a couple
months later in April, and what we think happened was, they lost access to
one of the web shells that's hosted on
the Exchange server. And what they did
was, they came back, they ran that same net group
Exchange Trusted Subsystem command to find all of the
Exchange servers on the network, and then they run
the hostname command to figure out where they're at. Which one of those
Exchange servers that they're currently
interacting with. - [Josh] Yeah,
this could've been because of like we showed
in the scenario earlier, that maybe our security
personnel at the
target organization found something and cleaned
up the original web shell, but more than likely
it could have been just that they had to
replace the server because they had a
hardware malfunction or something else
that caused them to replace the Exchange server. - [Robert] Yep, so, after
that what they start doing is they start trying
to list the contents of that specific
path within Exchange on the other four Exchange
servers on the network. And it's telling that
they probably lost access to one of those
with these commands. They immediately try to
ping server number three, and we don't see the
output of this obviously, but it's highly likely
that that didn't succeed. 'Cause then, the
next thing they do, is they try to list the contents or try to access the C: drive
and D: drive on that server, and they weren't
successful, okay? So, what did the actor
do in response to this? They uploaded yet another
web shell to this web shell, and this global.aspx
that they uploaded was just another
variant of TwoFace. And they used the attrib
command to hide it, and then they copied it over to all of the Exchange servers
they still had access to. - [Josh] That global.aspx
is not unique to Exchange, it's actually a part of IIS, it's typically a
hidden file that holds configuration information. It's not always present,
and it's typically not accessible, it's not
served by the web servers. You can't access it
through a browser, generally only
through a file system. - [Robert] So while
they're on the web server, they uploaded another
executable, mom.64, which, again, is Mimikatz. They exfiltrated the output
by using the type command, and then deleted
a bunch of files to clean up after themselves, including the text file,
including the executable, and the TwoFace payload
web shell itself. Okay, so this is the last
activity that we saw, was in May 2017. And we believe we lost
visibility on to this because the organization
that was impacted started doing remediation,
and they actually caught these guys and was able to successfully kick
them off their network. But what we saw them do
before that happened was, they immediately tried to
ping an external IP address, 4.2.2.4, and we think
that they were doing that to see if they could establish
outbound network connections. And immediately after
that, they tried to find Domain Admins on the
network by running this net group command. And again, they upload
another executable, and this one's
MicrosoftUpdate.exe. - [Josh] Yeah, obviously,
these are good guys now. They're trying to patch
this server for them, because they feel
bad for their target. - Yeah, and they're also dumping the credentials while
they're doing that. One other thing that I
should mention, though, and it may have been
kind of lost over, is the names of
the Mimikatz tools that they're uploading
kind of blend in to other Microsoft
executables as well. So they're trying
their best to hide while they're doing all this. So they run that executable, and you can see that the
parameters change a little bit, but again, this is Mimikatz. They're outputting the
credentials to mic.txt, and then exfiltrating it
with the type command. So you can start seeing
that there's a clear trend happening here. Every time they
access the web shell they're dumping
credentials to see if they got anything new, and to expand their
presence on the network. - So now that we've
had our bad guy hat on, let's put our good guy hat on, and take a look at
how we would examine this type of stuff on the
Exchange server itself. The first thing I
need to do is find out where the logs are at. If I'm coming in
and I'm not familiar with the Exchange environment
where I'm doing my hunt, I can whip up the Exchange
management shell here, just a PowerShell module, and run the command here
in the first example. That's gonna tell me where all
of the Exchange servers are, specifically the ones that have
the Client Access role on it which is gonna be what runs OWA. So I know how to focus my hunt. The second command
here is gonna show me where the IIS logs are stored. Now, they're generally gonna
be in the default location, but this will tell
you where they're at if they've been moved, just
quick to run and find out. So once I've gathered my logs, I need to look for some
indicators within those logs. And our first big giveaway
that there's something fishy going on here, is POST operations that
have a low RequestCount. There are very few pages
on an Exchange server that are gonna
have POST, period, and those are gonna
have a very high count because you're gonna have
normal day-to-day users accessing it on a regular
basis, issuing that POST to it. - [Robert] And if you think
about from my pew-pew map, there weren't a lot of
commands that were being run each time they
visited the web shell, so it's likely those
would be kind of exposed. I mean, 61 commands is gonna
be 61 POST requests, right? And that's probably
gonna stand out when you're looking at
other legitimate files that are handling POST
requests in Exchange, that are gonna have
lots and lots and lots and thousands of requests. - [Josh] Now, you
might run into a few false positives here and there, because it's case-sensitive
when it logs, so if you have somebody
that types the URL in in a weird way, they might
trigger a POST count for that, but those will be very
easy to filter out when you're looking
at this here. So the next thing that
we want to look at, will help us focus our hunt, is to pay close
attention to URIs that don't require
authentication. If I'm attacker
putting a web shell on any kind of web server here, I don't want to be blocked
by having to authenticate before I can load the page. I wanna be able to
access it with anonymous so that it comes
right up every time. And then finally, you
wanna look at GET requests that fail, 404 errors. Now, there's bound to
be a few here and there, typically very low on static
applications like Exchange. But the reason I
have this up here is, last year I was investigating
another web shell, and the attackers
had actually modified the logging configuration
on the Exchange server so that it filtered
access to the web shell out of the logs. Now they hid it in
that same error2.aspx, which I would expect
somebody would run into an error eventually, right? You'd have a legitimate
entry in the log for the error page. So what stood out is
there were no entries for the error page at all. So I flipped over and
looked at the 404 errors, and now, because attackers
are humans just like us and make mistakes,
I saw the attacker making typos trying to
access their web shell. That gave 'em away. So once I've gathered
this information, the next thing I wanna look
at is the User Agent String. Now, even in very
large environments where you have hundreds
of thousands of users accessing this
all day and night, the attacker's User Agent
String tends to stand out. This is because
they often use it similar to the 64-byte key
that Robert was talking out, it's a access method
to the web shell. If I connect and my
User Agent String doesn't match the one that
I programmed into the shell, I don't see the shell. This prevents hunters,
legitimate users, from accidentally stumbling
upon the web shell. - [Robert] Yeah, and I can
speak to the User Agent specifically to
this threat group. They love really old
versions of Firefox. Like, many many years
old versions of Firefox. So they kinda stand
out when you're doing this kind of hunting.
- And remember, User Agent Strings
are very easily faked. So, pay close
attention to those. Once you've gathered
your User Agent String, you can use that
to start tracking some of the attacker's activity. So here I'm showing, we
have the User Agent String that connected to the web shell, and then immediately after,
we see the User Agent String accessing OWA itself
and the user account that they used to log into OWA. So now I know my attacker
is using the credentials that they stole to access
this mailbox specifically. Now, there may be a
chance that you could mix up some legitimate use, but to make yourself
extra certain that you are tracking
the attacker activity, you can add in looking
at the ClientId field. This is in Exchange
2013 and later. In earlier versions,
it was session ID. This ID is a unique GUID
that is a server-side representation of the cookie
that the client generates, so it's persistent and unique to the session
that initiated it. So using that, we'll
go in and dig through and find out, okay, what
accounts did my attacker access? I know that I need to put
those on my remediation list and do something about it. Might also help us track
what type of information that they may have taken
out of these mailboxes. One other method, I actually
introduced this last year, it's a PowerShell script
that's basically a wrapper around Jared Atkinson's
PowerForensics, comparing the filetime
in the master file table. So what this does is it
uses the install time on the Active
Directory attribute of the Exchange
server as a baseline. This is the time
that all the files in the install should match. If they don't match,
throw me an alert, as you see here, saying that, hey, this file looks
like it doesn't belong. It works in 2013 and
later only because every update is a full install, so every file will
have the same file time except for anything
that doesn't belong. And with that, I have
one last graph for you. So we use everything that
we learned here today. Here our environment is
already completely compromised. Our security guy asked
for our DFIR help, our DFIR expert comes in and
they start their investigation with the Exchange server. Sometimes you go in for a hunt
and it might be proactive, you don't know where to start. Exchange is a high-value target, it's a really easy
place to start, it's a really easy place
to knock off your list. As you can see, you can just
filter through some logs, run this script, easily find
what you're looking for. So now our DFIR hero comes in, finds those unusual
POST operations we
were talking about, knows that this looks
like a web shell. They go ahead and
clean the web shell up and start tracing the activity of the attacker through
the environment, cleaning up things and
getting the attacker out as we go along. So with that, thank you all. - [Robert] Okay, are we all god? Alright, thanks everyone!
(audience applauds) (mysterious piano music) (sibilant white noise
crashes and fades out)
