1
00:00:14,720 --> 00:00:15,600
Outstanding.

2
00:00:15,780 --> 00:00:16,620
Apologies for that.

3
00:00:16,620 --> 00:00:17,980
So, my name is Aaron Seto.

4
00:00:17,980 --> 00:00:20,360
I am the Director of Learning at CoreLite.

5
00:00:20,360 --> 00:00:25,760
And today I'm going to be talking a little bit about the Zeek open source project in the light of OpenSoC.

6
00:00:25,760 --> 00:00:28,720
So, I've actually been part of the OpenSoC team for several years.

7
00:00:28,720 --> 00:00:32,540
Very excited to kind of talk about how these two projects are going to work together.

8
00:00:33,220 --> 00:00:38,400
Today's presentation was actually going to be a joint presentation with Amber, who is our Zeek Community Director.

9
00:00:38,400 --> 00:00:47,460
She had some unforeseen circumstances came up, so I'll be talking a little bit about the community piece, but I'll try and do it justice to her content.

10
00:00:47,640 --> 00:00:55,320
To kind of talk a little bit about... hold on, let me get my... I see that is going to be...

11
00:00:55,320 --> 00:00:57,680
I do not blame Discord right now.

12
00:00:57,680 --> 00:00:59,880
It just had the rug pulled out from under it.

13
00:00:59,880 --> 00:01:01,340
So, let me switch over to this.

14
00:01:01,740 --> 00:01:03,540
So, I'm going to talk a little bit about Zeek.

15
00:01:03,540 --> 00:01:04,460
What is Zeek?

16
00:01:04,460 --> 00:01:17,440
It's an open source framework that is used for network security monitoring, basically looking at network traffic.

17
00:01:17,440 --> 00:01:20,300
And you might have heard of Zeek as BRO.

18
00:01:20,300 --> 00:01:23,160
So, this was back in 1995.

19
00:01:23,160 --> 00:01:26,040
BRO started at Lawrence Berkeley National Labs.

20
00:01:26,040 --> 00:01:36,280
And there were a number of people who were looking into this problem space, and were thinking not even in a security context, but just looking at network traffic at large.

21
00:01:36,520 --> 00:01:51,080
And the name BRO really was kind of a nod to Big Brother, being like, this has a lot of surveillance potential, but it also has a lot of network security potential, which is obviously what we'll be focusing on today.

22
00:01:51,080 --> 00:02:04,200
But if you've heard of BRO or if you've heard of Zeek, it was probably as part of a research center university government, even potentially for like network forensics and network operations.

23
00:02:04,200 --> 00:02:08,880
There's actually some vendors, though I mentioned I'm employed by Corlite.

24
00:02:08,880 --> 00:02:14,640
There are a number of vendors who actually have Zeek integrated in with their platform and use it.

25
00:02:14,660 --> 00:02:18,200
So, if you've heard of it before, that's probably why.

26
00:02:18,600 --> 00:02:22,120
Zeek itself is actually very customizable, very extensible.

27
00:02:22,120 --> 00:02:24,380
It's really kind of its own language.

28
00:02:24,380 --> 00:02:36,160
And there's a lot that you can do with Zeek in terms of just having scripts and plugins and protocol analyzers and kind of these components that work together to analyze your network traffic.

29
00:02:36,200 --> 00:02:38,840
So, there's the Zeek package manager.

30
00:02:38,840 --> 00:02:43,340
If you go to packages.zeek.org, you can see all of these packages that the community has contributed.

31
00:02:43,340 --> 00:02:46,480
But you also, because it's open source, you can write your own.

32
00:02:46,480 --> 00:02:50,180
And so, there's actually a try.zeek.org environment where you can play around with that.

33
00:02:50,180 --> 00:02:52,200
And I'm not going to dive into that too much right now.

34
00:02:52,200 --> 00:02:53,940
I just want you to know that it's out there.

35
00:02:55,440 --> 00:02:57,940
So, what is the data?

36
00:02:57,940 --> 00:03:00,120
Like, the Zeek data is really where the power is.

37
00:03:00,120 --> 00:03:02,240
And I want to talk about what that looks like.

38
00:03:02,240 --> 00:03:07,500
So, I'm going to use three examples here, three logs to kind of start that conversation.

39
00:03:07,500 --> 00:03:09,280
On the left is the con log.

40
00:03:09,280 --> 00:03:11,820
So, that's the connection log.

41
00:03:11,820 --> 00:03:19,820
If you've ever seen NetFlow and it's got like IP addresses, ports, protocols, timestamps, like all this really high-level information, that's basically the con log.

42
00:03:19,820 --> 00:03:22,200
Every single connection will appear in the con log.

43
00:03:22,200 --> 00:03:25,340
But then there's these other logs that are more protocol-specific.

44
00:03:25,340 --> 00:03:27,240
So, let's say I have HTTP data.

45
00:03:27,240 --> 00:03:30,440
Like, I have a web browser talking to a web server.

46
00:03:30,600 --> 00:03:33,980
I'm going to see all of the metadata associated with that connection.

47
00:03:33,980 --> 00:03:37,040
So, things like what was the user agent string that was sent?

48
00:03:37,040 --> 00:03:39,880
What's the URI that was requested if you're talking about the client side?

49
00:03:39,880 --> 00:03:42,720
From the server side, like what was the MIME type that was returned?

50
00:03:42,720 --> 00:03:43,460
How many bytes?

51
00:03:43,460 --> 00:03:44,880
What was the status code?

52
00:03:44,880 --> 00:03:47,640
All of those things we see in our HTTP log.

53
00:03:47,660 --> 00:03:54,760
Similarly, if we're talking about other protocols, let's say like DNS, I can see the DNS, like the client and the server.

54
00:03:54,760 --> 00:04:00,920
I can also see the queries and the answers, the responses, which is surprisingly difficult to dig into sometimes.

55
00:04:00,920 --> 00:04:02,620
We'll talk about that more in a second.

56
00:04:03,000 --> 00:04:13,800
Now, realistically, there are only a few logs that you're really focused on in a given environment, in a given exercise, and frankly, even in OpenSoft.

