Comprehensive Guide to Windows Event Log Analysis in Incident Response

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 how pomerans deerrun Associates digital forensic

investigator please feel free to submit your questions at any point by using the questions window how will be answering

them throughout the webcast right now I'd like to turn things over to how

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 um but we're all inside and and talking forensics on the webcast so um you can

see my email uh 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 um for various companies um 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 you know our clients like to keep it a

little bit under Hush Hush so to speak um 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 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

going to solve all your problems and I think that you know all of those things and put together as part of a

comprehensive analysis package are good things to do but um even you know without those 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 you basic

stuff like Windows event logs and so I wanted to pass along um 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 um by the way uh if you are interested in you know intrusion response kinds of

things I'll be teaching Sans forensics 508 uh in Baltimore the first week in March so if you're looking something to

do pre St Patty's Day in Baltimore come on out to Baltimore be a nice small class lots of you know one-on-one uh

kind of conversations going on there Baltimore is always a good time so hope to see you

there all right so oh look we've got the SDF curriculum and uh 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 S forensics blog and the sift workstation yada yada yada

right so what are we talking about here today uh we're talking about Windows event logs which on Modern Windows

systems live under you know Windows system 32 when EVT logs uh we're just going to be talking about The Modern

event logs from you know the the evtx style logs that you started in Vista uh and later um for 2003 XP vintage

Machines of course they're the EVT logs there are similar sorts of events in those logs um but I just wanted to focus

in on the event IDs and logs from newer Windows systems that you're typically going to deal with right and you know

obviously the logs are in a binary format you need some sort of special parser to look at them and there there's

tons and tons of different event logged parsing tools out there ranging from you know Python and pearl libraries so you

can write your own scripts to parse event logs there are command line event viewers uh from you know variety of

different sources and there's you know all the different graphical ones you know 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 FS Pro Labs which is a nice um Standalone event log viewer for Windows gooey actually Alyssa Torres um

pointed me at event log viewer many years ago and I started using it and really liked it but you know whatever

pick one that you like um people are always a little bit leery I think of event log analysis I mean you

know there's a lot of different event logs and there's a billion different events um they're all mashed up together

and you know unless somebody sort of shows you um you don't really know what events to look for um 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 with you know like in the context like the super timeline where you have some

other Clues you start to get a notion of you know some of the event logs that are you important to you and um you know

what you need to be focusing in on and hopefully this presentation will give you some ideas in that direction as well

okay so uh I'm going to switch off the video so we can all like focus on the slides but uh I'll be back uh a little

bit later on on the video for questions and things like that at the end of the presentation okay okay so um I'm going

to actually do a couple of different examples um and these are based on actual incidents that I've investigated

in the last you know like I said eight or nine months and so you know when you when you see this one and you think oh

my God like nobody does that anymore actually no I mean like as recently as late last year I was investigating a a

team of attackers who used exactly this tactic for lateral movement okay and it's and it's you know an oldie but a

goodie but it still works okay so the tactic is you know you the attacker mounts a file share from you know some

machine they've already compromised um you know typically they're just going to grab you know C colon 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 malare on the target machine and frankly the easiest way to do it is via scheduled task so from

their compromised machine they schedule a task on the remote system and you know their malare 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 you know classic Windows Event

log 4 624 Style Network login now if you know 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 I'll show

you the details of these events as we move along through the presentation so once they've

successfully you know logged into 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 good old 5140 in your security event

logs so there's a bunch of stuff in the security event logs around you know the login and and all of 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 you know show what the attacker is doing as far as their

scheduled task even if they um you know end up deleting the schedule task later

you'll still see in the event logs a lot of detail about what was going on with those scheduled

tasks all right 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 you know if you're just looking at the Raw event

logs there's going to be a lot more more distracting events going on in the event logs than the ones you see on this you

know sort of simplified timeline I'm just trying to pull out and show you the interesting events that you want to

focus in on okay and like I said there's a couple of different log files running around for this kind of lateral movement

that you want to pay attention to so obviously there's the security. evtx log and that's where you

see things you know like the network log on and in netork share being mounted and then at the end of the session you know

them 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 um so there's Microsoft Windows task schuer operational. evtx where you find most of

the interesting event logs um related to you know Windows tasks okay and everything from you know the task

actually being scheduled to being executed the task finishing and then later the attackers removing the logs

okay and if the attackers are using you know some sort of scripted um mechanism for doing this

