WEBVTT

1
00:00:00.120 --> 00:00:03.399
<v Speaker 1>Welcome back to the deep dive. We're your shortcut to

2
00:00:03.439 --> 00:00:07.839
<v Speaker 1>getting well, incredibly well informed without feeling totally overwhelmed.

3
00:00:08.000 --> 00:00:09.519
<v Speaker 2>Yeah, there's a lot out there.

4
00:00:09.400 --> 00:00:13.359
<v Speaker 1>There really is. So today we're diving into something powerful,

5
00:00:13.400 --> 00:00:16.199
<v Speaker 1>maybe a bit underestimated, a kind of secret weapon that's

6
00:00:16.199 --> 00:00:21.559
<v Speaker 1>actually been part of computing for decades. Foundational really exactly,

7
00:00:21.920 --> 00:00:25.440
<v Speaker 1>but it's becoming super critical now in cybersecurity. Okay, let's

8
00:00:25.519 --> 00:00:30.079
<v Speaker 1>unpack this. We are talking about cybersecurity operations, but maybe

9
00:00:30.120 --> 00:00:32.719
<v Speaker 1>not with the fancy, expensive tools you might think of. First,

10
00:00:32.759 --> 00:00:34.479
<v Speaker 1>we're talking about the command line.

11
00:00:34.840 --> 00:00:38.960
<v Speaker 2>Ah, yes, good old command line, specifically the Bash Shehell.

12
00:00:39.359 --> 00:00:42.320
<v Speaker 1>Our guide for this is a really practical book, Cybersecurity

13
00:00:42.359 --> 00:00:46.359
<v Speaker 1>Ops with Bash, Attack, Defend and Analyze from the command

14
00:00:46.359 --> 00:00:49.759
<v Speaker 1>Line by Paul Truncone and Carl Alvin. Great resource, totally,

15
00:00:50.280 --> 00:00:52.359
<v Speaker 1>and our mission today is to give you a shortcut

16
00:00:52.560 --> 00:00:54.600
<v Speaker 1>a way to see how Bash isn't just you know,

17
00:00:54.640 --> 00:00:58.759
<v Speaker 1>for developers coding away or cised men's managing servers. It's

18
00:00:58.799 --> 00:01:02.560
<v Speaker 1>this incredibly flexible multi tool anyone interested in computer security,

19
00:01:02.759 --> 00:01:05.519
<v Speaker 1>whether you're on the offense probing systems or on defense

20
00:01:05.560 --> 00:01:08.879
<v Speaker 1>building walls, attack or defend. Yeah, and the cool thing

21
00:01:08.959 --> 00:01:12.159
<v Speaker 1>is the techniques work, whether you're on Linux, mac Os,

22
00:01:12.560 --> 00:01:13.799
<v Speaker 1>even Windows these days.

23
00:01:13.920 --> 00:01:16.799
<v Speaker 2>And what's truly fascinating here, I think is just how

24
00:01:16.840 --> 00:01:19.799
<v Speaker 2>fundamental the command line is. I mean, most of us, right,

25
00:01:19.959 --> 00:01:24.079
<v Speaker 2>we spend our time clicking around in graphical interfaces. Guisappoint

26
00:01:24.159 --> 00:01:27.159
<v Speaker 2>click and they're great, super easy to use, no doubt,

27
00:01:27.560 --> 00:01:32.439
<v Speaker 2>but that ease it often costs you something speed, maybe flexibility,

28
00:01:32.879 --> 00:01:35.560
<v Speaker 2>and you definitely get distanced from what the system is

29
00:01:35.599 --> 00:01:36.439
<v Speaker 2>actually doing.

30
00:01:36.280 --> 00:01:38.480
<v Speaker 1>Underneath, like a layer of abstraction exactly.

31
00:01:38.519 --> 00:01:41.400
<v Speaker 2>GUIs are like that nice dashboard in your car. Looks good,

32
00:01:41.519 --> 00:01:44.200
<v Speaker 2>tells you the basics, but the command line that's like

33
00:01:44.239 --> 00:01:46.000
<v Speaker 2>lifting the hood. You're right there with the engine.

34
00:01:46.120 --> 00:01:48.040
<v Speaker 1>Okay. I like that analogy, and this.

35
00:01:48.200 --> 00:01:51.319
<v Speaker 2>Deep dive hopefully will kind of reconnect you to that

36
00:01:51.439 --> 00:01:55.120
<v Speaker 2>raw power, show you that Bash is this direct, super

37
00:01:55.159 --> 00:01:58.560
<v Speaker 2>efficient way to tap into everything your operating system can do.

38
00:01:58.760 --> 00:02:01.560
<v Speaker 1>Getting under the hood. I like, yeah, So, okay, why

39
00:02:01.599 --> 00:02:07.640
<v Speaker 1>Bash specifically for cybersecurity? It still feels a bit basic.

40
00:02:07.879 --> 00:02:11.599
<v Speaker 2>Well, it's basic in the best sense, you know, it's foundational.

41
00:02:11.639 --> 00:02:14.919
<v Speaker 2>It's universal. Bash started in the Unix and Linux world obviously,

42
00:02:15.199 --> 00:02:18.439
<v Speaker 2>but it's just everywhere now. It's standard on macOS, and

43
00:02:18.520 --> 00:02:20.719
<v Speaker 2>you can get it really easily on Windows is get

44
00:02:20.759 --> 00:02:26.599
<v Speaker 2>Bash seguine or the Window subsystem for Linux WSL WSL. Yeah,

45
00:02:26.639 --> 00:02:29.360
<v Speaker 2>which means the stuff we talk about today. These aren't

46
00:02:29.479 --> 00:02:33.319
<v Speaker 2>niche skills. They are incredibly transferable. You learn the stuff once,

47
00:02:33.560 --> 00:02:35.759
<v Speaker 2>you can probably use it almost any way you might

48
00:02:35.800 --> 00:02:37.840
<v Speaker 2>need to secure a system or figure out what.

49
00:02:37.800 --> 00:02:40.280
<v Speaker 1>Happened on one. Okay, So it's like the ultimate cross

50
00:02:40.280 --> 00:02:43.000
<v Speaker 1>platform utility belt for security folks pretty much. But to

51
00:02:43.039 --> 00:02:46.639
<v Speaker 1>really use that belt effectively, especially for tricky security tasks,

52
00:02:47.080 --> 00:02:49.400
<v Speaker 1>we probably need to nail down some and core ideas first.

53
00:02:50.159 --> 00:02:53.039
<v Speaker 1>What are the essential bits of Bash that make it

54
00:02:53.120 --> 00:02:53.719
<v Speaker 1>so good for this?

55
00:02:54.360 --> 00:02:58.120
<v Speaker 2>Yeah, definitely if we connect this to the bigger picture,

56
00:02:58.800 --> 00:03:02.039
<v Speaker 2>the real power often comes from how Bash handles data,

57
00:03:02.520 --> 00:03:06.599
<v Speaker 2>how it moves information around data streams exactly. Every program

58
00:03:06.639 --> 00:03:10.280
<v Speaker 2>fundamentally has like three channels, one for input coming in stin,

59
00:03:10.719 --> 00:03:13.000
<v Speaker 2>one for normal output going out strout, and one for

60
00:03:13.120 --> 00:03:14.280
<v Speaker 2>error messages.

61
00:03:14.000 --> 00:03:16.400
<v Speaker 1>Sure, okay, in out and oops.