57
00:04:13,920 --> 00:04:20,520
But, there are probably pushing four dozen logs in total now in the ZEKE OpenSource project.

58
00:04:20,520 --> 00:04:30,960
So, there's a log for pretty much any protocol you can think of, and all that metadata, that rich metadata from that protocol, is stored in that log for whatever purpose that you might need.

59
00:04:30,960 --> 00:04:32,980
I've got a couple links down at the bottom, too.

60
00:04:33,280 --> 00:04:34,900
CoreLite has a little PDF cheat sheet.

61
00:04:34,900 --> 00:04:36,640
I'll have that link for you in a second, too.

62
00:04:37,220 --> 00:04:43,780
And the ZEKE OpenSource project has really good detailed documentation about logs and even some things that didn't make the cheat sheet.

63
00:04:43,840 --> 00:04:48,700
That's actually where I stole these graphics from, was from the CoreLite cheat sheet, because it's a little more colorful.

64
00:04:49,900 --> 00:04:56,660
So, to really talk about how we use ZEKE, let me start off by kind of comparing a little bit.

65
00:04:56,660 --> 00:05:03,660
So , we need to see if things are actually fine, or if maybe things are fine, or if things are actually not true, then we get something from tools like Wireshark and gpdump.

66
00:05:03,740 --> 00:05:09,000
Or, in the middle, we have intrusion detection systems, intrusion prevention systems.

67
00:05:09,000 --> 00:05:21,540
So, things like Snort and Suricata, things that we'll find as we kind of work our way through just kind of looking at this kind of signature-based detection.

68
00:05:21,700 --> 00:05:23,700
And then, on the far right, we have NetFlow.

69
00:05:23,700 --> 00:05:29,900
We have the IP addresses, ports, protocols, timestamps, that kind of high-level information.

70
00:05:29,900 --> 00:05:38,020
These are three very common tools, which we'll see as you're kind of getting familiar, as you're probably already familiar with.

71
00:05:38,020 --> 00:05:41,320
But, let's use those to kind of compare ZEKE.

72
00:05:41,320 --> 00:05:46,580
To start off with, ZEKE is really fundamentally different from something like NetFlow.

73
00:05:46,580 --> 00:05:49,680
Well, it's fundamentally different from all of these, but let's start with NetFlow.

74
00:05:49,880 --> 00:06:03,800
So, NetFlow is giving us just that IP address, port, protocol, timestamp, just that generic info, versus something like ZEKE is going to be able to understand protocols at a much deeper level.

75
00:06:03,800 --> 00:06:09,820
So, it understands how something like HTTP works, and it can pull out all that metadata.

76
00:06:09,820 --> 00:06:14,420
It can even see things like files being sent over HTTP and extract those files out.

77
00:06:14,420 --> 00:06:18,000
So, we're not saving everything, we're saving the most useful tidbits.

78
00:06:18,540 --> 00:06:23,120
And really, when you're thinking of ZEKE, I don't want to talk about how it compares to some of these tools.

79
00:06:23,120 --> 00:06:26,240
I want to say, like, throw away your IDS, throw away NetFlow.

80
00:06:26,240 --> 00:06:27,520
What should be useful?

81
00:06:27,840 --> 00:06:30,540
Deploy ZEKE in parallel with these tools.

82
00:06:30,540 --> 00:06:42,560
And especially if you have something like full packet capture, then you can go ahead and use ZEKE to help find where the most interesting pieces of that full packet capture, that data resides.

83
00:06:43,460 --> 00:06:47,460
Now, comparing ZEKE to an IDS is something that's very commonly done.

84
00:06:47,460 --> 00:06:53,140
And I want to take just a second to talk to that, because ZEKE isn't here to say what's good or bad, or what's right or wrong.

85
00:06:53,140 --> 00:06:55,920
It's here to say, this is what's happening in the network right now.

86
00:06:59,180 --> 00:07:07,720
So if something goes south, it's because I need to respond to that, or at least I need to investigate it to look at it.

87
00:07:07,740 --> 00:07:14,580
But ZEKE is here logging everything that's going on and giving us the control to say, is this good or is this bad?

88
00:07:15,280 --> 00:07:18,800
Now, as I mentioned before, ZEKE is very expandable, very extensible.

89
00:07:18,820 --> 00:07:21,740
And so there's a lot of things that we can add on to ZEKE.

90
00:07:21,740 --> 00:07:25,540
We can kind of do things like, hey, if you see these kinds of anomalies, let me know.

91
00:07:25,540 --> 00:07:32,700
Because ZEKE understands protocols at such a low level, it can do things like say, hey, this looks like protocol abuse.

92
00:07:32,700 --> 00:07:37,880
This looks like a situation because I totally understand how this protocol should work.

93
00:07:37,880 --> 00:07:41,200
And this is not conforming to that standard.

94
00:07:41,220 --> 00:07:44,100
I'm going to go ahead and write a notice log.

95
00:07:44,100 --> 00:07:45,940
I'm going to go ahead and write something to the weird log.

96
00:07:45,940 --> 00:07:48,200
And we'll talk about some of those logs a little bit more in a second.

97
00:07:48,200 --> 00:07:50,560
But there's a lot of things that we can do with this.

98
00:07:50,920 --> 00:08:03,540
So when I'm talking about ZEKE data, what I'm really talking about is the representation of network traffic, of what you're seeing on your network as it's represented in ZEKE data.

99
00:08:03,540 --> 00:08:06,040
Now, there's a couple ways you can get those logs out.

100
00:08:06,040 --> 00:08:08,000
You can look at the raw ZEKE logs.

101
00:08:08,000 --> 00:08:10,620
And we'll kind of see a little bit of that today.

102
00:08:10,700 --> 00:08:27,820
But as you normally use in an enterprise, and as you'll use in OpenSOC, that data is being forwarded to a SIEM where you can interact with that and get the context of all the other host-based data and everything else that's coming into that SIEM environment.

103
00:08:27,940 --> 00:08:36,000
So in case you haven't guessed already, our SIEM of choice for OpenSOC, if you were watching the workshop earlier, is Greylog.

