0:00

This week I'm

0:02

talking about detecting

0:04

malicious network activity.

0:06

Welcome to the

0:08

Digital Forensics Survival Podcast.

0:11

This is episode 169.

0:13

Hello everyone. I'm Michael,

0:16

your host. Welcome to

0:18

the show. Today's episode

0:20

is about Windows event

0:22

logs that record blocked

0:24

network connections. This will

0:26

be the... final installment

0:28

of this particular series

0:30

this is episode four

0:32

of four which if

0:34

you've been tuning in

0:36

covers how to quickly

0:38

identify malicious network activity

0:40

using windows event logs

0:42

or certain windows event

0:44

logs each episode gives you

0:46

a piece of the puzzle

0:49

and now you have the

0:51

final piece for the complete

0:53

picture so whether you're a

0:55

seasoned responder or this is

0:57

all brand new to you

0:59

Fundamentals are very important and

1:01

understanding the fundamentals of network

1:03

triage help keep your skills

1:05

sharp. So I'll have the

1:07

breakdown of this last bit

1:09

of network triage coming up

1:11

right after this. Facing an

1:13

overflow of evidence drives, image

1:15

26 drives at a time

1:17

with Atola. Task Force 2.

1:20

This high-performance hardware imager reassembles

1:22

unknown rate arrays, supports damaged

1:24

drives, and can be integrated

1:27

into your workflow via API.

1:29

Learn more at at atola.com.

1:32

Once again, that's at t-o-l-a.com.

1:35

Have you ever found the smoking gun

1:37

only to have the suspect claim the

1:39

device has a hidden back door or

1:42

malware? Now you could check for malware

1:44

on a disk image right with an

1:46

autopsy. The new cyber triage malware scanner

1:48

module for autopsy will check all the

1:51

executables on a disk image against 40

1:53

plus malware scanning engines. This saves you

1:55

from having to mount the drive and

1:58

risk bringing malware into your lab. Visit

2:00

cybertriage.com to learn more. Recon

2:02

ITR isn't just another forensic

2:05

tool. It's the most comprehensive

2:07

Mac forensic imaging solution available

2:10

today. Supporting more Mac systems

2:12

than any other tool on

2:15

the market, Recon ITR is

2:17

the go-to choice for examiners

2:19

who need reliable performance across

2:22

Apple Silicon and Intel Max.

2:24

What sets Recon ITR apart?

2:27

It uses native formats preserving

2:29

more proprietary Apple metadata without

2:31

the risk of reverse engineering.

2:34

Built by the experts at

2:36

Sumuri, ReconITR continues to set

2:39

the standard for Mac Forensics.

2:41

Learn more at Sumuri.com. Before

2:44

we dig into today's topic,

2:46

a quick reminder, this miniseries,

2:48

if you want to call

2:51

it that, was not delivered

2:53

in strict sequential order. So

2:56

if you've missed earlier episodes

2:58

on network triage fundamentals, the

3:00

one on live network triage,

3:03

or the one on historical

3:05

network triage, be sure to

3:08

go back and catch up

3:10

on those. Each episode is

3:13

designed to build a cohesive

3:15

methodology for quick Windows network

3:17

analysis. So you'll definitely want

3:20

to check them out. Now,

3:22

quick recap on what I

3:25

call... network triage. The network

3:27

triage fundamentals in that episode

3:30

we discussed the foundational concepts

3:32

of mapping out normal versus

3:34

abnormal network activity and touched

3:37

on how to interpret basic

3:39

Windows event logs for some

3:42

quick winds. The next episode

3:44

on live network triage I

3:46

explored some real-world methods. what

3:49

to capture while system is

3:51

up and running, for instance,

3:54

how to analyze on-the-fly events

3:56

and ways to filter out

3:59

suspicious connections quickly. This works

4:01

both for live triage and

4:03

for log analysis, when you

4:06

have those artifacts, which brings

4:08

us into the third one,

4:11

which was the historical network

4:13

triage. When I transitioned into

4:15

real-time historical data, talking about

4:18

that, we dove into the

4:20

specific Windows event logs that

4:23

captured permitted permitted connections and

4:25

listening ports. This is very

4:28

critical for painting a broader

4:30

timeline of an incident. Most

4:32

of your real-time tools are

4:35

giving you a snapshot when

4:37

you also need that historical

4:40

context if something, especially if

4:42

something has been going on

4:44

in an environment for months.

4:47

You want to have that

4:49

look back. So now we're

4:52

wrapping it all up by

4:54

talking about Windows event logs

4:57

that record block connections. This

4:59

information offers our last piece,

5:01

which is also a key

5:04

piece of the puzzle, when

5:06

it comes to uncovering hidden

5:09

compromises. You could also use

5:11

it to uncover additional malware

5:13

or help to uncover additional

5:16