62
00:03:16.599 --> 00:03:20.599
<v Speaker 2>Yeah basically. But the magic and where Bash really shines

63
00:03:20.639 --> 00:03:22.919
<v Speaker 2>for security work is redirection and piping.

64
00:03:23.319 --> 00:03:23.599
<v Speaker 1>Right.

65
00:03:23.759 --> 00:03:26.400
<v Speaker 2>This is what lets you chain simple commands together to

66
00:03:26.439 --> 00:03:30.520
<v Speaker 2>build surprisingly powerful custom tools like right on the spot.

67
00:03:30.639 --> 00:03:32.680
<v Speaker 1>So redirection is sending stuff places.

68
00:03:32.879 --> 00:03:35.039
<v Speaker 2>Yep. You can send the normal output of a command

69
00:03:35.080 --> 00:03:38.400
<v Speaker 2>straight into a file maybe command results dot out, or

70
00:03:38.400 --> 00:03:40.400
<v Speaker 2>if you want to add to a file that's already there,

71
00:03:40.520 --> 00:03:43.719
<v Speaker 2>you use up and it tended exactly and you can

72
00:03:43.759 --> 00:03:46.719
<v Speaker 2>send just the error messages somewhere else. Maybe two aero

73
00:03:46.719 --> 00:03:50.240
<v Speaker 2>loog dot txt, or combine both normal output and errors

74
00:03:50.240 --> 00:03:53.159
<v Speaker 2>into one file with evan in handy, or just make

75
00:03:53.199 --> 00:03:55.520
<v Speaker 2>output disappear entirely if you don't need it, send it

76
00:03:55.560 --> 00:03:58.479
<v Speaker 2>to dubnel, kind of like a black hole for data. Okay,

77
00:03:58.759 --> 00:04:01.560
<v Speaker 2>And one more really full one is t That command

78
00:04:01.719 --> 00:04:03.879
<v Speaker 2>lets you see the output on your screen while it's

79
00:04:03.879 --> 00:04:06.759
<v Speaker 2>also saving it to a file. Great for monitoring something

80
00:04:06.800 --> 00:04:08.360
<v Speaker 2>live but also keeping a record.

81
00:04:08.560 --> 00:04:11.479
<v Speaker 1>Right, see it and save it makes sense. And piping

82
00:04:11.639 --> 00:04:13.759
<v Speaker 1>that's the connector right the symbol. That's the one.

83
00:04:14.000 --> 00:04:16.879
<v Speaker 2>Piping takes the standard output from the command on the

84
00:04:16.959 --> 00:04:19.720
<v Speaker 2>left and feeds it directly as the standard input to

85
00:04:19.720 --> 00:04:20.360
<v Speaker 2>the command on the.

86
00:04:20.399 --> 00:04:22.759
<v Speaker 1>Right, connecting the tools precisely.

87
00:04:22.879 --> 00:04:26.399
<v Speaker 2>This is how you build those complex workflows from simple

88
00:04:26.399 --> 00:04:29.319
<v Speaker 2>building blocks. It's like creating an assembly line for your

89
00:04:29.399 --> 00:04:32.959
<v Speaker 2>data right there in the terminal okay, And one more thing.

90
00:04:33.720 --> 00:04:35.560
<v Speaker 2>If you have a command that might take a while,

91
00:04:35.720 --> 00:04:38.600
<v Speaker 2>like maybe pinging a machine constantly to see if it's up,

92
00:04:39.120 --> 00:04:41.560
<v Speaker 2>you can run it in the background using the ampersand

93
00:04:41.680 --> 00:04:44.240
<v Speaker 2>so like ping one two point one sixty eight point

94
00:04:44.240 --> 00:04:48.160
<v Speaker 2>one point one and ping results do log. It just

95
00:04:48.279 --> 00:04:51.480
<v Speaker 2>runs quietly, logs its output and gives you your prompt

96
00:04:51.519 --> 00:04:52.319
<v Speaker 2>back immediately.

97
00:04:52.480 --> 00:04:53.279
<v Speaker 1>Oh that's useful.

98
00:04:53.399 --> 00:04:55.480
<v Speaker 2>Yeah, And you can check on those background tasks with

99
00:04:55.480 --> 00:04:58.079
<v Speaker 2>the jobs command and bring one back to the foreground

100
00:04:58.120 --> 00:04:59.959
<v Speaker 2>with FG if you need to interact with it.

101
00:05:00.079 --> 00:05:00.399
<v Speaker 1>Got it.

102
00:05:00.600 --> 00:05:03.439
<v Speaker 2>And beyond just moving data, remember Bash is a full

103
00:05:03.480 --> 00:05:06.240
<v Speaker 2>on programming language too. You've got variables, you can read input,

104
00:05:06.279 --> 00:05:09.920
<v Speaker 2>you have if statements, wild loops, functions, you can automate

105
00:05:09.959 --> 00:05:10.680
<v Speaker 2>almost anything.

106
00:05:10.959 --> 00:05:14.199
<v Speaker 1>That flexibility is huge. Okay, but here's something you mentioned

107
00:05:14.240 --> 00:05:17.279
<v Speaker 1>in the book that seems to trip people up a lot. Honestly,

108
00:05:17.319 --> 00:05:18.519
<v Speaker 1>it confused me at first too.

109
00:05:18.959 --> 00:05:23.600
<v Speaker 2>Ah, let me guess shell patterns versus regular expressions.

110
00:05:23.920 --> 00:05:29.319
<v Speaker 1>Bingo. It gets really interesting here. What's the fundamental difference

111
00:05:29.480 --> 00:05:32.160
<v Speaker 1>and why is getting them mixed up such a potential

112
00:05:32.240 --> 00:05:33.360
<v Speaker 1>problem in security?

113
00:05:33.600 --> 00:05:36.120
<v Speaker 2>It's a great question, and yeah, it is critical for

114
00:05:36.199 --> 00:05:40.639
<v Speaker 2>doing things accurately. So shell patterns think for match anything,

115
00:05:40.720 --> 00:05:43.079
<v Speaker 2>for match any single character for a range like a

116
00:05:43.160 --> 00:05:46.560
<v Speaker 2>ZA right the file globbing stuff exactly. They're primarily designed

117
00:05:46.600 --> 00:05:50.160
<v Speaker 2>for matching filenames in the filesystem. When you type ls

118
00:05:50.199 --> 00:05:52.639
<v Speaker 2>dot log, you're telling the shell itself to find all

119
00:05:52.720 --> 00:05:54.240
<v Speaker 2>filenames ending in dot log.

120
00:05:54.319 --> 00:05:56.519
<v Speaker 1>Okay, so it's about the names of files, correct.

121
00:05:56.600 --> 00:06:00.319
<v Speaker 2>Now. Regular expressions or rejects are different beasts, which more

122
00:06:00.319 --> 00:06:04.000
<v Speaker 2>powerful patterns designed for matching text content stuff inside files

123
00:06:04.399 --> 00:06:05.920
<v Speaker 2>or within a stream of data.

124
00:06:05.680 --> 00:06:07.160
<v Speaker 1>Like searching inside a log file.

125
00:06:07.279 --> 00:06:11.720
<v Speaker 2>Precisely. Rejects has a much richer, sometimes more complex set

126
00:06:11.759 --> 00:06:14.639
<v Speaker 2>of special characters and rules. And you use rejects with

127
00:06:14.720 --> 00:06:17.959
<v Speaker 2>tools that process text like rep or AUC or said.