104
00:08:36,000 --> 00:08:38,620
And so we'll talk about what this looks like in Greylog.

105
00:08:38,880 --> 00:08:47,700
But one of the things that is... before we jump into that, I want to talk about how we kind of associate these logs with each other.

106
00:08:47,700 --> 00:08:51,020
So remember I said we have a CON log and an HTTP log.

107
00:08:51,300 --> 00:09:09,580
And so every connection that comes in, I'll see in my CON log, but every time there's some HTTP data, HTTP application layer protocol identified in this connection, there will be an HTTP log for that connection that has all that relevant metadata.

108
00:09:09,580 --> 00:09:12,400
Now, the question becomes, how do I kind of pivot?

109
00:09:12,400 --> 00:09:16,180
I see something in my CON log, and I know there's HTTP in there.

110
00:09:16,180 --> 00:09:19,540
How do I go find the matching thing in my HTTP log?

111
00:09:19,920 --> 00:09:24,760
So the way you're going to do that is with what's called the UID, or the connection unique ID.

112
00:09:24,760 --> 00:09:30,640
And that's something that every time there's a mention of this connection, it's going to appear in any one of these logs.

113
00:09:30,640 --> 00:09:36,880
So if I have a connection, let's say, that uses HTTP, and let's say it transfers a file.

114
00:09:36,880 --> 00:09:46,360
Well, then I'm going to see that same UID in my CON log, in my HTTP log, in my files log, and each one of those logs is going to give me the information about that file transfer.

115
00:09:46,360 --> 00:09:51,160
On the topic of file transfers, there's another type of unique ID called the file unique ID.

116
00:09:51,160 --> 00:10:05,880
And similarly, if I kind of want to pivot around and investigate a file that's happening, or that I'm interested in, then I can use that file unique ID and search through logs and see what connections are associated with that unique ID.

117
00:10:06,660 --> 00:10:10,860
So, all right, I've done a lot of the explanation.

118
00:10:10,860 --> 00:10:14,260
I want to dive into one pretty thorough use case.

119
00:10:14,260 --> 00:10:15,500
And I want to do this for two reasons.

120
00:10:15,500 --> 00:10:19,820
One, I want to get you in the mindset of how an incident responder thinks.

121
00:10:19,820 --> 00:10:21,720
And for some of us, that's not a stretch.

122
00:10:21,720 --> 00:10:23,480
And for some of us, that might be a little new.

123
00:10:23,560 --> 00:10:30,860
But the second thing I want to do is I want to show you how you would use just a ZEKE data to work through a particular incident.

124
00:10:30,860 --> 00:10:37,560
And so let's say I'm fresh out of college or fresh out of another career field I'm pivoting.

125
00:10:37,560 --> 00:10:40,680
And I just joined this team.

126
00:10:40,680 --> 00:10:42,400
I'm a SOC analyst.

127
00:10:42,400 --> 00:10:43,680
I'm entry level.

128
00:10:43,720 --> 00:10:49,880
And as is tradition, I am awarded the honor of the night shift.

129
00:10:49,880 --> 00:10:52,740
And I'm sitting here, and I'm watching alerts roll in.

130
00:10:52,740 --> 00:10:55,500
And it's my job to kind of triage these alerts.

131
00:10:55,500 --> 00:11:11,340
So I'm trying to figure out when something comes in, do I have like a playbook or procedure, something that I can fall back to, to say I know how to handle this, we've seen this before, or I have something in my playbook that I know how to resolve this myself.

132
00:11:11,580 --> 00:11:15,340
Is it maybe instead something that I can dismiss?

133
00:11:15,340 --> 00:11:18,580
I can say, well, this is a false positive, or this is not actionable.

134
00:11:18,680 --> 00:11:20,000
Okay, somebody's port scanning.

135
00:11:20,000 --> 00:11:20,880
Doesn't matter.

136
00:11:20,880 --> 00:11:22,700
I can't really do anything about it.

137
00:11:22,700 --> 00:11:27,300
Or in the third case, do I need to escalate this?

138
00:11:27,300 --> 00:11:37,680
Do I need to bring this to someone, a senior member of our team, who can then spend a little bit more time looking at this, or maybe has the expertise to work through this?

139
00:11:38,060 --> 00:11:40,040
And so it's 2 a.m.

140
00:11:40,040 --> 00:11:40,780
I'm sitting here.

141
00:11:40,780 --> 00:11:42,000
I'm watching these alerts roll in.

142
00:11:42,000 --> 00:11:43,680
I'm trying to figure out, can I deal with this?

143
00:11:43,680 --> 00:11:45,820
Can I deal with this myself?

144
00:11:45,820 --> 00:11:46,860
Can I dismiss this?

145
00:11:46,860 --> 00:11:48,460
Do I need to escalate this?

146
00:11:48,460 --> 00:11:52,060
And an alert comes in from our Intrusion Detection System.

147
00:11:52,060 --> 00:11:58,980
And it says, hey, I saw a DNS request leaving the network, and the host name in that DNS request matched the signature.

148
00:11:58,980 --> 00:12:02,140
So the IDS raised an alert to say, I know that.

149
00:12:02,140 --> 00:12:07,000
I have a signature that says that's associated with a known command and control server, a C2 server.

150
00:12:07,000 --> 00:12:08,400
So what am I going to do?

151
00:12:08,400 --> 00:12:10,060
Can I deal with this myself?

152
00:12:10,060 --> 00:12:11,200
Can I dismiss this?

153
00:12:11,200 --> 00:12:12,420
Do I need to escalate this?

154
00:12:12,420 --> 00:12:17,640
And if I just have this data to look at this, I might start off in my DNS log.

155
00:12:17,640 --> 00:12:22,220
So I mentioned there's a log for DNS, and this is a DNS-related alert.

156
00:12:22,220 --> 00:12:30,520
Let me turn to my DNS log, and I'm going to see the workstation or stations, potentially, that have tried to reach out and look up that host name.

157
00:12:30,520 --> 00:12:34,280
The DNS servers that responded to that, which maybe is something internal.