you'll see these logs come in very rapidly after one another right I mean so they log in the network share gets

mounted bam the task gets scheduled it runs you know in the next minute runs quickly and 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 it you don't

have to spend a lot of time looking all over the logs for for these components right so I wanted to drill down on each

one of these um 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 is the you

know initial Network log on okay so this is going to be um event ID 4624 you see the login type down there

sort of in the middle of the event that's login type three which is you know the classic Windows Network log on

that you see preceding you know file share being mounted and things like that okay so uh you know obviously the event

logs are all timestamped we'll call this one the you know St Valentine's Day Massacre um since it happened on

February 14th all right so in the event log you see the user that logged in right names change to protect the

innocent okay um I mean you know typically this is going to be a compromised account um where they've

they've stolen the account credential uh via some other mechanism and you see the the username and the domain name that

that user is a member of you also see the IP address where the Network's log on is originating from okay so this is

the IP address of the compromise machine and in the investigation right so this is the next machine that you work

backwards to um you know get an image of that machine figure out what happened as you work your way back to Patient Zero

okay so anyway so you can see who logged in where from at what time so that's what you get out of the 4624 messages

and it's one of the more useful messages and starts this whole chain of events

so next up if the person who was logging in had administrative privileges that 4624 login is going to be followed up by

a 4672 event which shows that this person is an administrator okay so you see their Sid and their username and

their domain again you also see the privilege list right which gives you an idea of the different you know

privileges that are allocated to this particular user um so um you know the the specific

privileges I mean you could go you know look at techet and and figure out what they are but basically the longer that

privilege list Vector is the more power this user has in this particular investigation that I sort of am

borrowing from this was a a domain admin user account that had been compromised and then was being used lateral movement

all around their Network you can see they have quite a large number of different privileges you know associated

with that account but basically you know there they going to 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 46 72s because those are the admin logins and

those are the ones that are going to do the most damage to you right so yeah 4624 followed by

4672 you know something you need to pay attention

to all right and then that'll quickly be followed up by that user actually mounting a network share okay so again

you can see the username and the domain name and 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 ojoy right and this is you know like if you're looking for events that you can plug into your

IDs or you know your sim tool for you know suspicious kinds of events I mean this this is the sort of thing that

doesn't normally happen in a typical Windows environment right you you don't see people you know mounting the C drive

from random workstations um all over your network this is one where you know like this is a kind of

event that I would look for for sort of automated sensors um because it's just not that normal right so look at you

know consider the context of the machine right 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 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 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 because it tells you something about how the attacker likely

put the malware on the system okay they just mounted Network share now they can drop whatever they want onto that

machine okay so now we've got an attacker they're using uh you know an owned admin account they're they

mounting Network shares a lot of people they just sort of stop you know I

mean at this level of analysis they they think you know like oh the security event logs you know where it's at and

that's that's everything there is but there's all kinds of other sort of interesting little event log files that

are running around uh on Windows and so for example I mean you have the um the scheduled tasks related event logs and

excuse me um so task schedu or operational is the one that has the interesting events okay so

right after the network share is 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 task being being registered um is that

while it shows you know 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 is 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 loop back in 12701 um so

um you know I don't know it's it's just a source of frustration you could sort of infer I think you know where the the

task was registered from it's 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 logging but there's nothing in the event log that

will tell you where the task was registered from um I got a a question in the

questions window um is there a good resource out there which recommends audit settings for the security event

logs um which events to audit event log size you know etc etc um there are many are the arguments of wizards uh you know

I I think there's probably a billion different resources out there that claim to be the be all and end all um you know

source for that information um there's some good papers in the Sans reading room if I remember that talk about

um you know um good settings for event log auditing and things like that um if any if any of y'all have particular

favorite ones that you like you're certainly welcome to throw them into the chat um 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 I mostly because I'm stuck with whatever

audit logs I happen to find on the system when I get there um so all right so 106 we've got a

scheduled task named at one that's been registered by our owned domain admin account right so typically you know in a

um IR situation like this um you've got um the attacker you know trying to move very quickly so you'll see them

scheduling a task in one minute and then it will that task will run at the top of the next minute and again I think this

is something where um you could easily use this as a indicator for lateral movement in your network right a 106

event followed up you know within under a minute by a 200 event which is the the task actually running okay so um now the

200 event is interesting I mean aside from the fact here that it's happening very quickly um you can see the task