128
00:06:18.279 --> 00:06:21.240
<v Speaker 1>So, different tools, different patterns, yeah.

129
00:06:20.759 --> 00:06:23.480
<v Speaker 2>And confusing them. That can lead to you missing crucial

130
00:06:23.519 --> 00:06:26.319
<v Speaker 2>evidence because you used a file name pattern to search

131
00:06:26.360 --> 00:06:29.160
<v Speaker 2>file content, or maybe doing something unintended because your pattern

132
00:06:29.199 --> 00:06:30.519
<v Speaker 2>match files you didn't expect.

133
00:06:30.759 --> 00:06:32.680
<v Speaker 1>Can you give a quick example, sure.

134
00:06:32.600 --> 00:06:36.600
<v Speaker 2>Find varlogdash name dot gz uses a show pattern dot

135
00:06:36.639 --> 00:06:38.920
<v Speaker 2>gz to find filenames ending in GZ.

136
00:06:39.160 --> 00:06:40.360
<v Speaker 1>Simple okay, But.

137
00:06:40.439 --> 00:06:44.839
<v Speaker 2>Grep error zerosh nine plus farlow gap dot log uses

138
00:06:44.879 --> 00:06:48.360
<v Speaker 2>a regular expression error zero zero nine plus to find

139
00:06:48.439 --> 00:06:50.920
<v Speaker 2>lines inside the app dot log file that contain the

140
00:06:50.959 --> 00:06:53.680
<v Speaker 2>word error followed by one or more digits.

141
00:06:53.800 --> 00:06:56.759
<v Speaker 1>Ah, Okay, one looks at the label, the other looks

142
00:06:56.759 --> 00:06:57.519
<v Speaker 1>inside the box.

143
00:06:57.560 --> 00:06:59.560
<v Speaker 2>That's a great way to put it. Understanding that difference

144
00:06:59.600 --> 00:07:01.439
<v Speaker 2>is vital for precise investigation.

145
00:07:01.639 --> 00:07:04.800
<v Speaker 1>Definitely. Okay. Let's shift gears into our first deep dive

146
00:07:04.920 --> 00:07:09.000
<v Speaker 1>area defensive security operations with Bash. Using Bash as the

147
00:07:09.040 --> 00:07:12.360
<v Speaker 1>investigator's toolkit, how do we usually frame defensive thinking?

148
00:07:12.519 --> 00:07:15.360
<v Speaker 2>Well, A really helpful framework is the five principles of

149
00:07:15.399 --> 00:07:21.639
<v Speaker 2>cybersecurity Confidentiality, integrity, availability, non repudiation, and authentication, often called

150
00:07:21.720 --> 00:07:27.680
<v Speaker 2>CIANA for short CIA. Briefly, confidentiality is about keeping secrets

151
00:07:27.839 --> 00:07:33.160
<v Speaker 2>secret only authorized access. Integrity means making sure data hasn't

152
00:07:33.199 --> 00:07:37.240
<v Speaker 2>been messed with it's trustworthy. Availability is ensuring systems and

153
00:07:37.319 --> 00:07:40.040
<v Speaker 2>data are there when you need them right. Non Repudiation

154
00:07:40.240 --> 00:07:42.639
<v Speaker 2>is about proof linking in action to a specific user

155
00:07:42.680 --> 00:07:46.000
<v Speaker 2>so they can't deny it. And authentication is simply proving

156
00:07:46.480 --> 00:07:47.879
<v Speaker 2>you are who you say you are.

157
00:07:48.120 --> 00:07:49.680
<v Speaker 1>Okay, the core security goals.

158
00:07:49.519 --> 00:07:53.319
<v Speaker 2>Exactly, So the important question for us becomes, how does Bash,

159
00:07:53.439 --> 00:07:56.759
<v Speaker 2>this command line tool actually help us maintain these principles,

160
00:07:57.319 --> 00:07:59.959
<v Speaker 2>or maybe more importantly, how does it help us investigate

161
00:08:00.120 --> 00:08:02.240
<v Speaker 2>when we suspect one of them has been violated?

162
00:08:02.319 --> 00:08:04.439
<v Speaker 1>That makes sense. It grounds what we're doing. So if

163
00:08:04.439 --> 00:08:07.639
<v Speaker 1>we're thinking about actually doing defense or investigating an incident,

164
00:08:07.720 --> 00:08:11.480
<v Speaker 1>say checking data integrity or figuring out the confidentiality impact

165
00:08:11.480 --> 00:08:14.920
<v Speaker 1>of a breach, Bash becomes our hands on toolkit. Where

166
00:08:14.920 --> 00:08:17.319
<v Speaker 1>do we start maybe data collection and analysis.

167
00:08:17.600 --> 00:08:20.759
<v Speaker 2>Absolutely, when something happens you need to gather evidence quickly

168
00:08:20.800 --> 00:08:23.879
<v Speaker 2>and thoroughly. Bash gives you these direct tools. You've got

169
00:08:23.920 --> 00:08:26.680
<v Speaker 2>simple things like cut to pull out specific columns of

170
00:08:26.759 --> 00:08:29.000
<v Speaker 2>data file to quickly tell you what kind of file

171
00:08:29.040 --> 00:08:31.399
<v Speaker 2>you're looking at, header tail to peak at the starter

172
00:08:31.560 --> 00:08:35.320
<v Speaker 2>end of logs. The basics, the powerful, basic, And what's

173
00:08:35.360 --> 00:08:37.879
<v Speaker 2>really neat is this isn't just a Linux Mac thing.

174
00:08:37.960 --> 00:08:41.000
<v Speaker 2>If you're using git Bash on a Windows machine, you

175
00:08:41.000 --> 00:08:44.720
<v Speaker 2>can call native Windows command line tools directly, things like

176
00:08:44.919 --> 00:08:47.919
<v Speaker 2>reg to query the Windows registry oh wow, or web

177
00:08:47.919 --> 00:08:51.240
<v Speaker 2>toodle to work with Windows event logs. You can investigate

178
00:08:51.279 --> 00:08:54.679
<v Speaker 2>Windows systems using the same Bash skills. That cross platform

179
00:08:54.679 --> 00:08:57.200
<v Speaker 2>ability is a huge win for analysts.

180
00:08:56.720 --> 00:09:00.000
<v Speaker 1>So you're not constantly switching mental gears between operating systems.

181
00:09:00.440 --> 00:09:03.639
<v Speaker 1>What about grabbing log files, say for later analysis.

182
00:09:03.759 --> 00:09:06.480
<v Speaker 2>Super efficient. On Linux, you can package up all the

183
00:09:06.519 --> 00:09:09.639
<v Speaker 2>logs in varlog into one compressed file, like sealing an

184
00:09:09.639 --> 00:09:13.639
<v Speaker 2>evidence bag, with a command like tarh ccf O scs

185
00:09:13.759 --> 00:09:16.720
<v Speaker 2>ez name logs, dot tr dot gz varlog easy.

186
00:09:16.840 --> 00:09:17.240
<v Speaker 1>Nice.

187
00:09:17.240 --> 00:09:19.799
<v Speaker 2>On Windows, you can script webtoodle to export all the

188
00:09:19.799 --> 00:09:22.919
<v Speaker 2>different event logs. And here's a really powerful technique for

189
00:09:22.960 --> 00:09:24.919
<v Speaker 2>remote systems, dotsh.

190
00:09:24.639 --> 00:09:25.320
<v Speaker 1>It cure shell.