malware or attempts by adversaries

5:18

to pivot around your environment.

5:21

So why does this even

5:23

matter? It is a fair

5:26

question because we're talking about

5:28

blocked connections. So what that

5:30

means is that some type

5:33

of security mechanism is in

5:35

place and it's actually working.

5:38

So why do you care?

5:40

Right? We're just looking for

5:42

evidence of a breach or

5:45

penetration into an environment. Well.

5:47

Block network events are interesting

5:50

because they might signal that

5:52

an attacker's secondary or tertiary

5:55

tool set isn't working as

5:57

intended. That's good news from

5:59

a security standpoint. It means

6:02

some security control, like I

6:04

mentioned, is preventing malicious, say,

6:07

outbound or inbound traffic. However,

6:09

it's also a sign to

6:11

stay vigilant. Attackers often try

6:14

multiple avenues of compromise. If

6:16

one of their tactics was

6:19

blocked on a host, it

6:21

could have been successful elsewhere.

6:24

So for thorough incident response,

6:26

it's important to log analyze

6:28

and understand these events because

6:31

they may be the precursors

6:33

of a breach that you're

6:36

going to be, or a

6:38

breach that's yet to be

6:40

discovered by you. Now we're

6:43

talking about Windows event codes

6:45

that log blocked connections. So

6:48

we're talking about a very

6:50

specific type of block. There

6:53

are four main event codes

6:55

that are tied, or four

6:57

block connections, that are tied

7:00

to the Windows filtering platform.

7:02

There's another one I'm going

7:05

to throw in here, which

7:07

is for updated Windows Systems.

7:09

So basically anything that you're

7:12

dealing with now. We have

7:14

event 5031, 5152, 5157, 5159,

7:17

5159, 5159, 5159, so those

7:19

are the four that I

7:22

have mentioned before. The new

7:24

one we're going to talk

7:26

about today is event 1125.

7:29

Event 5031. This is triggered

7:31

when the Windows filtering platform

7:34

blocks an application from receiving

7:36

inbound connections. 5152 logs when

7:38

the platform blocks an individual

7:41

packet. 5157 indicates when the

7:43

platform blocked a connection between

7:46

a program and a process.

7:48

And this is either logical,

7:51

not logical, or remote, or

7:53

remote. 5159

7:55

shows local port binding

7:57

denial. which is an

7:59

application that tried to

8:01

bind to a local

8:04

port and the Windows

8:06

filtering platform blocked it.

8:08

Now newer Windows and

8:10

Defender integrations will have

8:12

event 1125. So you'll

8:14

see this in Windows

8:16

10 or in some

8:19

Windows 10 and definitely

8:21

in Windows 11 configurations.

8:23

Now again, especially those

8:25

that are integrated with

8:27

Microsoft Defender for Endpoint.

8:30

You'll see this event in

8:33

the operational log, and this

8:35

can indicate connections at the

8:37

defender firewall level, which is

8:39

offering an additional layer of

8:42

detail around the reason for

8:44

a connection being blocked. Each

8:46

event is structured similarly, so

8:49

when you learn to interpret

8:51

one of these, you can

8:53

apply that knowledge to the

8:56

other. So this makes understanding

8:58

these in aggregate much easier.

9:02

Let's talk about event structure

9:04

and what to look for.

9:06

Every one of these Windows

9:08

Firewall platform event codes includes

9:11

four basic sections. You have

9:13

your basic information, which of

9:15

course is your date and

9:17

time, the event code itself,

9:20

the machine name, and the

9:22

message. So for instance, the

9:24

message for event 5159 would

9:26

state that the local port

9:29

was blocked. Then you have

9:31

the application information. So you'll

9:33

have the process ID in

9:35

hexadecimal or the PID in

9:37

hexadecimal, which you could cross-reference

9:40

with process creation event codes

9:42

to pinpoint exactly when the

9:44

process launched to get more

9:46

context. So something is doing

9:49

this, right? And you may

9:51

want to know what that

9:53

something is. The application name

9:55

field shows the full path

9:58

to the executable associated with

10:00

the blocked connection, which could be

10:02

very important because if something was

10:05

blocked, that is potentially something being

10:07

used or leveraged by the attacker.

10:09

So you want to figure out

10:12

if you have a compromised application

10:14

or service or something new introduced

10:17

into the environment. You'll have the

10:19

network information section. This is going

10:21

to give you the direction and

10:24

it'll be flagged as either inbound

10:26

or outbound. Then

10:28

you'll have the source

10:30

address and the source

10:33

port and the destination

10:35

address and destination port,

10:37

which again, pretty self-explanatory

10:39

there. And then you'll have

10:41

the protocol. Typically that's

10:43

TCP, UDP, and ICMP. They

10:45

each are represented by a code,

10:47

so in that order, that would

10:49