158
00:12:34,280 --> 00:12:39,980
Maybe it's an external DNS server, depending on how I can block that from leaving my network.

159
00:12:39,980 --> 00:12:45,800
I see the query itself, which in theory my IDS already told me, so it's not really that big of a deal.

160
00:12:45,800 --> 00:12:48,740
But the big one here is the answer field.

161
00:12:48,740 --> 00:12:50,080
It's literally called answer.

162
00:12:50,080 --> 00:12:54,520
There's a field in your DNS log, and it is the response that was provided to the client.

163
00:12:54,520 --> 00:12:58,540
So in this case, I know the client queried for this host name.

164
00:12:58,540 --> 00:13:00,880
I want to know what IP address they got back.

165
00:13:00,880 --> 00:13:09,000
A lot of times, even with good DNS logging setup, if you have your DNS server set up to forward logs, a lot of times they won't give you that last piece.

166
00:13:09,000 --> 00:13:11,260
They won't give you the answer, the IP address.

167
00:13:11,260 --> 00:13:16,100
And I need that, because I need to pivot from my DNS log to my con log.

168
00:13:16,100 --> 00:13:28,500
The question that I'm asking myself right now is, okay, I know that there was a DNS request leaving the network, but was there a connection that followed that to the IP address that was resolved?

169
00:13:28,620 --> 00:13:34,080
Maybe I had an intrusion prevention system that stopped it.

170
00:13:34,080 --> 00:13:40,120
Maybe I got lucky and the attacker's infrastructure was down, and I just dodged that bullet.

171
00:13:40,120 --> 00:13:42,200
But I want to know if there was a connection.

172
00:13:42,200 --> 00:13:43,240
I want to know more about it.

173
00:13:43,240 --> 00:13:45,400
And let's say for the sake of this example, there was.

174
00:13:45,400 --> 00:13:46,680
There was a connection.

175
00:13:47,260 --> 00:13:54,860
And so I can pivot from my DNS log to my con log, look for connections to that IP address, say that there were connections.

176
00:13:54,860 --> 00:13:56,280
I want to see what ports they're on.

177
00:13:56,280 --> 00:13:57,040
When did they happen?

178
00:13:57,040 --> 00:13:58,280
Are they still happening?

179
00:13:58,280 --> 00:14:00,620
How many bytes were sent either way?

180
00:14:00,940 --> 00:14:05,600
And ports in particular is interesting, because I want to know a little bit more about this communication.

181
00:14:05,600 --> 00:14:11,860
Let's say for the sake of this example that the communication to that server was on port 80.

182
00:14:12,040 --> 00:14:15,000
Well, the more veterans of you might say, port 80 is obviously HTTP.

183
00:14:15,000 --> 00:14:15,900
I know that.

184
00:14:16,020 --> 00:14:19,960
But hang on, put your attacker hat on for a second and think about this.

185
00:14:20,020 --> 00:14:24,560
An attacker doesn't have to use the port for its intended purpose.

186
00:14:24,560 --> 00:14:28,120
So just because they're on port 80 doesn't mean they're using HTTP.

187
00:14:28,320 --> 00:14:34,120
But one of the cool things Zeke does is it has what's called dynamic protocol detection, DPD.

188
00:14:34,120 --> 00:14:41,380
So I'll see in my con log a field called service that tells me the protocols identified.

189
00:14:41,380 --> 00:14:45,700
Zeke knows, regardless of what port it's on, what's going on inside that connection.

190
00:14:45,700 --> 00:14:48,320
And so it'll say, yep, I know there's HTTP inside of here.

191
00:14:48,320 --> 00:14:49,860
I don't care that it's on port 80.

192
00:14:49,860 --> 00:14:54,100
I mean, obviously, that wouldn't be what we would expect.

193
00:14:54,260 --> 00:14:57,980
But Zeke tells me certainly this has HTTP traffic.

194
00:14:57,980 --> 00:15:03,020
So I'm going to pivot now from my con log to my HTTP log to get more information.

195
00:15:03,020 --> 00:15:06,040
And how do I pivot between those two logs?

196
00:15:06,480 --> 00:15:09,620
The connection unique identifier, that UID field.

197
00:15:09,620 --> 00:15:14,520
Remember, that appears in every single log that has information about this connection.

198
00:15:14,520 --> 00:15:21,880
So I'm going to look to that UID field and look to see if I have a matching entry in my HTTP log.

199
00:15:21,880 --> 00:15:25,980
And in there, I'm going to see things that relate to this connection.

200
00:15:25,980 --> 00:15:29,160
Things like user agent strings and cookie values, get push parameters.

201
00:15:29,160 --> 00:15:33,220
Things that the browser sends as part of that request.

202
00:15:33,220 --> 00:15:34,980
And also I get some response information.

203
00:15:34,980 --> 00:15:42,120
And these are things that you'll hear the term indicator, or an IOC, or an indicator of compromise.

204
00:15:42,120 --> 00:15:46,920
These are things that might help us figure out exactly what this is, what malware strain we're dealing with.

205
00:15:46,920 --> 00:15:54,960
And that's something that, again, I might be able to go back to previous incidents and playbooks and community resources and say, Hey, what is this thing?

206
00:15:54,960 --> 00:15:57,720
Does anybody recognize this string that looks a little bit weird?

207
00:15:57,720 --> 00:16:00,720
Do I know what malware that's associated with?

208
00:16:01,840 --> 00:16:05,060
And so, if so, I might be able to handle this myself.

209
00:16:05,060 --> 00:16:06,840
I might say, all right, cool.

210
00:16:07,320 --> 00:16:09,900
This is an incident that I know how to resolve.

211
00:16:09,900 --> 00:16:13,020
I'm going to go ahead and quarantine, you know, kick that machine off the network.

212
00:16:13,260 --> 00:16:14,620
I'll contact the user.

213
00:16:14,620 --> 00:16:19,460
We'll start an IT ticket, get it re-imaged, and probably reset the user's password.

214
00:16:20,040 --> 00:16:22,120
But, okay, I can handle it, right?

215
00:16:22,860 --> 00:16:25,620
But, I like being the worst-case scenario person.