191
00:09:25.440 --> 00:09:28.000
<v Speaker 2>Yeah, you don't even need to log into the remote machine.

192
00:09:28.000 --> 00:09:31.639
<v Speaker 2>Sometimes you can run a command remotely like swash user

193
00:09:31.679 --> 00:09:34.440
<v Speaker 2>at remote server command and get the output back on

194
00:09:34.480 --> 00:09:37.320
<v Speaker 2>your local machine, or even run a local script on

195
00:09:37.399 --> 00:09:40.600
<v Speaker 2>the remote machine like swash user at remote server, Bash,

196
00:09:40.840 --> 00:09:45.919
<v Speaker 2>dash s dot mylocalscript, dot sh The script itself never

197
00:09:45.960 --> 00:09:49.480
<v Speaker 2>has to be copied over there. It's efficient and sometimes stealthier.

198
00:09:49.679 --> 00:09:52.279
<v Speaker 1>Okay, that's very cool for quick data grabs. So once

199
00:09:52.320 --> 00:09:55.039
<v Speaker 1>you have the data, maybe logs or files from a system,

200
00:09:55.279 --> 00:09:57.399
<v Speaker 1>it can be a lot of data. How do you

201
00:09:57.480 --> 00:09:59.840
<v Speaker 1>start searching through it effectively? With Bash?

202
00:10:00.320 --> 00:10:03.639
<v Speaker 2>Yeah, finding the needle in the haystack. Bash's fine command

203
00:10:03.799 --> 00:10:06.039
<v Speaker 2>is your go to for searching based on filenames and

204
00:10:06.080 --> 00:10:07.240
<v Speaker 2>other file attributes.

205
00:10:07.399 --> 00:10:08.799
<v Speaker 1>Like finding suspicious file.

206
00:10:08.720 --> 00:10:11.960
<v Speaker 2>Names exactly find dash name password. Could search the whole

207
00:10:12.000 --> 00:10:14.600
<v Speaker 2>system for files with password in the name, use in

208
00:10:14.720 --> 00:10:18.120
<v Speaker 2>name for case insensitive, or find hitting files which often

209
00:10:18.159 --> 00:10:20.320
<v Speaker 2>start with a dot on Linux or Mac fine home

210
00:10:20.399 --> 00:10:23.240
<v Speaker 2>name maagine. Remember that dot is a shell pattern matching

211
00:10:23.279 --> 00:10:24.519
<v Speaker 2>file names starting with a dot.

212
00:10:24.639 --> 00:10:28.320
<v Speaker 1>Got it filenames? What about searching inside the files for

213
00:10:28.440 --> 00:10:29.759
<v Speaker 1>keywords or indicators.

214
00:10:30.000 --> 00:10:35.320
<v Speaker 2>That's where GRIP comes in. Grap ir some directory suspicious pattern.

215
00:10:35.679 --> 00:10:39.039
<v Speaker 2>The I makes it case insensitive, R makes it recursive

216
00:10:39.080 --> 00:10:42.440
<v Speaker 2>through directories, and E specifies the pattern, which would typically

217
00:10:42.519 --> 00:10:45.279
<v Speaker 2>be a regular expression here that you're looking for within

218
00:10:45.320 --> 00:10:45.840
<v Speaker 2>the files.

219
00:10:45.960 --> 00:10:49.440
<v Speaker 1>Okay, find for names grap for content makes sense. What

220
00:10:49.519 --> 00:10:53.240
<v Speaker 1>about checking if files have been tampered with that integrity piece?

221
00:10:53.399 --> 00:10:58.480
<v Speaker 2>Ah? Yes, Message digests or hashes tools like chess on

222
00:10:58.519 --> 00:11:01.759
<v Speaker 2>some or md fivesome creator a unique digital fingerprint for

223
00:11:01.799 --> 00:11:04.159
<v Speaker 2>a file. I could check some sort of but much

224
00:11:04.159 --> 00:11:07.480
<v Speaker 2>more cryptographically strong. The key property is that changing even

225
00:11:07.639 --> 00:11:10.399
<v Speaker 2>one single bit in the file will produce a completely

226
00:11:10.399 --> 00:11:11.320
<v Speaker 2>different hash value.

227
00:11:11.399 --> 00:11:11.639
<v Speaker 1>Wow.

228
00:11:11.759 --> 00:11:13.879
<v Speaker 2>Okay, So if you calculate the hash of a critical

229
00:11:13.919 --> 00:11:16.320
<v Speaker 2>system file and compare it to a known good value,

230
00:11:16.480 --> 00:11:18.600
<v Speaker 2>you can tell instantly if it's been modified. It's a

231
00:11:18.600 --> 00:11:21.919
<v Speaker 2>fundamental integrity check. You can script Bash to check hashes

232
00:11:21.960 --> 00:11:23.279
<v Speaker 2>of many files very quickly.

233
00:11:23.440 --> 00:11:26.840
<v Speaker 1>Powerful stuff. Okay, moving on to data processing and analysis.

234
00:11:26.960 --> 00:11:30.039
<v Speaker 1>You've collected logs, maybe found some interesting files. How does

235
00:11:30.120 --> 00:11:33.080
<v Speaker 1>Bash help make sense of, say a massive web server log.

236
00:11:33.440 --> 00:11:36.799
<v Speaker 2>This is where combining tools with pipes really shines. Think

237
00:11:36.840 --> 00:11:40.759
<v Speaker 2>about an Apache Access dot log, huge file, lots of lines. Right,

238
00:11:40.879 --> 00:11:43.840
<v Speaker 2>you can use cut to extract just the IP address

239
00:11:43.879 --> 00:11:46.399
<v Speaker 2>a the first field, then pipe that into sort, then

240
00:11:46.440 --> 00:11:49.360
<v Speaker 2>pipe that into unique miss to count occurrences, and finally

241
00:11:49.360 --> 00:11:51.840
<v Speaker 2>pipe that into sort. Dice on to see which ips

242
00:11:51.919 --> 00:11:55.759
<v Speaker 2>made the most requests. Four simple commands chained together give

243
00:11:55.799 --> 00:11:56.879
<v Speaker 2>you a top talkers list.

244
00:11:56.919 --> 00:11:59.720
<v Speaker 1>It's pretty neat turning raw logs into a summary exact.

245
00:12:00.480 --> 00:12:02.960
<v Speaker 2>Or you could use ak, which is brilliant for field

246
00:12:03.039 --> 00:12:05.840
<v Speaker 2>based processing. Maybe you want to find which ips are

247
00:12:05.840 --> 00:12:08.480
<v Speaker 2>getting lots of four O four not found errors, AC

248
00:12:08.679 --> 00:12:11.919
<v Speaker 2>nine dollars easials four O four print one dollar. Access

249
00:12:11.919 --> 00:12:15.639
<v Speaker 2>dot log could print the IP address field one from

250
00:12:15.720 --> 00:12:18.559
<v Speaker 2>lines where the status code field nine is four oh four.

251
00:12:18.720 --> 00:12:20.240
<v Speaker 2>Pipe that through your sertunic chain again.

252
00:12:20.320 --> 00:12:21.799
<v Speaker 1>Help spot reconnaissance scanning.

253
00:12:21.840 --> 00:12:24.000
<v Speaker 2>Maybe could be or maybe you want to see who's

254
00:12:24.000 --> 00:12:26.679
<v Speaker 2>transferring the most data, use cut or ok to get