be 617 and 1. Others, or

10:51

there are others, those are the

10:53

common ones that you see. So

10:55

if you see something outside of

10:57

617 or 1 as a value,

11:00

that's something else, you'll have to

11:02

look it up, that may or

11:04

may not be normal for the

11:06

environment as well. And then lastly,

11:08

we have the filter information,

11:10

and this indicates which part

11:13

of the Windows filtering platform

11:15

specifically blocked the connection, which

11:18

often references a rule name

11:20

or ID that you have

11:22

detailed in firewall policies. How

11:25

do you use this information

11:27

for fast triage? What are the

11:29

guidelines here? There are at

11:31

least half a dozen techniques

11:33

or strategies that you can

11:36

use. You can use them all

11:38

together. You could pick and choose

11:40

what you want. Here are some

11:43

effective strategies that I've found helpful

11:45

in the past. One,

11:48

and these are in no particular

11:50

order. The first one is to

11:52

focus on outbound external IP addresses.

11:55

So if you filter records

11:57

to zero in on outbound

11:59

attempts. to external IP

12:01

addresses. That gives you typically

12:03

a shorter list of your

12:06

connection activity or what's being

12:08

blocked. So this could be

12:10

blocked, you know, inbound or

12:12

outbound. Typically, you're looking at

12:15

outbound, so these are probably

12:17

failed C2 calls. Okay, so that's

12:19

important. And then you could

12:21

take that information and you

12:24

could do some threat intelligence

12:26

research. on those to see

12:28

what they're connected to. Maybe

12:31

they're associated with a greater

12:33

campaign at a minimum. They're

12:35

an indicator of compromise or

12:38

something to fuel your internal

12:40

investigation. Now remember to do

12:42

these, it's something I covered

12:44

in previous episodes is you

12:46

have to know the private

12:48

IP address ranges versus the

12:50

public IP address ranges. And

12:52

I covered this in an

12:54

earlier part of this mini-series.

12:56

So that's not that difficult

12:58

to script out or even

13:00

within security appliances. So within

13:02

a seam tool, for instance,

13:04

you can quickly aggregate these

13:06

logs, sort on that field,

13:08

filter out the public, or

13:10

filter in the public IP addresses.

13:13

I was going to say, filter

13:15

out the private, and get a

13:17

short list. And doing this historically.

13:20

can mean a big deal. You

13:22

know, you could quickly get a

13:24

reduced data set to find out,

13:27

you know, what's being blocked,

13:29

you know, within the last, you

13:31

know, month or, you know,

13:34

30 days month, two months,

13:36

three months, what have you.

13:38

And the next thing is

13:40

to look for port application

13:43

alignment in a previous episode.

13:45

So this is a common

13:47

triage technique. you're looking to

13:49

see if the application or

13:52

service logically matches the port

13:54

that's in use. So for

13:56

example, a well-known port

13:59

is HD2. TPS, Port 80,

14:01

or 443. And if this

14:03

is being used by an

14:06

unknown or suspicious executable, or

14:08

something that isn't a web

14:10

application, or a browser, that

14:13

tends, or at least has

14:15

the potential of being interesting

14:17

for purposes of your investigation.

14:20

So low frequency usage of

14:22

certain ports by odd executables

14:25

is what you're looking for

14:27

here looking for here. The

14:29

next thing is poker hand

14:32

ports. This is something I've

14:34

brought up in the past.

14:36

If you look at open

14:39

source threat intelligence, you'll see

14:41

that this tends to come

14:43

up a lot. So ports

14:46

that resemble a winning poker

14:48

hand, so for instance, Port

14:50

44488 or Port 12345, tend

14:53

to come up because they're

14:55

easy to remember. from the

14:58

attacker's perspective. And if you

15:00

see anything like this, it's

15:02

just one of those, it's

15:05

interesting based on the historical

15:07

context or previous findings, don't

15:09

ignore it and may be

15:12

legitimate, something to keep in

15:14

mind. The next one is

15:16

to look for unusual paths.

15:19

So of course malware will

15:21

frequently masquerade. as legitimate file

15:24

names or it'll stash itself

15:26

in a user temp directory,

15:28

you're looking for any path

15:31

outside of what you expect

15:33

for application folders or system

15:35

folders. So you know that

15:38

system 32 subfolders. And of

15:40

course user profile directories. Here

15:42

is where you have to

15:45

look at what does not

15:47

belong when you're looking at

15:49

the data set as a

15:52

whole. for network activity. on

15:54

a given system, if you

15:57

look at all of the

15:59

network activity, where it's coming

16:01

from, where it's originating, within,

16:04

again, the context of these

16:06

Windows event codes, you should

16:08

see similar themes of source

16:11

directories. So just as I

16:13

mentioned, either a standard system

16:15

directories, or standard application directories.

16:18

