Comprehensive Guide to Windows Event Log Analysis in Incident Response

- [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 Windows\System32\winevt\Logs. 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 Windows\Temp. 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 Windows\Temp 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.