216
00:16:25,620 --> 00:16:28,920
What happens if I don't know how to deal with this?

217
00:16:28,920 --> 00:16:35,360
What happens if I don't have any indicators that I can pull up and say I know what malware strain this is?

218
00:16:35,380 --> 00:16:39,220
Let's say, for the sake of this example, that this is a downloader.

219
00:16:39,220 --> 00:16:48,580
This is a piece of malware that kind of establishes a foothold on this compromised workstation and then beacons out to a C2 server and starts downloading additional malware.

220
00:16:48,580 --> 00:16:59,420
It's going to bring back tools, things that might potentially let the attacker find a foothold on this workstation or within this network.

221
00:16:59,420 --> 00:17:13,820
So, in that case, I would see all these HTTP connections and I would see mentions in my files log so I could pivot from the HTTP log to the files log using that connection ID again and say, hey, what files are being transferred here?

222
00:17:13,820 --> 00:17:20,500
Specifically, I'm looking for... so Zeke has the ability to extract MD5, SHA-1, and SHA-256 checksum.

223
00:17:20,580 --> 00:17:24,420
And so these checksums are things that, again, can be an indicator of compromise.

224
00:17:24,420 --> 00:17:27,080
Another IOC that I can use and go back and say, what is this?

225
00:17:27,460 --> 00:17:33,280
Maybe I don't know what the downloader is, but I can kind of know what these other tools are and I can start to understand what the capabilities of this are.

226
00:17:33,280 --> 00:17:43,320
I can also look around my network and see what other machines have seen those hashes and maybe there's other machines that are part of this compromise that I'm just now discovering now.

227
00:17:45,660 --> 00:17:49,560
But let's say... I don't know, I like being the worst case scenario person.

228
00:17:49,560 --> 00:17:59,400
Let's say that the attacker gets a foothold on that machine and starts deleting evidence, which, you know, putting my open-sock hat on for a second, it's been known to happen.

229
00:17:59,400 --> 00:18:02,640
So let's say the attacker goes in and starts to clean up after themselves.

230
00:18:02,640 --> 00:18:08,280
And I'm like, well, great, all the information on that endpoint now that the evidence is getting erased.

231
00:18:08,280 --> 00:18:11,780
Well, remember I talked about Zeke having file extraction.

232
00:18:11,780 --> 00:18:23,180
So I can pull out those files as they go across the wire, save them to disk, and even if they get deleted, you know, zero-wise, wiped, whatever, off that workstation, I still have those binaries.

233
00:18:23,180 --> 00:18:32,680
So putting my worst case scenario hat on again, if I say, all right, well, the evidence has gone over there, I still have these binaries that I can go back to and figure out exactly what they're capable of.

234
00:18:32,680 --> 00:18:41,580
If I have to escalate this and, you know, it's 2.15 in the morning now, and I have to call one of the senior members of my team to say, yo, this looks bad.

235
00:18:41,780 --> 00:18:44,020
You know, I'm pretty sure this is an actual incident.

236
00:18:44,340 --> 00:18:46,200
Here are the things that I know so far.

237
00:18:46,200 --> 00:18:47,800
I know the IP address that we're getting out to.

238
00:18:47,800 --> 00:18:51,700
I can tell you all the hosts that are talking to that host name or that IP address.

239
00:18:51,800 --> 00:18:56,940
I have some indicators that we can potentially write some IDS signatures for so we can catch this in the future.

240
00:18:57,020 --> 00:19:05,400
I have these SHA-1, MB5, and SHA-26 hashes that we can, you know, search the network, and I can tell you what machines have this malware associated with them.

241
00:19:05,400 --> 00:19:10,720
So I figured out the scope, and I mean both in time and in the hosts associated with this.

242
00:19:11,000 --> 00:19:20,640
And if we have to bring in, you know, reverse engineers or, you know, malware analysis people, they have those binaries they can start tearing through.

243
00:19:20,640 --> 00:19:27,960
So even in the worst case scenario, I've got a lot of evidence here, even without talking about anything on the endpoint at all.

244
00:19:28,180 --> 00:19:39,780
So I know I belabor this quite a bit, but I think it's powerful to talk through kind of the questions that you'll be asking yourself as you're going through something like an open-socket exercise or a real-world exercise.

245
00:19:39,780 --> 00:19:41,100
They're shockingly similar.

246
00:19:41,920 --> 00:19:47,960
And also to understand where you go in the ZEKE data to understand those questions a little bit better.

247
00:19:48,000 --> 00:19:52,000
So there's many ways, as I mentioned, that this ZEKE data can be represented.

248
00:19:52,000 --> 00:19:57,540
So here I have a screenshot of Splunk, which is, you know, you can get a free version and pipe the data into Splunk.

249
00:19:57,540 --> 00:20:01,200
And so, sure, that's a thing, you know, if you're a Splunk person.

250
00:20:01,200 --> 00:20:03,500
We had a talk earlier on Kibana.

251
00:20:03,500 --> 00:20:12,160
Instead of asking if you're using the Elastic, the Elk stack, you can feed this data into Kibana and look at it that way as well.

252
00:20:12,400 --> 00:20:16,200
But our tool of choice in open-socket is going to be Greylock.

253
00:20:16,320 --> 00:20:20,560
And so you should get comfortable with what this looks like in Greylock.

254
00:20:20,560 --> 00:20:28,400
So to start off with, when you get access to the open-socket environment and you go to Greylock, you might end up looking at a screen like this.

255
00:20:28,400 --> 00:20:32,100
When you click on the screens, you're just going to get the stream of data.

256
00:20:32,100 --> 00:20:34,340
This is everything that's going across the network right now.

257
00:20:34,340 --> 00:20:35,840
It's a ton of data, right?

258
00:20:36,260 --> 00:20:45,520
And so as you're looking through this, I want to talk to you a little bit about the Greylock interface, but also we'll use it to kind of talk about what the ZEKE data will look like.

259
00:20:45,520 --> 00:20:53,140
So to start off with, you'll notice that I've typed a query into my Greylock window here that I am looking for ZEKE data.