255
00:12:26.679 --> 00:12:29.240
<v Speaker 2>the IP address and the number of bytes transferred. Then

256
00:12:29.320 --> 00:12:32.120
<v Speaker 2>use another script maybe like the summer chistish example from

257
00:12:32.159 --> 00:12:34.879
<v Speaker 2>the book, to total the bytes per IP. Sort that

258
00:12:35.120 --> 00:12:37.759
<v Speaker 2>and a huge spike for one IP that might warrant

259
00:12:37.799 --> 00:12:39.519
<v Speaker 2>investigation for data exultration.

260
00:12:39.960 --> 00:12:43.559
<v Speaker 1>Right, checking the confidentiality wasn't breached precisely, and you can

261
00:12:43.600 --> 00:12:45.840
<v Speaker 1>even visualize this stuff simply in the terminal.

262
00:12:46.120 --> 00:12:48.679
<v Speaker 2>The book has examples like histogram dot ash that can

263
00:12:48.720 --> 00:12:51.960
<v Speaker 2>take counts or totals and draw basic bar charts right there.

264
00:12:52.039 --> 00:12:53.200
<v Speaker 2>Quick visual checks.

265
00:12:53.360 --> 00:12:58.120
<v Speaker 1>Very cool. Okay. One more defensive area real time log monitoring,

266
00:12:59.120 --> 00:13:00.600
<v Speaker 1>watching things as they happen.

267
00:13:00.679 --> 00:13:03.679
<v Speaker 2>Yeah, super important for catching things early. The classic command

268
00:13:03.759 --> 00:13:08.039
<v Speaker 2>here is tail dash F PATHTOLG file follow the file right.

269
00:13:08.080 --> 00:13:10.159
<v Speaker 2>It just sits there and prints new lines as they

270
00:13:10.159 --> 00:13:12.080
<v Speaker 2>get added to the end of the file. But the

271
00:13:12.080 --> 00:13:15.240
<v Speaker 2>real power comes when you pipe that live stream.

272
00:13:15.159 --> 00:13:17.519
<v Speaker 1>Ah pipe tail dash f output.

273
00:13:17.720 --> 00:13:20.440
<v Speaker 2>Yes, pipe it into rep or egrep using the line

274
00:13:20.440 --> 00:13:23.200
<v Speaker 2>buffered options, so it processes each line immediately, and you

275
00:13:23.200 --> 00:13:25.759
<v Speaker 2>can filter that live stream for keywords or patterns so

276
00:13:25.840 --> 00:13:26.200
<v Speaker 2>you can.

277
00:13:26.080 --> 00:13:29.600
<v Speaker 1>Watch for specific errors or maybe log in attempts exactly.

278
00:13:29.879 --> 00:13:32.960
<v Speaker 2>You could even build a simple lightweight intrusion detection system

279
00:13:33.039 --> 00:13:36.919
<v Speaker 2>and IDs have a file say ioc dot txt with

280
00:13:37.080 --> 00:13:40.879
<v Speaker 2>known bad patterns indicators of compromise like attempts to access

281
00:13:40.879 --> 00:13:45.080
<v Speaker 2>sensitive files et cetera, paswd, or run commands pinch. Then

282
00:13:45.159 --> 00:13:47.600
<v Speaker 2>you tail dash f your weblog and pipe it into

283
00:13:47.840 --> 00:13:53.120
<v Speaker 2>egrep lineh buffer dash fioc dot txt. It will only

284
00:13:53.120 --> 00:13:55.639
<v Speaker 2>show you the lines that match your bad patterns, alerting

285
00:13:55.639 --> 00:13:56.440
<v Speaker 2>you in real time.

286
00:13:56.600 --> 00:13:59.399
<v Speaker 1>Wow. Okay, a homegrown IDs with just tail.

287
00:13:59.200 --> 00:14:01.320
<v Speaker 2>And rep pretty much, and you can do similar things

288
00:14:01.320 --> 00:14:04.159
<v Speaker 2>on Windows. The book has a windtail dot sh script

289
00:14:04.200 --> 00:14:06.519
<v Speaker 2>that uses web toodle in a loop to simulate tail

290
00:14:06.600 --> 00:14:08.519
<v Speaker 2>dash f for Windows event logs.

291
00:14:08.279 --> 00:14:10.440
<v Speaker 1>Bringing that real time view to Windows logs too.

292
00:14:10.559 --> 00:14:12.679
<v Speaker 2>And you can take it further. There are scripts like

293
00:14:12.720 --> 00:14:15.639
<v Speaker 2>webdash dot sh that use terminal control commands to create

294
00:14:15.679 --> 00:14:19.399
<v Speaker 2>simple dashboards. They repeatedly run several commands, maybe monitoring different

295
00:14:19.440 --> 00:14:22.399
<v Speaker 2>logs or system stats, and repaint the screen, giving you

296
00:14:22.480 --> 00:14:24.559
<v Speaker 2>multiple live views in one terminal window.

297
00:14:24.639 --> 00:14:27.759
<v Speaker 1>Okay, so Bash is definitely a powerhouse for defense and investigation.

298
00:14:28.000 --> 00:14:30.960
<v Speaker 1>Let's flip the coin now penetration testing with Bash. Thinking

299
00:14:31.200 --> 00:14:34.200
<v Speaker 1>like an adversary. How does Bash fit into the attacker's toolkit?

300
00:14:34.279 --> 00:14:35.440
<v Speaker 1>Is there a structure they follow?

301
00:14:35.679 --> 00:14:39.799
<v Speaker 2>Often yes, especially for more organized attackers. It's rarely just

302
00:14:39.919 --> 00:14:43.320
<v Speaker 2>random hacking. A useful model to understand the phases is

303
00:14:43.399 --> 00:14:46.799
<v Speaker 2>Mandiance attack life cycle. It lays out typical steps.

304
00:14:46.879 --> 00:14:47.559
<v Speaker 1>Okay, where are they?

305
00:14:47.639 --> 00:14:50.679
<v Speaker 2>There are about eight phases in that model. Reconnaissance first,

306
00:14:51.000 --> 00:14:56.960
<v Speaker 2>then initial exploitation, establish foothold, escalate, privileges internal reconnaissance, move

307
00:14:57.039 --> 00:15:01.039
<v Speaker 2>laterally inside the network, maintain presence, and and finally complete

308
00:15:01.080 --> 00:15:02.279
<v Speaker 2>the mission whatever.

309
00:15:02.000 --> 00:15:05.840
<v Speaker 1>That might be. Recon exploit foothold, escalate, internal recon lateral movement,

310
00:15:05.960 --> 00:15:07.679
<v Speaker 1>maintain complete. Got it?

311
00:15:08.039 --> 00:15:11.840
<v Speaker 2>Understanding that flow helps you see where tools including bashcripts

312
00:15:11.919 --> 00:15:15.440
<v Speaker 2>might be used. It gives context to offensive actions. Bash

313
00:15:15.480 --> 00:15:17.960
<v Speaker 2>makes an attacker very agile within this cycle.

314
00:15:18.159 --> 00:15:21.200
<v Speaker 1>That framework definitely helps visualize it. Given how quick and

315
00:15:22.399 --> 00:15:24.840
<v Speaker 1>low profile Bash can be, where does it really shine

316
00:15:24.879 --> 00:15:27.639
<v Speaker 1>in this attack cycle? Let's start at the beginning. Reconnaissance.