name but it also tells you the name of the thing that's being run by the scheduled task okay um so here our

attackers were were um you know nice enough to name their uh script malicious. bat this never happens um I

just changed the name of 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 is often a batch script but it could be an executable um you may or may not see

the full path name to the program depending on where they dropped it in the you know share that they mounted

right if they just dropped it in the windows directory then they can run it without needing a full path name if they

try to put it somewhere out of the way then you'll actually that's better for you because you actually see the full

path name of where it got dropped in the the um 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 2011 event at the end of all of that which um shows you um that it's finished but in this case before that

2011 event happened we actually got a Bonus okay it turns out that in this case uh my friends were running uh

credential dumping tool it was actually mimic cats which they cleverly renamed me.exe

um but one of the things about credential dumping tools like that is that they need to um Elevate um

privileges in order to you know dump the hashes out of the Elsas process or whatever it is they're going to do so

when this particular you know malicious. bat ran it ran the me.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 see

and windows.exe as you see here so that one was a bonus right I'm going through my event logs in in my timeline I'm like

oh look um there's the you know there's the nasty script running and oh look there's what the nasty script actually

executed um so in my case I wasn't able to actually go back and get me.exe um it wasn't in the file system but a little

bit of file carving and you know hey Presto um I can pull back that executable right but only because I need

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 you know showing me exactly what you're doing on the system so this was just a this is a flat out credential

dump they were um they moved laterally onto the system in order to try and dump creds um obviously to harvest more

accounts so they could continue to move through the network right okay and so you know after their credential dumping

tool ran then we get down to the 2011 event which is the end of the um execution in this case um you'll notice

something a little bit different right the action name is actually command. exe because they were running a batch scrip

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 you know was actually running was a command shell so you see you so you sometimes see a

little discrepancy like that in the 2011 output um but that's what's going on here that's why you get different things

in the 200 and 2011 events for the action you actually see the result code of the script um that may or may not be

meaningful to you as well now sometimes that's it right I me sometimes you know the attackers R their

script and and they're done um that's good because that means um you'll find the at one job file sitting

in the Windows task directory and you can dump out all metadata from that job file um in my case um the folks I was

working with were a little bit more careful about cleaning up and so after their task ran they actually REM you

know manually removed the task and when you see a task being removed that's event ID 141 okay and you see the task

name um that's being removed um you know it's normally it's you know going to be removed with system privileges so you

don't actually see um anything more than that in the um username field but you know you can see that you can at least

see the task being removed um so these these folks cleaned up but it doesn't really matter because I know you know

when they scheduled the task I know what job the task ran right so I have I have all of the interesting data about the

task I don't actually need the at one job file from the from the Windows task directory because I got all of the

interest data out of the event logs and then at some point you're going to see them logging off right I mean so

disconnecting so again the login type should on the 4634 event should match the login type on the

4624 Network log on event and you'll see the username and the domain name match as well um the the log off could

actually happen pretty much anywhere in this timeline after they mount the network share 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 um

even before they do the the scheduled task stuff so logoff events can happen you know anywhere in the timeline um

just you know keep an eye out for them you know nothing particularly interesting unless you're trying to you

know plot exactly when the attackers are logging on and logging off of the system and and in a typical incident you may

the attacker log in you know multiple times from multiple different places um you know sometimes using um

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 you know domain access or whatever access they need to

access the data they're looking for so so just by looking at at the event logs on this particular system

system we actually know a lot about what happened here right we see the login event which tells you know which

credential they're using what IP address they're coming from and you know of course all the all the events are

timestamped we have the 4672 event which says the credential they've stolen is 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 you know what they mounted

in our case C colon and then you can actually see what they did after that because we see them registering a

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 okay so um you know again um if you're looking for things to

plug into your sim tool or your automated analysis to to alert you about this kind of lateral movement weird 5140

events um 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 um and and to some extent cleaning up schedule tasks I mean in in

my experience looking at Windows event logs you don't see a lot of 141 events okay um mostly people schedule tasks and

then let them go so that might be another interesting one to look for okay so um there you go that's that's

example number one basic um lateral movement kind of thing right um we've got some uh we got a uh

URL that showed up in the questions let me put it down into the chat here for people hold on a sec doing a little

copying and pasting here um so that uh URL that I just posted was a suggestion from one of the

attendees about um you know places you can go for suggestions on event log auditing and things like

that um okay so um moving on let's talk a bit