260
00:20:53,140 --> 00:21:02,160
Specifically, I am asking Greylock to search for a field called event type, and I want you to tell me when that event type equals ZEKE.

261
00:21:02,160 --> 00:21:10,380
And so this is going to limit down the events that are returned back to me as part of this UI.

262
00:21:10,580 --> 00:21:19,580
And so this is a gotcha that you'll find again and again, especially in open-socket, where you'll be looking for an artifact and you're like, I can't find it, it's not here, I don't know where it is.

263
00:21:19,580 --> 00:21:28,280
It's because you probably have your search set to the last five minutes, and if you're looking for something that happened several hours ago, well, yeah, you're not going to see it.

264
00:21:28,280 --> 00:21:34,980
So I'm also going to go ahead and turn down, or turn up, I guess you could say, my search window to a larger window.

265
00:21:34,980 --> 00:21:41,440
Maybe I have a particular time span and I can input that, but right now I'm just kind of taking a casual stroll through the data.

266
00:21:41,540 --> 00:21:48,000
So with those things, I'm going to scroll down a little bit, and on the right-hand side here, you see the Greylock events.

267
00:21:48,000 --> 00:22:01,420
And so these are Zeek events, specifically, and you'll notice there's a lot of them, but each one of these is a Zeek log, a line in a Zeek log that's giving me some information about communication that happened.

268
00:22:01,420 --> 00:22:05,760
And if I click on any given one of them, you'll notice the event type is Zeek, that's why this was returned.

269
00:22:05,760 --> 00:22:10,080
And there's a lot of information here inside this particular log entry.

270
00:22:10,080 --> 00:22:16,500
The first thing that you should look at, the first thing I want you to get familiar with, is this file field.

271
00:22:16,500 --> 00:22:19,620
And the file field tells me which type of log is this.

272
00:22:19,620 --> 00:22:23,700
In this particular case, I'm looking at a MySQL log or a MySQL log.

273
00:22:23,700 --> 00:22:27,780
So this is going to have information about a database transaction that occurred here.

274
00:22:27,780 --> 00:22:31,720
Now, if you look down a little bit further, you will see the message, which is the line.

275
00:22:31,860 --> 00:22:35,520
These are the individual fields of the MySQL log.

276
00:22:35,520 --> 00:22:43,860
Now, there's one thing I'm going to come completely clean here, and some of the logs that you'll see, they're really parsed that cleanly.

277
00:22:43,860 --> 00:22:50,100
So for something like this, I have to kind of turn back to some of those cheat feeds for that documentation to figure out, like, what does each field mean?

278
00:22:50,100 --> 00:22:57,460
Like, I can see the first field is a timestamp, and the second field that starts with a C, that's my connection unique ID, so that's something I can pivot off of.

279
00:22:57,460 --> 00:23:00,440
I see some IP addresses, some ports, I see a MySQL query.

280
00:23:00,440 --> 00:23:05,260
Sometimes it's a little self-explanatory, but refer to that documentation as needed.

281
00:23:05,260 --> 00:23:06,880
Let me give you another example here.

282
00:23:06,880 --> 00:23:08,820
So I'm scrolling down, looking at another entry.

283
00:23:08,820 --> 00:23:11,980
Again, event type is Zeke, that'll be consistent.

284
00:23:11,980 --> 00:23:16,280
But instead now, I'm looking at the con log, so this is that connection log.

285
00:23:16,280 --> 00:23:19,580
This is giving me information about a connection that occurred.

286
00:23:19,860 --> 00:23:25,440
And I see the message down here that those fields, which you'll also notice, all the fields have been broken out for me.

287
00:23:25,440 --> 00:23:28,280
So I can see the connection state, the destination IP.

288
00:23:28,320 --> 00:23:31,120
There's a Boolean that tells me, is that inside my network?

289
00:23:31,140 --> 00:23:33,400
And that's a Zeke variable that gets set.

290
00:23:33,400 --> 00:23:35,560
I get to see, you know, the destination port.

291
00:23:35,560 --> 00:23:38,200
The history field is actually a really interesting one.

292
00:23:38,200 --> 00:23:41,640
I don't have nearly enough time to dive into it, but it's really well documented.

293
00:23:41,640 --> 00:23:46,560
And it tells you kind of the order of things that happened inside the communication.

294
00:23:46,680 --> 00:23:48,000
So there's a lot of things here.

295
00:23:48,000 --> 00:23:53,740
And also, you'll notice, I could scroll down, but I can also see it here in the message field, that connection unique ID.

296
00:23:53,900 --> 00:23:55,980
So, sure, there's a connection here.

297
00:23:55,980 --> 00:23:57,860
All right, it's on port 80.

298
00:23:57,860 --> 00:23:59,180
Is it HTTP?

299
00:23:59,180 --> 00:24:01,180
Well, I see HTTP in my message there.

300
00:24:01,180 --> 00:24:04,260
And if I were to scroll down, I would see that as part of my service field.

301
00:24:04,260 --> 00:24:13,380
But I can look and search, write a great log query to search for that connection unique ID, and find all the information associated with this particular connection.

302
00:24:13,700 --> 00:24:15,760
So as we scroll down a little bit further...

303
00:24:15,760 --> 00:24:18,300
Oh, look, here's an HTTP log entry.

304
00:24:18,360 --> 00:24:21,940
And so this file here tells me I'm looking at the HTTP log.

305
00:24:21,940 --> 00:24:24,240
I get a little information from the client side.

306
00:24:24,240 --> 00:24:28,700
So it looks like this was a GET request for the slash link on the root page.

307
00:24:28,720 --> 00:24:30,940
So I can see a little bit of information from the client.

308
00:24:30,940 --> 00:24:33,140
I can see a little bit of information from the server.

309
00:24:33,140 --> 00:24:36,840
I respond back with a 200 OK, which is perfectly normal.

310
00:24:36,840 --> 00:24:37,280
Right .

311
00:24:37,660 --> 00:24:40,380
At least that's what I would generally expect.

312
00:24:40,380 --> 00:24:43,900
And so all these fields, again, are broken out for me as I work my way through.