317
00:15:27.720 --> 00:15:30.759
<v Speaker 2>Reconnaissance is all about gathering intel in the target. Bash

318
00:15:30.840 --> 00:15:33.200
<v Speaker 2>is great here. You can use kerl for example, to

319
00:15:33.240 --> 00:15:36.440
<v Speaker 2>download web pages, maybe follow redirects to l save the output.

320
00:15:36.919 --> 00:15:39.919
<v Speaker 2>Basically crawl website looking for information or vulnerabilities.

321
00:15:40.039 --> 00:15:40.919
<v Speaker 1>This is from the command line.

322
00:15:41.000 --> 00:15:44.720
<v Speaker 2>Yeah, and another classic technique is banner grabbing. Lots of

323
00:15:44.759 --> 00:15:49.559
<v Speaker 2>network services like web servers, HGTP file servers, FTP mail

324
00:15:49.639 --> 00:15:53.200
<v Speaker 2>servers SMTP. They announce themselves with a banner when you.

325
00:15:53.159 --> 00:15:55.360
<v Speaker 1>Connect, like a welcome message kind of.

326
00:15:55.799 --> 00:15:58.840
<v Speaker 2>And that banner often reveals the software name and version,

327
00:15:59.159 --> 00:16:02.720
<v Speaker 2>maybe even the operating system gold dust for an attacker

328
00:16:02.759 --> 00:16:04.159
<v Speaker 2>looking for known exploits.

329
00:16:04.320 --> 00:16:07.120
<v Speaker 1>And you can automate grabbing these banners with Bash absolutely.

330
00:16:07.159 --> 00:16:10.559
<v Speaker 2>But here's where Bash gets really sneaky and powerful, something

331
00:16:10.600 --> 00:16:13.799
<v Speaker 2>that surprises people. You don't always need a dedicated tool

332
00:16:13.879 --> 00:16:16.080
<v Speaker 2>like telnet or nmap to connect to a port and

333
00:16:16.120 --> 00:16:19.759
<v Speaker 2>see that banner. No, Bash itself has this built in capability.

334
00:16:20.039 --> 00:16:23.679
<v Speaker 2>Using a special filepath deftcfos nameport.

335
00:16:23.320 --> 00:16:26.320
<v Speaker 1>Wait, Bash can make TCP connections directly effectively.

336
00:16:26.360 --> 00:16:28.440
<v Speaker 2>Yes, it's a fetcher of the show. So an attacker

337
00:16:28.480 --> 00:16:31.200
<v Speaker 2>on a system where maybe tools like telnet are removed

338
00:16:31.279 --> 00:16:34.519
<v Speaker 2>or blocked, they can still perform network reconnaissance using just

339
00:16:34.600 --> 00:16:38.120
<v Speaker 2>built in Bash commands. The book shows an SMTP connect

340
00:16:38.120 --> 00:16:42.039
<v Speaker 2>dotsh script that uses exec three DVTCP one twenty five

341
00:16:42.120 --> 00:16:44.639
<v Speaker 2>dollars to open a connection to an SMTP server on

342
00:16:44.720 --> 00:16:48.039
<v Speaker 2>port twenty five and read its banner. No external tools needed.

343
00:16:48.159 --> 00:16:51.240
<v Speaker 1>WHOA Okay, that is sneaky, minimal.

344
00:16:50.840 --> 00:16:54.159
<v Speaker 2>Footprint exactly, pure command line resourcefulness.

345
00:16:54.360 --> 00:16:59.519
<v Speaker 1>Okay. So after recun the model had like establishing a foothold,

346
00:16:59.639 --> 00:17:01.039
<v Speaker 1>getting persistence.

347
00:17:00.639 --> 00:17:02.799
<v Speaker 2>Right right Once you're in, you want a way to

348
00:17:02.799 --> 00:17:06.799
<v Speaker 2>stay in or get back in easily. NC or netcat

349
00:17:06.839 --> 00:17:09.400
<v Speaker 2>is often called the Swiss Army knife for networking. You

350
00:17:09.440 --> 00:17:13.160
<v Speaker 2>can use it to create simple listeners, nclap port or

351
00:17:13.400 --> 00:17:15.240
<v Speaker 2>make outbound connections.

352
00:17:14.680 --> 00:17:16.319
<v Speaker 1>For simple data transfer or shells.

353
00:17:16.519 --> 00:17:19.279
<v Speaker 2>Yes, and one very common technique for footholds is a

354
00:17:19.319 --> 00:17:21.359
<v Speaker 2>reverse shell, especially using.

355
00:17:21.240 --> 00:17:23.880
<v Speaker 1>SSH versus SSH. How does that work?

356
00:17:24.160 --> 00:17:27.319
<v Speaker 2>Instead of the attacker connecting into the target, which might

357
00:17:27.319 --> 00:17:30.079
<v Speaker 2>be blocked by a firewall, the compromised target machine initiates

358
00:17:30.119 --> 00:17:33.079
<v Speaker 2>an outbound SSH connection to the attacker's machine using the

359
00:17:33.160 --> 00:17:36.000
<v Speaker 2>natch R option SSR one two three four five dot

360
00:17:36.000 --> 00:17:38.759
<v Speaker 2>local host part two to two attacker at attacker. This

361
00:17:38.799 --> 00:17:41.200
<v Speaker 2>punches a hole out through the firewall. The attacker then

362
00:17:41.200 --> 00:17:43.200
<v Speaker 2>connects to port one two three four five on their

363
00:17:43.200 --> 00:17:45.759
<v Speaker 2>own machine, and SSH tunnels that connection back to the

364
00:17:45.799 --> 00:17:50.359
<v Speaker 2>SSH server on the compromise targetqwever bypasses inbound rules very common.

365
00:17:50.480 --> 00:17:53.759
<v Speaker 2>You can also create simpler, though less secure back doors

366
00:17:54.160 --> 00:17:58.319
<v Speaker 2>just with Bash redirection and that devtsap trick again, something

367
00:17:58.440 --> 00:18:00.839
<v Speaker 2>like exec binbash zero one one in two, two in

368
00:18:00.920 --> 00:18:04.279
<v Speaker 2>one combined with connecting input output to a network socket

369
00:18:04.599 --> 00:18:07.839
<v Speaker 2>instant remote shell Wow. Big warning though that kind of

370
00:18:07.880 --> 00:18:12.519
<v Speaker 2>simple Bash backdoor. It's usually plain text unencrypted. Anyone stuffing

371
00:18:12.519 --> 00:18:16.200
<v Speaker 2>the network can see everything risky, very so attackers might

372
00:18:16.240 --> 00:18:19.319
<v Speaker 2>develop more sophisticated custom tools, maybe like the local rat

373
00:18:19.359 --> 00:18:22.519
<v Speaker 2>dot show listener and remote rat dot ish client examples

374
00:18:22.839 --> 00:18:25.839
<v Speaker 2>which use Bash scripting to provide more robust command execution

375
00:18:25.960 --> 00:18:28.759
<v Speaker 2>and even file transfer capabilities over their backdoor channel.

376
00:18:28.880 --> 00:18:31.759
<v Speaker 1>Makes sense now. If attackers are using these tools, they

377
00:18:31.799 --> 00:18:34.759
<v Speaker 1>probably don't want defenders easily figuring them out if they

378
00:18:34.759 --> 00:18:37.240
<v Speaker 1>get caught. That brings us to script obfuscation.

379
00:18:37.559 --> 00:18:40.480
<v Speaker 2>Exactly, if your penetration testing script or your back door