Those should be readily apparent.

16:20

anything that falls outside of

16:22

that becomes interesting. Here is

16:25

where stacking and counting for

16:27

low frequency can really play

16:30

or really pay dividends. You

16:32

also could throw in here

16:34

since you get the name,

16:37

you know, any name that

16:39

is a bit suspicious. Now

16:41

you may actually have an

16:44

IOC, you may have derived

16:46

that from some threat intelligence

16:48

or something from another system.

16:51

But just keep that in

16:53

mind that when you have

16:56

the full file path in

16:58

the name, of course, you

17:00

have a lot of opportunity

17:03

to dig into that when

17:05

you're just looking for bad

17:07

in general. The next one

17:10

is to evaluate, evaluate, that

17:12

is, those protocol types. Again,

17:14

you're typically going to see

17:17

ICMP, TCP, TCP, and UDP.

17:19

So ICMP is going to

17:21

be represented by the number

17:24

one TCP6 and UDP. Anything

17:27

that falls outside of this,

17:29

a lesser known protocol, may

17:31

be normal, but it may

17:33

not be. Again, you need

17:36

to do the frequency analysis

17:38

here. So just looking, stacking,

17:40

and counting based on this

17:42

element, will probably tell you

17:44

what the most common ones

17:46

are, and you'll see the

17:48

low frequency outliers. Check those

17:50

out. That could be the

17:52

attacker trying to use a

17:54

specific protocol. Everything I'm mentioned

17:57

here for tree out strategy

17:59

can with just a little

18:01

work be automated in your

18:03

seam in your security appliance

18:05

or you know offline whether

18:07

or not that's going to

18:09

be an offline elk stack

18:11

that you spin up or

18:13

you're gonna have you some

18:15

other tool they typically are

18:17

going to give you some

18:20

way to search on or

18:22

I should say pivot around

18:24

on the different elements of

18:26

these. So knowing where to

18:28

go to for those quick

18:30

winds and then specifically what

18:32

to look for will allow

18:34

you, so in this case,

18:36

let's just say you're using,

18:38

we'll say Splunk, for instance,

18:41

that's a common one, can

18:43

easily operationalize this and Splunk.

18:45

With little preparation, you can

18:47

build the searches. a dashboard,

18:49

what have you, and you

18:51

could simply look at a

18:53

number of systems at once,

18:55

looking for these different things,

18:57

and pulling out those low-frequency

18:59

outliers, mismatches, what have you,

19:01

and probably in an hour

19:04

or less, depending on the

19:06

size of the data set,

19:08

have triaged this along with

19:10

the other... elements from the

19:12

other parts of the mini-series

19:14

or something like this, you

19:16

could do it very quickly,

19:18

especially if there are negative

19:20

findings. You're just going through

19:22

and if there's nothing interesting,

19:25

that's jumping out based on

19:27

this criteria. You go on

19:29

to the next one, on

19:31

to the next one, on

19:33

to the next one. But

19:35

when you do find something

19:37

interesting, that's when things, of

19:39

course, slow down, but that's

19:41

what you're looking for. That

19:43

may be the lead that

19:46

leads to... the information about

19:48

the breach or gives you

19:50

more information about the attacker's

19:52

activity in your environment. But

19:54

the important thing is to

19:56

be thorough and this here

19:58

gives you the blue on

20:00

how to be thorough with

20:02

these event logs, and also

20:04

be thorough and efficient at

20:06

the same time, which is

20:09

very key when you're working

20:11

these enterprise-level investigations. So with

20:13

that, that is going to

20:15

wrap up our network FastTriage

20:17

mini-series, so across the four

20:19

episodes, I've taken a good

20:22

look on how to leverage

20:24

Windows-based evidence. to quickly zero in

20:26

on compromise host or you're

20:28

just plain old suspicious activity.

20:30

As I mentioned if you

20:32

missed any of the earlier

20:34

episodes I definitely recommend going

20:36

back and listening to them

20:39

in order especially if anything

20:41

I said here you find

20:43

interesting but you feel you're

20:45

missing some of the context

20:47

the context is in those

20:49

previous episodes and of course

20:51

as always don't forget to

20:53

check out the SDF training

20:55

series. It's online on demand,

20:57

computer forensic training, and it's

20:59

aimed at teaching you a

21:02

valuable computer forensic skill, or

21:04

two, and a couple of

21:06

hours. You can find the

21:08

classes on Udami, that's udemy.com.

21:10

This type in the letters

21:12

SDF in a search bar,

21:14

and all of my classes

21:16

come up. You could also

21:18

go to the website, which

21:20

is security TTX.com,/SDF. All of

21:22

the classes are listed. there

21:24

as well. And with that,

21:26

it looks like it's time

21:28

to wrap up another episode.

21:30

As always, thanks for

21:32

listening.