313
00:24:43,900 --> 00:24:47,680
One more log entry I want to talk about is the files log.

314
00:24:47,680 --> 00:24:52,200
So I mentioned that whenever we see a file transfer, the example I used was HTTP.

315
00:24:52,200 --> 00:24:57,640
But it actually works over SMB, SMTP, HTTP, FTP.

316
00:24:58,300 --> 00:25:00,380
I'm sure I'm forgetting many of them.

317
00:25:00,380 --> 00:25:05,180
But fundamentally, if we can see a file transfer that's happening, we can pull that off the wire.

318
00:25:05,320 --> 00:25:10,560
And so you'll see an entry in your files log that gives you things like the LIME type.

319
00:25:10,560 --> 00:25:13,520
So, oh, this looks like it was an MP4 video.

320
00:25:13,540 --> 00:25:17,600
I get those hashes, those checksum values, which in the case of a video...

321
00:25:17,600 --> 00:25:19,160
Maybe that's interesting or not.

322
00:25:19,300 --> 00:25:21,840
Or a document, that might be a lot more interesting.

323
00:25:21,840 --> 00:25:25,580
That might be something that would be a very interesting indicator to key off of.

324
00:25:25,980 --> 00:25:28,300
In some cases, you'll see the file name.

325
00:25:28,300 --> 00:25:32,460
In this particular case, this was part of an HTTP connection that just wasn't provided in a header.

326
00:25:32,460 --> 00:25:34,920
We just couldn't extract it for one reason or another.

327
00:25:35,060 --> 00:25:39,060
But if we do get the opportunity to pull a file name off the wire, we'll happily do that.

328
00:25:39,300 --> 00:25:41,760
There's one thing that I didn't have an arrow to on the slide.

329
00:25:41,760 --> 00:25:45,360
And that, as you'll notice just under the file name, is the file unique ID.

330
00:25:45,360 --> 00:25:50,820
And so similar to the connection unique ID that starts with a C, the file unique ID starts with an F.

331
00:25:50,820 --> 00:25:54,380
And that tells me that this is associated with a file transfer.

332
00:25:55,080 --> 00:25:56,700
So there's a lot of data.

333
00:25:56,700 --> 00:26:03,040
I'm just giving you the highlights, and I promise you're going to see some of those in some OpenSock scenarios later.

334
00:26:03,040 --> 00:26:05,820
Not that, you know, I don't want to spoil too much.

335
00:26:06,160 --> 00:26:09,480
I'll put these URLs in the Discord chat as well.

336
00:26:09,480 --> 00:26:12,640
I'll also post a PDF of these slides, so you'll have these.

337
00:26:12,720 --> 00:26:16,880
But these are the two resources I would suggest to get comfortable with Zik data.

338
00:26:16,880 --> 00:26:18,600
So the thing on the left is the PDF.

339
00:26:18,600 --> 00:26:19,960
I like it because it's searchable.

340
00:26:19,960 --> 00:26:29,560
The thing on the right is the Zik documentation from Read the Docs that does a much better job of going into more depth and has more logs that didn't really make the cut on the cheat sheet.

341
00:26:29,980 --> 00:26:35,600
So I only have a few minutes left, and I want to talk very briefly about the Zik community.

342
00:26:35,720 --> 00:26:42,260
And by all rights, this would be Amber here talking about, as a community director, she would talk authoritatively about this.

343
00:26:42,260 --> 00:26:47,120
And there's so much that's going on now and on the roadmap.

344
00:26:47,120 --> 00:26:52,100
Fundamentally, the things that you should know about is head to Zik.org slash connect.

345
00:26:52,100 --> 00:26:53,820
So Zik.org is the Zik website.

346
00:26:53,820 --> 00:26:54,700
They've got a YouTube channel.

347
00:26:54,700 --> 00:27:07,160
They've got a Twitter account that's constantly posting and retweeting new packages and things that are relevant to current vulnerabilities that are blowing up Twitter.

348
00:27:07,360 --> 00:27:13,660
Zik started a Slack organization, a Slack channel, which Discord... I'm working on it.

349
00:27:14,240 --> 00:27:24,820
Slack is the home of a lot of these really great conversations that you can have alongside the Zik developers, the package developers, and they're a really approachable community.

350
00:27:24,820 --> 00:27:33,020
That said, because it has such a long history to it, there are also some very good mailing lists that you should join as well.

351
00:27:33,200 --> 00:27:37,860
On the bottom left, you see there are a lot of in-person events, obviously not happening at the moment.

352
00:27:37,860 --> 00:27:40,760
But keep an eye out if you hear Zik Hour, Zik Days.

353
00:27:40,940 --> 00:27:48,460
These are kind of local organizations, so you can kind of come and hang out for a happy hour and meet people.

354
00:27:48,580 --> 00:27:53,320
In fact, you can kind of help Amber organize your own if this is something that you want to bring to your area.

355
00:27:53,380 --> 00:27:55,180
I'll give you her contact information.

356
00:27:55,180 --> 00:27:56,980
She'll be eager to talk to you.

357
00:27:57,100 --> 00:28:03,000
Zik Week is actually an annual event that we do, so it's all these conversations about Zik package development.

358
00:28:03,000 --> 00:28:15,200
Things from like, how are Blue Teamers using this to defend themselves, all the way down to like the lowest internals of the Zik ecosystem.

359
00:28:15,540 --> 00:28:19,380
There are also now a lot of virtual events that are happening.

360
00:28:19,380 --> 00:28:26,400
So if you check out the Zik.org site or the Zik Slack, you'll hear about a lot of online events that are happening.

361
00:28:27,560 --> 00:28:37,840
There's Zik from Home, there's Ask the Zik-sperts, which is where they bring in a lot of experts, and you can just be like, hey, I'm trying to install Zik at home, and I'm hitting this error, and they'll happily walk you through it.

362
00:28:38,180 --> 00:28:40,240
Super, super approachable community.

363
00:28:40,800 --> 00:28:44,300
And to that end, I would encourage you to contribute to that community.