380
00:18:40.519 --> 00:18:43.559
<v Speaker 2>gets found, you don't want the blue team immediately understanding

381
00:18:43.559 --> 00:18:46.720
<v Speaker 2>exactly how it works and what it did. Obfuscation makes

382
00:18:46.720 --> 00:18:47.880
<v Speaker 2>reverse engineering harder.

383
00:18:48.279 --> 00:18:50.359
<v Speaker 1>How do you obfuscate a Bash script?

384
00:18:50.599 --> 00:18:54.119
<v Speaker 2>Several ways? Syntax obfuscation is the simplest. Just make the

385
00:18:54.160 --> 00:18:56.519
<v Speaker 2>code hard to read. Put the whole script on one

386
00:18:56.599 --> 00:19:01.039
<v Speaker 2>giant line, separated by semicolons. Use really meaningless variable and

387
00:19:01.160 --> 00:19:03.799
<v Speaker 2>function names like afrioco.

388
00:19:03.559 --> 00:19:06.079
<v Speaker 1>Or funky one annoying to read. That's the point.

389
00:19:06.559 --> 00:19:09.599
<v Speaker 2>Then there's logic offuscation. This is where you add tons

390
00:19:09.640 --> 00:19:13.319
<v Speaker 2>of useless code, pointless variables, functions calling other functions that

391
00:19:13.359 --> 00:19:17.039
<v Speaker 2>do nothing important, complex loops that calculate something trivial. Makes

392
00:19:17.039 --> 00:19:19.599
<v Speaker 2>a simple script look incredibly.

393
00:19:19.000 --> 00:19:22.279
<v Speaker 1>Complicated, like hiding a needle in a bigger messier astac.

394
00:19:21.960 --> 00:19:25.519
<v Speaker 2>Pretty much, but the most effective method is usually encryption. Okay,

395
00:19:25.559 --> 00:19:28.400
<v Speaker 2>The basic idea is you have your real script plaintext.

396
00:19:28.599 --> 00:19:32.039
<v Speaker 2>You encrypt it using a key producing ciphertext. You can

397
00:19:32.160 --> 00:19:36.279
<v Speaker 2>use standard tools like ohensolars two thousand, CBC sll inrelscript

398
00:19:36.319 --> 00:19:40.039
<v Speaker 2>dot sa outencrypted dot dot dot a password. Then you

399
00:19:40.079 --> 00:19:43.279
<v Speaker 2>create a small rapper script. This wrapper contains the encrypted

400
00:19:43.359 --> 00:19:46.119
<v Speaker 2>data and the password or prompts for it. When run,

401
00:19:46.200 --> 00:19:49.240
<v Speaker 2>the rapper decrypts the real script into memory importantly, often

402
00:19:49.240 --> 00:19:52.000
<v Speaker 2>without writing the decrypted version to disc, and then executes

403
00:19:52.039 --> 00:19:54.079
<v Speaker 2>it using something like Bash open.

404
00:19:53.880 --> 00:19:58.200
<v Speaker 1>Soli executes from memory much harder to recover the original script,

405
00:19:58.319 --> 00:19:59.119
<v Speaker 1>much harder.

406
00:19:59.680 --> 00:20:01.960
<v Speaker 2>Bash, which can even be used to demonstrate simple xor

407
00:20:02.039 --> 00:20:05.880
<v Speaker 2>stream ciphers like the stream cipher dot sh example, using

408
00:20:05.920 --> 00:20:09.400
<v Speaker 2>the random variable and a seed for educational purposes, showing

409
00:20:09.440 --> 00:20:11.480
<v Speaker 2>the principles involved fascinating.

410
00:20:11.640 --> 00:20:16.480
<v Speaker 1>Okay, one more offensive technique fuzzing. What is that exactly?

411
00:20:16.839 --> 00:20:20.880
<v Speaker 2>Fuzzing is basically throwing junk at a program to see

412
00:20:20.880 --> 00:20:24.279
<v Speaker 2>if it breaks. It's an automated way to find vulnerabilities,

413
00:20:24.359 --> 00:20:26.440
<v Speaker 2>particularly thing like buffer overflows.

414
00:20:26.480 --> 00:20:29.400
<v Speaker 1>Buffer overflows where the program tries to stuff too much

415
00:20:29.480 --> 00:20:30.559
<v Speaker 1>data into a small.

416
00:20:30.279 --> 00:20:34.680
<v Speaker 2>Space exactly classic C programming vulnerability With functions like strikeat

417
00:20:34.839 --> 00:20:37.079
<v Speaker 2>they copy data from one place to another, but don't

418
00:20:37.119 --> 00:20:39.680
<v Speaker 2>always check if the destination has enough room. If you

419
00:20:39.759 --> 00:20:43.039
<v Speaker 2>send way too much data, it spills over overwriting adjacent memory,

420
00:20:43.160 --> 00:20:46.359
<v Speaker 2>potentially crashing the program, or worse, allowing an attacker to

421
00:20:46.400 --> 00:20:49.960
<v Speaker 2>inject malicious code. So a fuzzer, often just a simple script,

422
00:20:50.240 --> 00:20:54.599
<v Speaker 2>systematically sends slightly different, often invalid or overly long inputs

423
00:20:54.640 --> 00:20:57.559
<v Speaker 2>to the target program. The book has an example fuzzer

424
00:20:57.559 --> 00:21:01.200
<v Speaker 2>dot is sha targeting a vulnerable C program fuzzme dot ex.

425
00:21:02.279 --> 00:21:04.720
<v Speaker 2>The script just keeps sending longer and longer strings as

426
00:21:04.720 --> 00:21:08.440
<v Speaker 2>command line arguments until fuzz me dot ex crashes. That

427
00:21:08.519 --> 00:21:11.920
<v Speaker 2>crash point tells you roughly how much data causes the overflow.

428
00:21:12.119 --> 00:21:14.039
<v Speaker 1>Automated vulnerability discovery yep.

429
00:21:14.240 --> 00:21:16.920
<v Speaker 2>Bash is great for scripting that kind of repetitive testing.

430
00:21:17.400 --> 00:21:20.920
<v Speaker 1>So we've seen Bash used for defense and offense. How

431
00:21:20.960 --> 00:21:22.440
<v Speaker 1>do these two sides connect?

432
00:21:22.839 --> 00:21:24.799
<v Speaker 2>Well? If we connect, this all back to the bigger picture.

433
00:21:25.279 --> 00:21:28.640
<v Speaker 2>Understanding these attack methods is directly useful for defense. Knowing

434
00:21:28.680 --> 00:21:31.680
<v Speaker 2>your enemy precisely. If you know how an attacker might

435
00:21:31.799 --> 00:21:34.920
<v Speaker 2>use DEVTCP for banner grabbing or set up a reverse

436
00:21:35.039 --> 00:21:37.759
<v Speaker 2>SSH tunnel, you know what kind of network traffic or

437
00:21:37.799 --> 00:21:40.359
<v Speaker 2>process behavior to look for on your systems, you can

438
00:21:40.359 --> 00:21:45.000
<v Speaker 2>figure firewalls better, maybe monitor for suspicious outbound connections. Knowing

439
00:21:45.039 --> 00:21:47.960
<v Speaker 2>how a Bash backdoor works helps you spot those weird

440
00:21:48.160 --> 00:21:52.240
<v Speaker 2>Bash processes talking over the network. Understanding fuzzing helps you

