SANS DFIR Webcast – Incident Response Event Log Analysis


– [Narrator] Hello everyone
and welcome to today’s webcast, IR Event Log Analysis. My name is Trevor and I will
be moderating this webcast. Today’s featured
speaker is Hal Pomeranz, Deer Run Associates Digital
Forensic Investigator. Please feel free to submit
your questions at any point by using the questions window. Hal will be answering them
throughout the webcast. Right now I’d like to
turn things over to Hal. – [Hal] Hey, everybody
how’s it going? Happy Monday or whatever
time it is wherever you are. Greetings from Central Florida where it’s currently
pissing down rain. But we’re all inside and talking
forensics on the webcast. So you can see my email address and Twitter contact information if you have questions
after the webcast. I haven’t been too active
on social media lately because well I’ve been spending the last eight or nine months doing a lot of IR work
for various companies. I’m happy to say that none
of those investigations have made the news unlike
some of the bigger, more public ones over
the last few months. But generally our
clients like to keep it a little bit under
hush-hush, so to speak. But what I’ve been
finding myself doing a lot during those IRs is
spending a lot of time with Windows event logs. Now you know I mean when
you’re doing an investigation there’s lots and lots
of different things you’ll be looking at right? And some people say, oh you
know like memory forensics is the way to go, or network
forensics is the way to go or registry forensics
is the way to go. That’s the you
know silver bullet that’s gonna solve
all your problems and I think that all of
those things put together as part of a comprehensive
analysis package are good things to do. But even without those things I’m finding that I’m getting
a really good picture of what’s happening in
some of these incidents just by looking at basic
stuff like Windows Event Logs. And so I wanted to pass along some specific areas
where I’ve been finding a lot of gold lately,
particular events to look for, particular event logs
and that kind of thing hoping that it will assist
you with your investigations. By the way if you’re
interested in you know intrusion response
kinds of things I’ll be teaching
SANS Forensics-508 in Baltimore the
first week in March. So if you’re looking
for something to do pre St. Patty’s Day in Baltimore come on out to Baltimore,
it’ll be a nice small class with lots of one-on-one
conversations going on there. Baltimore’s always a good
time, so hope to see you there. Alright, so oh look, we’ve
got the SANS DFIR curriculum and aside from 508 I also teach the Reverse Engineering
Malware Class and our new MAC
Forensic Analysis Class that Sarah put together which
is an awesome class too, by the way, but we’ve
got lots of other classes and free things like
the SANS Forensics Blog and and the SIFT Workstation, yada, yada, yada. Right, so what are we
talking about here today? We’re talking about
Windows Event Logs which on modern Windows
systems live under WindowsSystem32winevtLogs. We’re just gonna
be talking about the modern event logs
from the evtx style logs that started in Vista and later. For 2003 XP vintage machines
of course, they’re EVT logs, there’re similar sorts
of events in those logs but I just wanted to focus
in on the event IDs and logs from newer Windows systems that you’re typically
gonna deal with. And obviously the along with
some sort of binary format you need some special
parser to look at them and there’s tons and
tons of different event log parsing
tools out there, ranging from you know
Python and Perl libraries so you can write your own
scripts to parse event logs. There are command
line event viewers from a variety of
different sources. Then there’s all the
different graphic ones, starting with the
Microsoft Event Viewer, but there’s also some third
party event log parsers. Me personally, you know
I’ll just throw a shout-out to Event Log Explorer
from FSPro Labs which is a nice stand-alone
event log viewer for Windows GUI. Actually Alyssa
Torres pointed me at Event Log Viewer
many years ago and I started using it
and really liked it, but whatever, pick
one that you like. People are always a
little bit leery I think of event log analysis, you know there’s a lot
of different event logs and there’s a billion
different events. They’re all mashed up together and you know unless
somebody sort of shows you you don’t really know
what events to look for. But don’t be fearful actually. I mean there’s a lot
of good stuff in there and if you just sit
down and start looking at the event logs in the
context of investigation maybe like in the context
like the super timeline where you have some other clues you start to get a notion
of some of the event logs that are important to you and what you need to
be focusing in on. And hopefully this presentation
will give you some ideas in that direction as well, okay. So I’m gonna switch
off the video so we can all like
focus on the slides but I’ll be back a little
bit later on in the video for questions and
things like that at the end of the presentation. Okay, so I’m gonna actually do a couple of different examples and these are based
on actual incidents that I’ve investigated
in the last, like I said eight
or nine months. So when you see this one and you think like oh my God,
nobody knows that anymore. Actually no, like as
recently as late last year I was investigating
a team of attackers who used exactly this
tactic for lateral movement and it’s an oldie but a goodie, but it still works okay. So the tactic is the
attacker mounts a file share from some machine they’ve
already compromised, you know typically they’re
just gonna grab C: basically and then they drop their
malware somewhere on the disc drive of
the target system and now they have to figure
out a way to activate their malware on
the target machine. And frankly the easiest way to
do it is by a scheduled task. So from their there
compromised machine they schedule a task
on the remote system and whoop, their malware
starts executing, whatever that happens to be. There are a whole bunch
of events that go into this happening okay, and
they’re actually events that happen in a couple of
different event log files as we’ll see. But basically you
know at the beginning there is logging into
the target system over the network, okay. And that’s a classic
Windows Event Log, 4624 style network login. Now typically this is
being done as an admin user that they’ve compromised so paired with that 4624 login there’s actually a 4672 event which indicates an
admin user logging in. And I’ll show you the
details of these events as we move along through
the presentation. So once they’ve successfully
logged in to the target system then they mount the share
and there’s an event on the target system that
shows that share being mounted. That’s event 5140 your
security event logs. So there’s a bunch of stuff
in the security event logs around the login
and all that stuff. But there are other
event logs as well and in particular
there are event logs related to scheduled tasks and there’s a whole
series of events in the scheduled task event logs that show what the
attacker is doing as far as their scheduled task. Even if they you know end up deleting the
scheduled task later you’ll still see the event logs a lot of detail about
what was going on with those scheduled tasks. Alright, so let’s look
at this in detail. If you were to like put all
of the interesting events into a timeline you
might have a timeline that looks a little
bit like this, okay. And if you’re just looking
at the raw event logs there’s gonna be a lot
more distracting events going on in the event logs than the ones you see on this
sort of simplified timeline. I’m just trying to
pull out and show you the interesting events that
you would want to focus in on. And like I said there’s a couple of different log
files running around, it’s this kind of
lateral movement that you wanna pay attention to. So obviously there’s
the security, .evtx log and that’s where you see
things like the network logon and the network
share being mounted and then end of the
session, logging off, right. But in the middle there’s
all the work they do to actually schedule the task and that one lives in
a separate log file. So there’s, Microsoft
Windows Task Scheduler or Operational.evtx where you find most of
the interesting event logs related to Windows Tasks. And everything from the task
actually being scheduled to being executed. The task finishing
and then later the attackers removing the logs and if the attackers are
using some sort of scripted mechanism for doing this you’ll see these logs
come in very rapidly after one another, right. I mean they login, the
network share gets mounted, bam, the task gets scheduled,
it runs in the next minute, it runs quickly, it gets removed and you know they’re gone
within under 10 minutes. So really it’s a very
narrow window of time that this stuff can happen in. You don’t have to
spend a lot of time looking all over the logs
for these components, right. So I wanted to drill down on
each one of these log entries and show you the kinds
of things you can extract from each log message and sort
of tell you a little story about what we’re seeing in
this particular investigation. So first up is the
initial network logon. Okay, so this is gonna
be event ID 4624. You see the login
type down there sort of in the
middle of the event, that’s Logon Type-3, which is the classic
Windows network logon that you see preceding
file shares being mounted and things like that, okay. So obviously the event
logs are all time-stamped, we call this one the St.
Valentine’s Day Massacre since it happened
on February 14th. So in the event log you see the user logged in right, names changed to
protect the innocent. Typically this is gonna
be a compromised account where they’ve stolen
the account credential by some other mechanism. And you see the user
name and the domain name that that user is a member of. You also see the IP address where the network’s logon
is originating from. So this is the IP address
of the compromised machine and in the investigation right, so this is the next machine
that you work backwards too, you know to get an
image of that machine, figure out what happened. As you work your way
back to patient zero. So anyway you can
see who logged in, where from, at what time. So that’s what you get
out of 4624 messages and it’s one of the
more useful messages that starts this
whole chain of events. So next up, if the person who was logging in had administrative privileges that 4624 login is gonna be
followed up by a 4672 event which shows that this
person is an administrator. So you see their SID,
and their user name and their domain
again, but you also see the privilege list, right,
which gives you an idea of the different privileges
that are allocated to this particular user. The specific privileges, I mean you could go
and look at Tech NET and figure out what they are, but basically the longer
that privilege list vector is the more power this user has. And in this particular
investigation that I sort of am
borrowing from, this was a domain
admin user account that had been compromised and then was being used
for lateral movement all around their network. You can see they have
quite a large number of different privileges
associated with that account. But basically there are
gonna be a lot of 4624 events in a typical Windows
Security log. The ones you want to
focus in on are the ones that get followed
up by the 4672s because those are
the admin logins and those are the
ones that are gonna do the most damage to you, right? So you know 4624
followed by 4672, you know something you
need to pay attention to. Already and then that’ll
quickly be followed up by that user actually
mounting a network share. So again, you can see the
user name and the domain name, the SID and all
that stuff, right. It’s Event ID 5140, that’s a
network share being mounted. Okay, so you can see
again, the IP address which is the source
of the connection. So this is where they’re
mounting the share from, and then you can see actually
what’s being mounted. In this case they’re mounting
the C drive, oh joy, right. And this is you know like
if you’re looking for events that you can
plug into your IDS or you’re SIM tool for
suspicious kinds of events, I mean this is the sort of thing that doesn’t normally happen in a typical Windows
environment, right. You don’t see people you
know mounting the C drive from random workstations
all over your networks. This is one where you know like this is the kind of event
that I would look for for sort of automated sensors because it’s just not
that normal, right. So look at, you know consider
the context of the machine. What’s the source address? What’s the target system
that’s being mounted? And what’s the share
that’s being mounted? Right, because if
it’s not a file server why are people mounting shares
from the machine, right? So this is one of the things
that you can instrument in your network to warn you when this kind of lateral
movement is happening. But obviously you know
once it’s already happened and you’re doing investigations
like I’m doing now this is an interesting event ’cause it tells
you something about how the attacker
likely put the malware on the system. Okay, they just mount
a network share, now they can drop whatever
they want onto that machine. Okay, so now we’ve
got an attacker, they’re using an
owned admin account, they’re mounting network shares, a lot of people they
just sort of stop at this level of analysis. They like oh, the
security event log’s where it’s at and that’s
everything there is. But there’s all kinds of
other sort of interesting little event log files
that are running around on Windows. And so for example, I mean
you have the scheduled tasks related event logs, and
(coughing) excuse me. So task scheduler/operational
is the one that has the interesting events, okay. So right after the
network share’s mounted we can see the same owned
administrator account registering a scheduled
task on the target machine. What’s unfortunate about
good old event ID 106, scheduled tasks
being registered, is that while it shows
the name of the task and it shows the user
who registered the task it does not actually
show the source where the task was
registered from and this has actually
always been one of my gripes with this particular event was, gosh, I’d really like to
see the source IP address where the task was
registered from even if you know that
source IP is looped back in 127-001. I don’t know it’s just
a source of frustration. You could sort of infer
I think you know where the task was registered from. Most likely registered
from the same place they mounted the network share, but you can’t say for
certain unless you have you know some
network level logs. But there’s nothing in the
event log that will tell you where the task was
registered from. I got a question in
the questions window, “Is there a good
resource out there “which recommends audit settings “for the security event logs? “Which events to
audit, event log size?” Et cetera, et cetera. There are,
(laughing) many are the
arguments of wizards, you know I think there’s
probably a billion different resources out
there that claim to be the be-all and end-all you know
source for that information. There’s some good papers
in the SANS reading room if I remember that talk about, you know good settings
for event log auditing and things like that. If any of you all have
particular favorite ones that you like you’re
certainly welcome to throw them into the chat and share them with the
rest of the audience. I don’t have one sort of
off the top of my head at this point, mostly because
I’m stuck with whatever audit logs I happen
to find on the system when I get there. Already so 106. We’ve got a scheduled
task named AT1 that’s been registered by
our own domain admin account. So typically you know in
an IR situation like this you’ve got the attacker
trying to move very quickly. So you’ll see them scheduling
a task in one minute and then that task will run
at the top of the next minute. And again, I think
this is something where you could easily use
this as a indicator for lateral movement
in your network. A 106 event followed up
within under a minute by a 200 event, which is the
task actually running, okay. Now the 200 event
is interesting, aside from the fact here that
it’s happening very quickly, you can see the task name, but it actually tells
you the name of the thing that’s being run by the
scheduled task, okay. So here are attackers
were nice enough to name the script, malicious.bat. This never happens, I
just changed the name, the script to again,
protect the innocent. But at least what you’ll
see in the 200 event is the thing that got
executed, whatever that is. It’s often a batch script,
but it could be an executable. You may or may not
see the full path name to the program depending
on where they dropped it in the share that they mounted, whether they just dropped
it in the Windows directory then they can run it without
needing full path name. If they try to put it
somewhere more out of the way then that’s actually
better for you because you actually
see the full path name of where it got dropped
in the 200 event because they have to
specify the full path name. Okay, so we’ve got
the task running, you can see the
name that’s running and then whenever
the task finishes there’ll be a 201 event
at the end of all of that which shows you
that it finished. But in this case before
that 201 event happened we actually got a bonus, okay. It turns out that in
this case, my friends were running a
credential dumping tool, it was actually Mimikatz which they cleverly
renamed M.exe. But one of the things about
credential dumping tools like that is that they
need to elevate privileges in order to dump the hashes
out of the L slash process or whatever it is
they’re gonna do. So when this particular
malicious.bat ran it ran the M.exe executable that they had also dropped
on the network share, that executable elevated
privileges and you actually get this extra event from the
security event logs, 4688, which shows the token
elevation happening and it shows you the
name of the process that’s being executed, so C:/Windows/m.exe
as you see here. So that one was a bonus, right, I’m going through my
event logs in my timeline, I’m like oh, look, there’s
the nasty script running and oh look, there’s what the nasty script
actually executed. So in my case I wasn’t
able to actually go back and get m.exe, it wasn’t
in the file system, but a little bit of file carving and you know hey, presto, I could pull back that
executable, right. But only because I
knew to look for it because this extra little
security event happened. So that was nice, you know
it’s like oh okay, great. Thank you for showing me exactly what you’re doing on the system. So this was just a
flat-out credential dump, they moved laterally
onto the system in order to try and dump creds. Obviously to harvest
more accounts so they could continue to
move through the network. Okay and so you know after their
credential dumping tool ran then we get down
to the 201 event which is the end
of the execution. In this case you’ll
notice something a little bit different right. The action name is
actually command.exe because they were
running a batch script. So malicious.bat is the
thing that they executed and you saw that
in the 200 event when the task was started. But since it was a batch script that was actually running, you
know it was a command shell, so you sometimes see a
little discrepancy like that in the 201 output, but
that’s what’s going on here, that’s why you get
different things in the 200 and 201
events for the action. You actually see the
result code of the script, that may or may not be
meaningful to you as well. Now, sometimes that’s it right, and sometimes the
attackers run their script and they’re done. That’s good because
that means you’ll find the At1 job files sitting in
the Windows task directory and you can dump out all the
metadata from that job file. In my case the folks
I was working with were a little bit more
careful about cleaning up and so after their
task ran they actually manually removed the task. And when you see a
task being removed that’s even ID 141, okay
and you see the task name that’s being removed. You know it’s normally
gonna be removed with system privileges
so you don’t actually see anything more than that
in the user name field. But you can at least see
the task being removed, so these folks cleaned up, but it doesn’t really matter because I know when
they scheduled the task, I know what job the
task ran, right. So I have all of the
interesting data about the task. I don’t actually
need the At1 job file from the Windows task directory because I’ve got all
of the interesting data out of the event logs. And then at some point you’re
gonna see them logging off, right, so I mean disconnecting. So again, the login type
should, on the 4634 event, should match the login type on
the 4624 network logon event and you’ll see the user name and the domain
name match as well. The logoff could actually happen pretty much anywhere
in this timeline after they mount
the network shares. So sometimes I see
them logging off you know as soon as they’ve
mounted the network share and have deposited their
malware on the system even before they do the
scheduled task stuff. So logoff events can happen
anywhere in the timeline just keep an eye out for them. You know nothing
particularly interesting unless you’re trying
to plot exactly when the attackers are logging on
and logging off of the system. And it’s typical, you
may see the attacker login multiple times from multiple different places, sometimes using
different credentials so you’ll see multiple
network logins from the same source IP address as they’re trying out
different credentials trying to see you know which
ones have domain access or whatever access they need to access the data
they’re looking for. So just by looking
at the event logs on this particular system
we actually know a lot about what happened here, right. We see the login event, which tells which
credential they’re using, what IP address
they’re coming from and of course all the
events are time-stamped. We had the 4672 event
which says the credential they’ve stolen as an admin user. And we can see the 5140 event which shows them mounting
the network share from the same source IP address and you know what they
mounted, in our case C: and then you can actually
see what they did after that because we see them registering
the scheduled task, right. We see what program the task ran and when it actually executed. You can see when it finished and you can see that they
then later removed the task. So no again, if you’re looking
for things to plug into your SIM tool or your
automated analysis to alert you about this
kind of lateral movement, weird 5140 events,
tasks being scheduled and then executing
shortly thereafter. So like a 106 followed by a 200 within the same
one-minute interval, or two-minute interval. And to some extent cleaning
up scheduled tasks. I mean in my experience
looking at Windows event logs you don’t see a lot
of 141 events, okay. Mostly people schedule
tasks and then let them go. So that might be another
interesting one to look for. Okay, so there you go,
that’s example number one, basic lateral movement
kind of thing, right. We’ve got a URL that
showed up in the questions, let me put it down
in the chat here for people, hold on a sec, doing a little copying
and pasting here. So that URL that I just
posted was a suggestion from one of the attendees about places you can
go for suggestions on event log audit
and things like that. Okay, moving on let’s talk a bit about number two. Which I call the domain
controller of doom. In this case, in this
particular investigation my adversaries were moving
around the network using RDP, so there’s a lot of
malicious RDP activity all over the network. On this particular system
that I was investigating it was the same attack group
but they actually left behind two different remote
access Trojans at two different timeframes, but because they’d
been in the network for some considerable
period of time and this system had actually
been compromised twice. Now this is a domain controller and so all of those
wonderful security event logs that I was showing
you, forget about it. Honestly a domain controller’s
security event logs wraps so frequently that’s there usually very
little usable information, particularly for sort of
historical investigations going back more than
eight hours or so. So the problem is you know
event logs have limited size. And so they’re circular and when you fill up
the event log buffer they overwrite the
oldest entries, constantly eating their
own tail like that. And on a domain controller there are constant security
events being wrapped up by every machine in the domain that’s talking to this
domain controller. So the security event logs
on a domain controller spins like a mother, and
so you only get a few hours of retroactive logs,
usually you know not enough to show you attacker activity. So we need some other ways
to see what’s going on on the system. So let’s see here, what you do get though,
I mean in this case because the attacker’s
were using RDP there’s a couple
different logs related to terminal services. Okay, so terminal services
remote connection manager and terminal services
local session manager. Both logs have
interesting events that you wanna
pay attention too. So the remote
connection manager, the interesting log events
are the 1149 events. These are remote connections,
remote authentication, from various IPs. And in the 1149
events you can see, you know user and domain and source IP address for the connection
and of course the time that that connection occurred. But if you drill down into
the local session manager event logs with
that you also see sort of more detail, okay. So in the local session
manager there are events that are, actually
number 21 through 25, are sort of interesting events, but the ones that are
particularly interesting are the 21 events, that
shows a successful login. So you’ll typically
see an 1149 event in the remote
connection manager log paired with a 21 event in the
local session manager log. So they should match up, you
should see the same user, you should see the
same source IP address. What’s interesting is the
time stamping on those events. I’ve actually seen the 21
event, you know come in up to a minute
after the 1149 event that’s logged in the remote
connection manager log and so I assume that 1149 logs you know as soon as
the user types in the right password,
whereas the 21 event, the local session manager, basically shows the user’s
desktop being fully instantiated which is why there’s
a time gap there. So other events you can
see when they log off, so that’s a 23 event. And there’s also
disconnect event, which typically happens
a few seconds after the logoff event. So you’ll see you
know this pattern, 1149, 21, 23, 24,
and you can see how long the session lasted ’cause it’s the timeframe
between the 1149 event and the 24 event, so if you’re trying
to build again, a map of user login and
logoff activity, you’ll see that. So this is the
simplest possible case, they login, they do
something for a little while, they log off. But when this gets
more complicated is
you can actually see situations like this
where in this case they were using the same
compromised credential, they’re actually logging in
from two different systems. So at 15:00 you
see the 1149 event which is them logging in from in this case 192.168.1.10 and you can see the 21 event which shows that logon
being successful. Then a little bit later you actually see them logging in from a different IP address. So notice the 1149 event
that’s happening at 16:00 comes from a completely
different IP. Now typically when
that happens, right, they’re logging in
as the same user but from a different IP. The current session
gets kicked, right, so you’ll see the 25
and the 24 events, so 25 is user reconnecting, now in this case
they’re reconnecting from a different IP address which means there’s a
24 event that happened showing their original session from in this case 192.168.1.10 being disconnected to make
way for the reconnection from the new IP address. And by the way I’ve seen
the Windows event logs log the 24 and 25
events in either order, there doesn’t seem to
be much rhyme or reason which one gets thrown
down in the logs first. This is a typical
pattern where you have maybe multiple attackers
using the same credential or the same attacker coming
in through multiple systems you’ll see these 1149 events which may be paired with a
normal 21 style logon success or they may be paired
with these reconnect, disconnect events, 24 and 25 in the local session
manager logs. So both of those happen and I’ve observed both of
those in my actual cases. But in any event we
now have a sense right. We can see what credential
they’re using again, where they’re connecting from and again, we have timeframes
so we can establish activity on the system within
particular windows of time. So it’s a good
amount of information and if I had security logs, I mean there would
be a 4624 event associated with RDP logins,
that’s logon type 10 by the way. So normal network logins,
like I showed you before, are logon type 3, RDP type
logins are logon type 10. But in this case because
I’m on the domain controller all of my 4624 events
have been overwritten so I don’t see them. But on a less
heavily used machine you’d actually be able to tie the 4624 events to
the 1149 and 21 events in the terminal
services logs as well. But in this case all I’ve got
is the terminal services logs but they go back quite far, I mean even on
domain controllers I’ve seen terminal
services logs go back for the better part of a year. So you have quite a bit
of historical legacy stuff for you know terminal
services kinds of things. I’ve got all this
stuff about attackers logging into the system and
that’s all great, right, but I’ve got some other
sort of bonus things from looking at the
event logs on this system and they were related to the different persistence
mechanisms for the malware that the attacker
established on this machine. In particular the attacker, well actually I’m gonna
do a little quiz here. I was looking at the timeline of all of the
different event logs that I’d thrown into
a super timeline and what I noticed
was that every time there was a user login
I saw one of these logs it was actually
from the Symantec end-point protection client they had installed
on these machines. So anti-virus is dead
right, but sometimes end-point protection tools
can show you useful stuff if you’re paying attention. So this one was associated
with every single user login on the box, whether it
was by RDP or whatever. Every time a user logged
in, right after the login we saw this little thing, we saw a tampered warning
on servicehost.exe and it was associated with
the particular user login. So anybody have
any theories about what the persistence
mechanism was that was being used for
this particular malware? Throw it into the
chat if you want. Okay, persistence mechanism
associated with user login usually means that there’s
a current version run-key that’s set, so that’s typically
what you’re gonna see. You know current version
run-keys can be set so that software’s activated
when a given user logs in and that’s exactly
what happened here. We had a remote access Trojan where the persistence mechanism was a current version
run-key that was set in the all users registry. So any user who logged in
executed the attacker’s malware. The program that was executed
then injected the malware into a service
host on EXE process which is why we’re
getting the tamper warning from the Symantec product. So this was noisy, I mean
this was all over the logs on this particular system and every time
somebody logged into the freaking domain controller the attacker’s
malware got activated and was beaconing
out, so it turns out if this particular client
had been paying attention to their firewall logs
and things like that they would have seen the
beacons every single time somebody logged into
the domain controller, but unfortunately
for them anyway they weren’t paying attention. This one was a little bit subtle but once I started looking
at the other events and then noticed this
one I’m like huh, you know why is that happening? And then of course
you can go off and do a little bit
of memory analysis, you know run a MALF
or something like that on the service host processing and sure enough you’d see
the injected memory segment with the rat floating
around in it. So this one was interesting, there’s a bunch of
different application logs that may be created
and don’t ignore those because they have
clues like this in them if you’re looking for them. This is again, a case where
putting all the logs together into something
like this timeline is definitely a useful
investigative technique because then you can see all
of these things happening chronologically and you start
to see a pattern developing that can be useful for you. So turns out that
there was another clue in a different event
log related to the other remote access Trojan that they’d
installed on this machine. So I mentioned there were
two different malware loaded on this box, so
the other clue comes to us from the system event log where in particular
you see event ID 7045 which is a service
being registered. So another common
persistence mechanism is to install your malware
as a system service and in the 7045
events you’ll see, obviously the timestamp when
the service was registered but you’ll see the service
name under services registered. Again, I’ve changed
the service name and more importantly you
see the full path name to the executable that
is being registered. So in this case this
one was really obvious because the attackers
used a completely stupid directory path for
their service, right. I mean there are not
a lot of services that run out of WindowsTemp. So that one was sort of obvious and you see attackers you
know putting their malware in random directories. I mean maybe a
directory right under C: or under program data, but outside of the normal
system bin directories. I mean normally I’d
expect to see a service being run out of
WindowsSystem32 maybe, maybe under somewhere
under program files if it’s a third-party
application. But WindowsTemp
forget it, right, obviously not good. So again, like if you’re
looking for things to kind of look for as far as
automating your infrastructure and alerting look for suspicious service event registrations. So it’s event ID 7045, look
for the image path right, if the image path is
something non-standard or maybe even like something
you’ve never seen before. So this is a case
where you know stacking across multiple systems
would definitely be useful. In this case it’s
an alert, hey look, somebody’s doing something
kinda hinky here. So I’ve seen a lot of
malware persistance by a service in my
investigations over the last eight or nine months. It seems to be a very
popular mechanism these days. In this case you can see
StartType, auto start whenever the system reboots
you can see what privileges are running with local system. So I mean they’ve owned
the box at this point. So now you can go off and
do your displace analysis and you know where
the malware is now, so go find it, give it
to your malware analysts and let them figure
out what kind of Trojan you’ve got on the system. The other thing
I’ll say about this is you know attackers
will sometimes get in and they’ll trash your
security event logs ’cause they know there’s
bad stuff in there but you know this
is a case where they often will leave
behind System.evtx because they don’t
think there’s anything particularly bad in there
from their perspective. But I mean here, you
know clearly we see a clear sign of the
attacker’s activity. So yeah. So with this second example
what I really wanted to show you was first off, even
when you don’t have your security event log, either it’s because it’s
eaten its own tail so rapidly that events you want are gone or because the attacker has
removed the security event log, there’s still lots of other
places that you can go to look for signs of
attacker activity. If they’re using RDP, the
terminal services logs last a long time, they
go back many months and you can profile activity
far back in time, right. And that’s good because
you can then sort of see the normal RDP activity
into the system so when the attackers
start RDP into the box it stands out like a sore thumb because they’re using an account that you’ve never seen on
the box before or whatever. There are additional
application logs, maybe from third-party
applications like Symantec that we saw before that
may give you clues. Those are easier to spot
if you put all the logs into a timeline and kind of
read them chronologically. And even basic system event logs can contain useful things,
like showing the attacker registering the service or
malware persistence, right. So don’t give up just
because you don’t have security event logs, there’s lots and
lots of other logs that last longer, or
may be more persistent. Okay, so that was
a quick drive-by on the kinds of events
that I’ve been using for my investigations recently. Are there any other questions people want to throw out at me before we close off for the day? There won’t be a
survey by the way, thankfully it’s just a webcast. There’s my contact
information again, if you have any questions
after the webcast is over or you think of things later. Also don’t forget I will
be talking a lot more about intrusion response
forensics in Baltimore in just a few weeks,
so beginning of March, if you haven’t
signed up already, I hope to see you there. Okay, I’m gonna throw
it back to Trevor to close us out. Trevor, it’s all yours. – [Trevor] All right,
I would like to say thank you so much to our
featured speaker, Hal, for his great presentation today and bringing this content
to the SANS community. To our audience we greatly
appreciate you listening in. For scheduled all upcoming
and archived webcasts visit sans.org/webcast. Until next time take care and we hope to have
you back again, for the next SANS webcast.

5 thoughts on “SANS DFIR Webcast – Incident Response Event Log Analysis

  1. This video is a bit dated. But it wasn't long after this video was produced that Microsoft triggered the control algorithms that they had been working on for many years, and started changing computers two Windows 10 without permission from users. By this point, anyone who doesn't realize that Microsoft is patient zero, as it is called in this video, is either Clueless or scared of Microsoft. No, they will never plant files called malicious. Anything. but any file that starts with the name trusted is a dead giveaway as to being a major component in the first malware driven operating system in history.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2019 Explore Mellieha. All rights reserved.