about number two uh which I call the domain controller of Doom um in this case the

uh in this particular investigation uh my adversaries were moving around the network using

RDP um so there's a there's a lot of malicious RDP activity all over the network um on this particular system

that I was investigating they it was the same attack group but they actually left behind two different remote access

Trojans at two different time frames because they've been in the network for some um considerable period of time um

and this this system had actually been compromised twice now this is a domain controller and so um all of those

wonderful security event logs that I was showing you forget about it um honestly domain controllers security event logs

wraps so frequently that there's usually very little usable information particularly for sort of historical

investigations going back more than you know eight hours or so so the problem is you know event logs have limited size

right 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 they're constant security events being racked up by every

machine in the domain that's talking its domain controller so the security event log on a domain controller spins like a

mother and and so you only get a few hours of retroactive logs usually you know not enough to show you attack or

activity so we need some other ways to see what's going on um on the system so let's see here

um what you do get though I mean in this case because the attackers we're using RDP is a couple of different logs

related to terminal Services okay so there's terminal Services remote connection

manager and terminal Services local session manager both logs have interesting events that you want to pay

attention to so the remote connection manager the interesting log events are the 1149 events these are you know

remote connections remote authentication uh from you know various IPS and in the 1149 events you can see

you know user in 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 more detail okay so in the local session manager there are events actually number 21 through 25

are sort of interesting events but the 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 timestamping on those events I've actually seen the 21 event you know come

in you know up to a minute after the 11 49 event gets logged in the remote connection manager log and so I assume

that you know 11:41 I'm sorry 11:49 logs you know as soon as the user types in the right

password whereas the um 21 event in the local session manager basically shows you know the use the user's desktop

being fully instantiated which is why there's a Time Gap there so um other events you can see when they log off

um so that's a 23 event and there's also a disconnect event which you know typically happens a few seconds after

the logoff events so you'll see you know this pattern 11:49 21 23 24 um you know and you can

see how long the session lasted because it's the it's the time frame between the 11:49 event and the 24 event so if

you're trying to build again a map of you know user login and log off activity you know you'll see see that okay so

this is this is the simplest possible case they log in they do something for a little while they log off right but

where this gets more complicated is you can actually see situations like this where in this case they were using the

same compromise credential they're actually logging in from two different systems right so at 1500 you see the

1149 event which is them Lo in in from you know in this case 192 168 1.10 and you can see the 21 event which shows

that log on you know being successful then a little bit later you actually see them logging in from a

different IP address right so notice the 1149 event that's happening at 1600 comes from a completely different IP now

typically when that happens right if you're logging in as the same user 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 happens showing their original

session from you know in this case 19268 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 um it

just you know there doesn't seem to be much Rhyme or Reason for which one gets thrown down in the logs first so but

this is this is a typical pattern where you have you know maybe multiple attackers using the same credential or

the same attacker coming in through multiple systems you'll see these you know 1149 of events which may be paired

with a normal you know 21 style log on success or they may be paired with these um you know reconnect disconnect events

24 and 25 in the local session manager log so both of those happen and I've observed um both of those in my actual

cases but in any event you we now have a sense right we can see you know what credential they're using again um where

they're connecting from and again we have time frames so we can you know estabish Lish activity on the system

within particular Windows of time so it's you know it's 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 log on type 10 by the way um so normal Network

logins like I showed you before are log on type three RDP type logins are log on type 10 okay 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 on a less

heavily used machine you'd actually be able to tie the 4624 events to the to the 1149 and and 21 events in the

terminal Services logs as well okay but in this case all I've got is the terminal Services logs but they go back

quite far I mean even on you know domain controllers I've seen terminal Services logs go back for you know the better

part of the year so you have quite a bit of historical Legacy stuff for um uh you know terminal Services

kinds of things um okay

so I've got all this stuff about you know attackers logging into the system and that's all great right um but I got

some other sort of bonus things from looking at the event logs on this system and um they were related

to the different persistence mechanisms for the malare that the attacker has established on this machine so in

particular um the attacker well actually I'm GNA do a little quiz here um so what we I was looking at the uh timeline of

all the different event logs that I'd thrown into a you know super time line and what I noticed was that every time

there was a user log in I saw one of these logs it was actually from the semantic endpoint protection client that

they had installed on these machines so so you know antivirus is dead right but you know sometimes the endpoint

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 okay every time user logged in right after the login we saw