441
00:21:52.279 --> 00:21:55.680
<v Speaker 2>appreciate why validating INP and properly in your own applications

442
00:21:55.759 --> 00:21:59.519
<v Speaker 2>is so critical. Defense and offense really inform each other.

443
00:22:00.079 --> 00:22:02.519
<v Speaker 2>Using Bash for offense gives you insight into how to

444
00:22:02.640 --> 00:22:05.359
<v Speaker 2>use Bash for defense and vice versa.

445
00:22:05.480 --> 00:22:07.559
<v Speaker 1>So what does this all really mean for you? The

446
00:22:07.599 --> 00:22:10.880
<v Speaker 1>listener trying to learn this stuff? This deep dive? I

447
00:22:10.920 --> 00:22:14.079
<v Speaker 1>think really Hammers home that Bash isn't just some utility

448
00:22:14.079 --> 00:22:17.799
<v Speaker 1>for moving files around, not at all. It's this incredibly powerful,

449
00:22:18.519 --> 00:22:22.160
<v Speaker 1>versatile language right at the heart of cybersecurity. Doesn't matter

450
00:22:22.200 --> 00:22:25.599
<v Speaker 1>if you're Red Team or Blue Team. It's a foundational

451
00:22:25.640 --> 00:22:28.200
<v Speaker 1>skill that just amplifies everything else.

452
00:22:27.960 --> 00:22:30.480
<v Speaker 2>You do, which raises the important question, how can you

453
00:22:30.559 --> 00:22:32.680
<v Speaker 2>actually practice these skills? Make them real?

454
00:22:32.839 --> 00:22:36.200
<v Speaker 1>Good question? Reading is one thing doing as another exactly, And.

455
00:22:36.160 --> 00:22:39.599
<v Speaker 2>The book actually has some really good practical workshop props

456
00:22:39.599 --> 00:22:41.920
<v Speaker 2>to get you hands on. They're great starting points.

457
00:22:41.960 --> 00:22:42.960
<v Speaker 1>Oh yeah, like what well?

458
00:22:43.000 --> 00:22:45.480
<v Speaker 2>For example, you could try modifying one of the data

459
00:22:45.480 --> 00:22:49.319
<v Speaker 2>collection scripts like get local dot shsh to automatically upload

460
00:22:49.359 --> 00:22:53.279
<v Speaker 2>its findings to a secure server using CPP automate your

461
00:22:53.279 --> 00:22:54.000
<v Speaker 2>evidence collection.

462
00:22:54.079 --> 00:22:54.759
<v Speaker 1>Okay, practical.

463
00:22:54.960 --> 00:22:57.319
<v Speaker 2>Or take the hash search dot s script, the one

464
00:22:57.319 --> 00:23:00.400
<v Speaker 2>that finds files by their hash. Modify it so it

465
00:23:00.480 --> 00:23:02.599
<v Speaker 2>stops searching as soon as it finds the first match.

466
00:23:02.680 --> 00:23:06.160
<v Speaker 2>Make it more efficient, or maybe simplify the output paths

467
00:23:06.200 --> 00:23:10.519
<v Speaker 2>it displays, tidying it up. Or for Windows, enhance the

468
00:23:10.559 --> 00:23:13.119
<v Speaker 2>windlogs dot sh sh script to show a progress bar

469
00:23:13.200 --> 00:23:16.359
<v Speaker 2>while it's working using tiput make it more user friendly.

470
00:23:16.599 --> 00:23:17.759
<v Speaker 1>Nice little touches.

471
00:23:17.720 --> 00:23:20.240
<v Speaker 2>On the offensive side. You could expand the fuzzer dot

472
00:23:20.319 --> 00:23:23.000
<v Speaker 2>sh syncrypt to fuzz more than one command line argument

473
00:23:23.079 --> 00:23:25.680
<v Speaker 2>at a time, make it a bit more thorough, or

474
00:23:25.759 --> 00:23:28.680
<v Speaker 2>modify the banner grabber dot sh script instead of just

475
00:23:28.720 --> 00:23:31.039
<v Speaker 2>one target, make it read a whole list of IPS

476
00:23:31.079 --> 00:23:33.880
<v Speaker 2>from a file and output the results neatly into an

477
00:23:34.000 --> 00:23:37.200
<v Speaker 2>htmel table for reporting. That sounds useful, and definitely try

478
00:23:37.279 --> 00:23:40.680
<v Speaker 2>encrypting a simple script yourself using open sale or even

479
00:23:40.720 --> 00:23:43.279
<v Speaker 2>the xor method and then write the rapper script to

480
00:23:43.319 --> 00:23:47.000
<v Speaker 2>decrypt and run. It really helps understand that obfuscation technique.

481
00:23:47.200 --> 00:23:49.440
<v Speaker 1>Get your hands dirty with encryption exactly.

482
00:23:49.920 --> 00:23:52.640
<v Speaker 2>This kind of exercises really bridge that gap from just

483
00:23:52.680 --> 00:23:54.359
<v Speaker 2>reading about it to actually doing it.

484
00:23:54.480 --> 00:23:58.599
<v Speaker 1>Absolutely so, mastering the command line using Bash like this.

485
00:23:59.000 --> 00:24:03.039
<v Speaker 1>It's not about throwing away your fancy graphical security tools, noah,

486
00:24:03.119 --> 00:24:06.640
<v Speaker 1>not at all. It's about augmenting them, adding this fundamental

487
00:24:06.720 --> 00:24:09.440
<v Speaker 1>layer of control and insight that maybe you didn't realize

488
00:24:09.480 --> 00:24:10.240
<v Speaker 1>you had access to.

489
00:24:10.480 --> 00:24:13.480
<v Speaker 2>Well said, I mean, the command line is your direct

490
00:24:13.480 --> 00:24:16.880
<v Speaker 2>pipe to the OS. Right. All that power refined over

491
00:24:16.920 --> 00:24:21.640
<v Speaker 2>decades in a world where we're increasingly using these slightly

492
00:24:21.680 --> 00:24:26.799
<v Speaker 2>opaque GUIs understanding and being able to wield this direct power.

493
00:24:27.000 --> 00:24:29.680
<v Speaker 2>That's not just another skill. It really is a critical

494
00:24:29.720 --> 00:24:33.759
<v Speaker 2>advantage whether you're protecting systems or probing them, Which maybe

495
00:24:33.839 --> 00:24:36.920
<v Speaker 2>leads to a final thought, what other lost arts, maybe

496
00:24:36.960 --> 00:24:39.839
<v Speaker 2>in computing or even your own field, holds similar kinds

497
00:24:39.839 --> 00:24:42.400
<v Speaker 2>of untapped power just waiting to be rediscovered.

498
00:24:43.880 --> 00:24:47.200
<v Speaker 1>That's a great question to chew on something powerful hidden

499
00:24:47.200 --> 00:24:49.720
<v Speaker 1>in plain sight. Well that's all the time we have

500
00:24:49.799 --> 00:24:52.680
<v Speaker 1>for this deep dialk into cybersecurity ops with Bash. We

501
00:24:52.720 --> 00:24:53.720
<v Speaker 1>hope you found it useful.

502
00:24:53.920 --> 00:24:55.640
<v Speaker 2>Yeah, hope it sparks some ideas.

503
00:24:56.160 --> 00:24:57.960
<v Speaker 1>Thanks for joining us, and we'll catch you on the

504
00:24:57.960 --> 00:24:58.799
<v Speaker 1>next deep dive.