364
00:28:44,300 --> 00:29:01,060
So a lot of folks, especially approaching open source, think, well, hey, I'm just getting started, or hey, you know, yeah, I'm working on this Blue Team thing, and I'm figuring this out, but I don't know anything about development or, well, anything about what seems like it would be needed here.

365
00:29:01,060 --> 00:29:07,620
And I want to dispel that, because there's so many skills that are required to make this work.

366
00:29:07,620 --> 00:29:10,220
So yes, you might be thinking in code.

367
00:29:10,220 --> 00:29:13,240
You might be saying, well, I'm not a good coder.

368
00:29:13,240 --> 00:29:23,740
Well, okay, what about looking into the user community and contributing to, as you're installing this, and you're saying, hey, this documentation, you know, is a little bit unclear.

369
00:29:23,740 --> 00:29:26,900
Or, hey, I tried to do this, and this documentation didn't work for me.

370
00:29:26,900 --> 00:29:31,580
Let me fire off something on the mailing list and say, hey, I have some suggestions.

371
00:29:31,800 --> 00:29:35,680
How do I, you know, make some proposals to the documentation?

372
00:29:35,920 --> 00:29:37,680
Maybe you want to try your hand at scripting.

373
00:29:37,680 --> 00:29:41,920
Scripting is actually pretty approachable, and there's so much that you can do in the Zika language.

374
00:29:42,080 --> 00:29:52,740
Things that are just very simple that are going to help you in your day-to-day, versus like, hey, there's a protocol I just want to tear into, whatever that might be.

375
00:29:52,920 --> 00:29:57,940
Maybe you're just saying, hey, you know, I don't know anything about Zika yet.

376
00:29:58,140 --> 00:29:59,460
Where could I start?

377
00:29:59,540 --> 00:30:00,360
Download it.

378
00:30:00,360 --> 00:30:04,720
Get some of the latest releases and give us an okay and say, yep, we tested it out.

379
00:30:04,720 --> 00:30:05,120
It worked.

380
00:30:05,120 --> 00:30:08,240
Help us test releases and get that feedback.

381
00:30:08,240 --> 00:30:17,240
So there's so much that you can do, and it's so tempting to think of this as like, I'm at the bottom of this ladder, and I don't have the skills that I need to climb it.

382
00:30:17,280 --> 00:30:21,200
And Amber has this awesome metaphor about, think of this as a lattice.

383
00:30:21,200 --> 00:30:23,660
Think about kind of moving diagonally.

384
00:30:23,660 --> 00:30:29,980
Think about kind of charting your own path and building your own skill set as you're contributing back to the community.

385
00:30:29,980 --> 00:30:34,280
This goes for so many communities, but I think for Zika, it's especially true.

386
00:30:34,620 --> 00:30:41,760
So there are a couple links that I threw down earlier, the link to the Zika documentation.

387
00:30:41,760 --> 00:30:48,220
So if you're interested in deploying Zika locally, probably something I would recommend putting on until after OpenStock, because you're going to have a busy weekend.

388
00:30:48,460 --> 00:30:50,040
But you've got the link there.

389
00:30:50,040 --> 00:30:51,700
Again, I'll post these in the Discord.

390
00:30:51,720 --> 00:31:00,180
Security Onion, a lot of you know, as kind of the Cali for blue team, it's a Linux distribution that has all of these tools built into them, including Zika.

391
00:31:00,180 --> 00:31:14,920
And so if you're interested in just having kind of a live environment, I wouldn't recommend it for like a full production environment, but for just getting your feet wet and understanding how this works together with these other tools, Security Onion is a fantastic starting point.

392
00:31:14,920 --> 00:31:18,660
I mentioned that PDF, so I've got the link to the PDF there.

393
00:31:18,660 --> 00:31:21,720
And oh, by the way, there's this event that's happening called OpenStock.

394
00:31:21,860 --> 00:31:26,420
If you haven't joined the OpenStock Discord yet, there's a lot that's happening there.

395
00:31:26,420 --> 00:31:30,840
It starts tomorrow, but you can swing on by, you can get registered and set up.

396
00:31:30,840 --> 00:31:37,540
Check out the DC28 OpenStock CTF in the Blue Team Village Discord for more information about that.

397
00:31:37,960 --> 00:31:42,180
So with that said, I think I am pretty darn close to time here.

398
00:31:42,180 --> 00:31:45,480
I want to leave you with my contact info, Aaron Soto at Corelite.com.

399
00:31:45,480 --> 00:31:57,760
Amber is our Zika Community Director, an incredible resource, and just constantly has these amazing plans for the Zika community and helping it grow.

400
00:31:57,760 --> 00:32:03,560
So if you are interested at all, there's also a Zikurity Twitter account that I mentioned.

401
00:32:03,640 --> 00:32:06,020
There's a Zik channel in that OpenStock Discord.

402
00:32:06,020 --> 00:32:12,800
So even if you're not going to play OpenStock, come join the Zik channel and kind of have the conversation there.

403
00:32:12,800 --> 00:32:14,400
Keep an eye out for a lot of these online events.

404
00:32:14,400 --> 00:32:16,340
As I mentioned, Zik From Home, Ask the Zik Experts.

405
00:32:16,340 --> 00:32:19,240
There's a lot more on the way that I'm sure Amber could write a lot.

406
00:32:19,340 --> 00:32:27,020
And we're also doing, not quite as cool as OpenStock, I'll admit, but some community CTFs to help you learn the Zik environment.

407
00:32:27,020 --> 00:32:31,980
So with that said, I know I am pretty darn close to time.

408
00:32:32,420 --> 00:32:36,760
Did we have any questions from the chat?

409
00:32:36,900 --> 00:32:43,920
I'm going to scroll and kind of take a quick look here, but if you have any...

410
00:32:44,680 --> 00:32:48,160
I'm actually happy to have a conversation with folks afterwards.

411
00:32:48,320 --> 00:32:51,200
As I know, we are pretty darn close.

412
00:32:51,320 --> 00:32:54,220
I'm hearing people ask about, you know, how hard is it to set up?

413
00:32:54,220 --> 00:32:55,460
I'd encourage you if you...