this little thing we saw a tamper warning on service host.exe and it was associated with you know 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 in 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 okay

so that's typically what you're going to what you're going to see um you know current version run Keys uh can be set

um so so that they so that software is activated when a given user logs in and that's exactly what happened here we we

had um a remote access Trojan where the persistence mechanism was current version run key that was set in the all

users registry so any user who logged in executed the attacker's malware um the the program that was executed then

injected the malware into a service host.exe processes which is why we're getting the tamper warning from the

semantic product okay 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 um got activated and and was beaconing out so

it turns out you know um 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 some logged into the domain controller but

unfortunately um for them anyway they weren't paying attention so um this one was a little bit subtle but you know

once I started looking at the other events and then noticed this one I'm like huh you know why is that happening

and and then of course you can go off and do a little bit of memory analysis you know um you know run a malind or

something like that on the service host process and you know sure enough you see the injected memory segment with the

with the rat floating around in so um so this one this one was interesting I mean so there's a bunch of different um

application logs that that may be created and you don't ignore those because they have Clues like this in

them you know uh if you're if you're looking for them this is again a case where putting all the logs together into

something like a s timeline is definitely a useful investigative technique because then you can see all

of these things happening chronologically and you start to see a p pattern developing that can be useful

for you so turns out um that there was another clue in a different event log

related to the other remote access troan that they installed on this machine so um you know I mentioned there were two

different um Mau uh loaded on this box so the other clue comes to us from the system event log where um in particular

you see event ID 745 which is a service being registered right so another common persistence

mechanism is to install your malware as a system service and in the 7045 events you'll see obviously the time stamp when

the service was registered but you'll see the service name that the service was registered again I've changed the

service name um and more importantly you see the full path name name to the executable that um is being registered

so in this case I this one was really obvious because the attackers used a completely stupid um directory path for

their service right I mean not a lot of services that run out of Windows temp um so that one was sort of obvious and you

see attackers you know putting um their their malware and and random directories I mean you know maybe a directory read

under C colon or under program data but outside of the normal system bin directories right I mean normally I'd

expect to see a service being run out of I don't know Windows system 32 maybe maybe under you know somewhere under

program files if it's a third party application but Windows temp forget it right obviously not good so again you

know like if you're looking for things to kind of look for um as far as automating your infrastructure and

alerting um look for suspicious um service event registrations so it's event ID

745 um look for the image path right if the image path is something non-standard or maybe even you just like something

you've never seen before right so this is a case where um you know stacking across multiple systems would definitely

be useful um so in this case you know it's an alert hey look somebody's doing something kind of hanky here so i' you

know I've seen a lot of malare persistence via um Service uh in my investigations over the last eight or

nine months um seems to be a very popular mechanism these days um in this case you can see um you know start type

auto start means it's going to start whenever the system reboots you can see what privileges it's running with you

local system so I mean they've owned the box at this point so now you can go up and you know do your dis base analysis

and and you know where the ma is now so so go find it and you know give it to your Mau analysts um and let them figure

out what kind of you know 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 um trash your security event logs because they

know there's bad stuff in there but you know uh this is a case where um you know they often will leave behind the system

evtx because they you know 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 so

yeah so with this second example what I really wanted to show you was um first off even when you don't have you know

your security event long whether it's because it's you know eaten its own tail so rapidly that the 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 attack activity if they're using RDP the terminal Services logs last a long time uh they go back

many months and you can profile activity far back in time right and and and that's good because you can then you

know sort of see the normal RDP activity into the system so that 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 whatever

you know um there are you know additional application logs um maybe from third-party applications like

semantic that we saw before that may give you Clues um those are easier to spot if you put all of the logs into a

timeline and kind of read them Chron logically um and you know even even the you know basic system event logs uh can

contain useful things like showing the attack or registering the service for 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 maybe

more persistent okay so that was a quick drive by on um you know the kinds of

events that I've using for my investigations recently are there any other questions people want to throw out

at me uh before we close off for the day uh there won't be a survey by the way thankfully it's just a webcast

um there is my contact information again if you um have any questions after the webcast is

over uh or think of you know things later um also don't forget I will be um 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 all right uh I would like to say thank you so much to our Fe speaker how for his great presentation today and for

bringing this content to the S Community to our audience we greatly appreciate you listening in for a schedule of all

upcoming and archive webcast visit sans.org webcast until next time take care and we

hope to have you back again for the next Sans webcast