WEBVTT

1
00:00:00.080 --> 00:00:04.360
<v Speaker 1>Imagine you're standing at the edge of this huge, complex

2
00:00:04.440 --> 00:00:07.719
<v Speaker 1>digital landscape. Maybe you're a network admin, maybe just really

3
00:00:07.799 --> 00:00:10.759
<v Speaker 1>curious about how it all works underneath, right, and suddenly

4
00:00:10.800 --> 00:00:14.880
<v Speaker 1>you're just hit with this flood of info about network

5
00:00:14.880 --> 00:00:20.039
<v Speaker 1>security vulnerabilities, exploits, all these scanning tools. It's overwhelming. How

6
00:00:20.079 --> 00:00:22.160
<v Speaker 1>do you actually cut through that noise? How do you

7
00:00:22.160 --> 00:00:26.039
<v Speaker 1>get smart about what really matters without you drowning?

8
00:00:26.280 --> 00:00:28.000
<v Speaker 2>Well, that's exactly what we try to do here on

9
00:00:28.039 --> 00:00:31.160
<v Speaker 2>the deep Dive. We're aiming to be that shortcut for you.

10
00:00:31.359 --> 00:00:33.679
<v Speaker 2>We dig through a whole stack of sources on these

11
00:00:33.920 --> 00:00:38.359
<v Speaker 2>really complex topics and pull out the most important insights,

12
00:00:38.759 --> 00:00:43.719
<v Speaker 2>sort of turning that information overload into hopefully clear understanding.

13
00:00:44.079 --> 00:00:47.960
<v Speaker 1>And today we're diving into the Network Scanning Cookbook. This

14
00:00:48.000 --> 00:00:50.479
<v Speaker 1>isn't just theory, right, it's a really practical look at

15
00:00:50.479 --> 00:00:54.520
<v Speaker 1>how two absolute powerhouse tools en MAP and NESSUS are

16
00:00:54.600 --> 00:00:58.000
<v Speaker 1>used to genuinely understand network security exactly.

17
00:00:58.079 --> 00:01:00.280
<v Speaker 2>We'll get to the essentials. What are these tools, why

18
00:01:00.320 --> 00:01:03.799
<v Speaker 2>are they so crucial for dealing with today's digital threats,

19
00:01:04.200 --> 00:01:07.319
<v Speaker 2>and how they can uncover some surprising weaknesses even in

20
00:01:07.359 --> 00:01:11.079
<v Speaker 2>places you might not expect, like say, industrial control systems.

21
00:01:11.159 --> 00:01:14.280
<v Speaker 1>Okay, so by the end of this deep dive, the

22
00:01:14.359 --> 00:01:17.159
<v Speaker 1>idea is you'll not only get the core concepts, but

23
00:01:17.239 --> 00:01:20.920
<v Speaker 1>you'll have those aha moments. You'll be able to really

24
00:01:20.959 --> 00:01:24.120
<v Speaker 1>evaluate network security stuff critically.

25
00:01:25.200 --> 00:01:27.840
<v Speaker 2>Let's get started right, Well, like any good cookbook, you

26
00:01:27.879 --> 00:01:31.560
<v Speaker 2>start with the basics and a network security that's defining

27
00:01:31.560 --> 00:01:35.760
<v Speaker 2>a vulnerability. Fundamentally, it's just a weakness, a flaw in

28
00:01:35.799 --> 00:01:39.439
<v Speaker 2>a system or a device that an attacker could potentially exploit.

29
00:01:39.519 --> 00:01:41.280
<v Speaker 2>Think of it like a door left unlocked, maybe a

30
00:01:41.280 --> 00:01:42.439
<v Speaker 2>window latch that's broken.

31
00:01:42.599 --> 00:01:47.560
<v Speaker 1>Got it, simple weakness. So network vulnerability scanning, that's basically

32
00:01:47.599 --> 00:01:50.120
<v Speaker 1>the process of actively hunting for those weak spots across

33
00:01:50.120 --> 00:01:50.959
<v Speaker 1>your whole network.

34
00:01:51.040 --> 00:01:55.200
<v Speaker 2>That's it, clients, servers, routers, switches, everything connected.

35
00:01:54.840 --> 00:01:58.840
<v Speaker 1>And with new critical vulnerabilities popping up seeming well daily,

36
00:02:00.000 --> 00:02:02.400
<v Speaker 1>what's this so urgent for organizations? Why make it a

37
00:02:02.439 --> 00:02:03.120
<v Speaker 1>real time thing?

38
00:02:03.480 --> 00:02:07.359
<v Speaker 2>It's really about staying ahead of the curve. Organizations absolutely

39
00:02:07.400 --> 00:02:12.039
<v Speaker 2>need procedures in place, real time procedures to find, analyze,

40
00:02:12.080 --> 00:02:14.479
<v Speaker 2>and fix these issues before attackers find them.

41
00:02:14.639 --> 00:02:16.400
<v Speaker 1>Right prevention exactly.

42
00:02:16.599 --> 00:02:21.199
<v Speaker 2>It prevents potentially huge financial losses, protects their reputation, keeps

43
00:02:21.240 --> 00:02:26.960
<v Speaker 2>systems updated, and crucially, you can't fix everything instantly, so

44
00:02:27.000 --> 00:02:31.240
<v Speaker 2>it's also about smartly prioritizing which risks are the biggest threats.

45
00:02:31.479 --> 00:02:33.919
<v Speaker 1>That's the classic problem, isn't it. You hear stories all

46
00:02:33.919 --> 00:02:37.199
<v Speaker 1>the time where some major flaw goes unfixed for ages

47
00:02:37.240 --> 00:02:39.000
<v Speaker 1>just because they didn't prioritize it correctly.

48
00:02:39.080 --> 00:02:40.039
<v Speaker 2>It happens way too often.

49
00:02:40.080 --> 00:02:42.439
<v Speaker 1>Now. The sources talk about two main kinds of scans.

50
00:02:42.520 --> 00:02:43.639
<v Speaker 1>Can you break those down?

51
00:02:43.759 --> 00:02:47.360
<v Speaker 2>Sure? So? First you have internal scans. These simulate what

52
00:02:47.400 --> 00:02:50.840
<v Speaker 2>an insider could see, usually targeting private IP addresses inside

53
00:02:50.879 --> 00:02:54.479
<v Speaker 2>the company network. Then you have external scans. These mimic

54
00:02:54.479 --> 00:02:57.240
<v Speaker 2>an attacker coming from the Internet hitting your public facing

55
00:02:57.280 --> 00:02:58.159
<v Speaker 2>IP addresses.

56
00:02:58.199 --> 00:03:00.199
<v Speaker 1>Ah so inside and outside views.

57
00:03:00.159 --> 00:03:04.159
<v Speaker 2>Precisely, and you absolutely need both for a complete security picture.

58
00:03:04.280 --> 00:03:06.919
<v Speaker 2>It's like checking your house locks from the inside and

59
00:03:06.960 --> 00:03:08.719
<v Speaker 2>walking around the outside to check the windows.

60
00:03:08.840 --> 00:03:12.039
<v Speaker 1>Makes sense, and the scanning itself, it follows a pretty

61
00:03:12.080 --> 00:03:15.080
<v Speaker 1>logical flow, right, like a three step recipe exactly.

62
00:03:15.400 --> 00:03:18.719
<v Speaker 2>The first phase is discovery sometimes called host discovery. Okay,

63
00:03:18.759 --> 00:03:20.360
<v Speaker 2>you got to find out what's actually live on the

64
00:03:20.400 --> 00:03:23.360
<v Speaker 2>network first, no point scanning things that aren't even turned

65
00:03:23.360 --> 00:03:24.080
<v Speaker 2>on or don't.

66
00:03:23.919 --> 00:03:26.400
<v Speaker 1>Exist, right, avoid wasted effort exactly.

67
00:03:27.199 --> 00:03:29.840
<v Speaker 2>Tools like end map and nessus are great for this.

68
00:03:30.520 --> 00:03:34.520
<v Speaker 2>N MAP even has its script engine, the NSC, for

69
00:03:34.719 --> 00:03:36.120
<v Speaker 2>really customized discovery.

70
00:03:36.599 --> 00:03:39.639
<v Speaker 1>Okay, so step one find the live devices. What's next?

71
00:03:39.800 --> 00:03:42.759
<v Speaker 2>Step two is port scanning. Once you know what's live,

72
00:03:42.800 --> 00:03:45.000
<v Speaker 2>you need to check which doors, which ports are open

73
00:03:45.080 --> 00:03:48.000
<v Speaker 2>on those devices, and it works differently depending on the

74
00:03:48.000 --> 00:03:51.280
<v Speaker 2>protocol like TCP versus UDP. En map is really the

75
00:03:51.319 --> 00:03:52.759
<v Speaker 2>master tool for figuring all that.

76
00:03:52.719 --> 00:03:55.280
<v Speaker 1>Out, checking the doors and windows on the live houses.

77
00:03:55.560 --> 00:03:55.919
<v Speaker 1>Got it?

78
00:03:56.400 --> 00:03:59.599
<v Speaker 2>And the final step, the final, really crucial phase, is

79
00:03:59.680 --> 00:04:04.439
<v Speaker 2>vulnerability scanning. This is where automated tools, especially nessa's, really

80
00:04:04.479 --> 00:04:06.719
<v Speaker 2>come into their own how so well, They go beyond

81
00:04:06.800 --> 00:04:09.280
<v Speaker 2>just seeing if a port is open. They actually try

82
00:04:09.280 --> 00:04:12.039
<v Speaker 2>to look through that open port to find known issues,

83
00:04:12.520 --> 00:04:16.720
<v Speaker 2>things like outdated software, vulnerable protocols, maybe even default admin

84
00:04:16.759 --> 00:04:18.160
<v Speaker 2>passwords left unchanged.

85
00:04:18.319 --> 00:04:19.199
<v Speaker 1>Ah.

86
00:04:19.439 --> 00:04:23.240
<v Speaker 2>Imagine trying to manually check for thousands of known vulnerabilities

87
00:04:23.279 --> 00:04:27.120
<v Speaker 2>across one hundred, maybe thousands of devices almost impossible.

88
00:04:27.199 --> 00:04:31.199
<v Speaker 1>Yeah, you'd never finish. So Okay, the scan runs what

89
00:04:31.319 --> 00:04:34.279
<v Speaker 1>kind of valuable stuff? What are those gold nuggets? It

90
00:04:34.319 --> 00:04:36.439
<v Speaker 1>actually finds what are the key takeaways?

91
00:04:36.439 --> 00:04:39.079
<v Speaker 2>Oh? It's like finding a treasure map to your network's weaknesses.

92
00:04:39.600 --> 00:04:43.600
<v Speaker 2>It reveals things like unwanted open port stores that shouldn't

93
00:04:43.600 --> 00:04:44.199
<v Speaker 2>be opened at all.

94
00:04:44.319 --> 00:04:44.560
<v Speaker 1>Okay.

95
00:04:44.920 --> 00:04:49.319
<v Speaker 2>It can find default user accounts basically engraved invitations for attackers,

96
00:04:49.680 --> 00:04:55.879
<v Speaker 2>missing security patches, massive holes, vulnerable software protocols. Sometimes it

97
00:04:56.000 --> 00:04:59.319
<v Speaker 2>even gives you direct information on how to exploit a vulnerability.

98
00:04:59.399 --> 00:05:01.519
<v Speaker 2>It's an instant in blueprint of you'rre hidden risks.

99
00:05:01.800 --> 00:05:08.519
<v Speaker 1>But real world networks they're messy, aren't they? Firewalls, weird configurations.

100
00:05:09.439 --> 00:05:12.639
<v Speaker 1>The sources mentioned This complexity can lead to false positives.

101
00:05:13.079 --> 00:05:14.120
<v Speaker 1>What is that exactly?

102
00:05:14.279 --> 00:05:17.519
<v Speaker 2>Yeah, that's a really important point. A false positive is

103
00:05:17.519 --> 00:05:21.279
<v Speaker 2>when the scanner reports of vulnerability or maybe says a

104
00:05:21.319 --> 00:05:25.079
<v Speaker 2>host is live, but it's actually wrong. For example, a

105
00:05:25.120 --> 00:05:28.199
<v Speaker 2>firewall might just block the scanner's ping, making a machine

106
00:05:28.240 --> 00:05:31.439
<v Speaker 2>look offline when it's perfectly fine. Understanding these is key

107
00:05:31.480 --> 00:05:35.360
<v Speaker 2>because chasing down non existent problems waste a ton of time.

108
00:05:35.519 --> 00:05:38.160
<v Speaker 1>Right, you focus your effort on the real issues. So,

109
00:05:38.279 --> 00:05:40.800
<v Speaker 1>like any good recipe, you need good prep for the scan.

110
00:05:41.319 --> 00:05:43.319
<v Speaker 1>What are the key things to get right beforehand?

111
00:05:43.480 --> 00:05:46.600
<v Speaker 2>Three main things? Really. First, you absolutely have to define

112
00:05:46.600 --> 00:05:49.439
<v Speaker 2>the scan scope know exactly what you are and aren't scanning,

113
00:05:49.480 --> 00:05:51.480
<v Speaker 2>and why don't just point it everywhere?

114
00:05:51.519 --> 00:05:51.839
<v Speaker 1>Okay?

115
00:05:52.000 --> 00:05:52.360
<v Speaker 2>Scope?

116
00:05:52.560 --> 00:05:56.079
<v Speaker 1>Second, understand the network architecture. Got a web application firewall?

117
00:05:56.120 --> 00:05:57.600
<v Speaker 1>You need to know how that affects.

118
00:05:57.360 --> 00:06:00.639
<v Speaker 2>The scan right, know the landscape. And third, make sure

119
00:06:00.680 --> 00:06:04.319
<v Speaker 2>the scanner has proper network access. Sometimes you need to

120
00:06:04.360 --> 00:06:07.560
<v Speaker 2>whitelist its IP address so firewalls don't block its scans.

121
00:06:08.120 --> 00:06:09.319
<v Speaker 2>You need to clear the path for it.

122
00:06:09.319 --> 00:06:14.560
<v Speaker 1>Okay, scope, architecture access, got it. But finding the vulnerabilities

123
00:06:14.800 --> 00:06:17.079
<v Speaker 1>that's just step one. Right. Once you have this list

124
00:06:17.079 --> 00:06:20.160
<v Speaker 1>of problems, what's next? How do you actually improve security?

125
00:06:20.240 --> 00:06:22.519
<v Speaker 2>That's why the response and mitigation plan kicks in. It's

126
00:06:22.560 --> 00:06:26.000
<v Speaker 2>all about fixing what you found, closing those unwanted ports,

127
00:06:26.360 --> 00:06:30.079
<v Speaker 2>enforcing strong passwords, unique ones, applying the patches you miss,

128
00:06:30.199 --> 00:06:34.279
<v Speaker 2>maybe disabling old, risky protocols, and crucially remembering network security

129
00:06:34.319 --> 00:06:39.519
<v Speaker 2>isn't a one off task. It's a continuous cycle. Assess, analyze, mitigate,

130
00:06:39.759 --> 00:06:41.639
<v Speaker 2>then repeat. You're never really.

131
00:06:41.439 --> 00:06:45.079
<v Speaker 1>Done right, always iterating. Okay, let's get into the tools themselves.

132
00:06:45.160 --> 00:06:47.920
<v Speaker 1>First up in the cookbook NESSUS.

133
00:06:47.439 --> 00:06:52.360
<v Speaker 2>RIGHTSUS, it's a very comprehensive commercial grade vulnerability scanner. Its

134
00:06:52.399 --> 00:06:55.519
<v Speaker 2>real strength comes from its constantly updated plug in billion. Yeah,

135
00:06:55.519 --> 00:06:58.680
<v Speaker 2>they're basically little detection scripts. They're written in a language

136
00:06:58.720 --> 00:07:04.279
<v Speaker 2>called NASL Nessus Attacks Scripting Language. These plugins let nessus

137
00:07:04.319 --> 00:07:08.120
<v Speaker 2>find new vulnerabilities incredibly quickly, often as soon as they

138
00:07:08.120 --> 00:07:08.759
<v Speaker 2>become public.

139
00:07:08.839 --> 00:07:09.160
<v Speaker 1>Wow.

140
00:07:09.360 --> 00:07:12.959
<v Speaker 2>Plus, it has a nice user friendly web interfhase a GUI,

141
00:07:13.319 --> 00:07:16.680
<v Speaker 2>which makes setting up and running scans, even complex ones,

142
00:07:16.839 --> 00:07:17.759
<v Speaker 2>pretty straightforward.

143
00:07:18.199 --> 00:07:22.600
<v Speaker 1>So it sounds powerful, but how do security teams actually

144
00:07:22.720 --> 00:07:25.160
<v Speaker 1>use it day to day? What are the practical features

145
00:07:25.199 --> 00:07:26.120
<v Speaker 1>that make it efficient?

146
00:07:26.560 --> 00:07:31.480
<v Speaker 2>Missus has several really useful operational features. For example, policies.

147
00:07:31.879 --> 00:07:34.079
<v Speaker 2>A policy is like a template, a collection of settings

148
00:07:34.079 --> 00:07:37.040
<v Speaker 2>and scan types you've configured. Ok, you create a policy once,

149
00:07:37.279 --> 00:07:40.240
<v Speaker 2>say for scanning Windows servers, and then you can reuse

150
00:07:40.279 --> 00:07:42.920
<v Speaker 2>it for dozens or hundreds of scans. There's a huge

151
00:07:42.959 --> 00:07:44.600
<v Speaker 2>amount of time I can see that. Then there are

152
00:07:44.639 --> 00:07:48.000
<v Speaker 2>plugin rules. These let you customize the results. You can

153
00:07:48.000 --> 00:07:50.519
<v Speaker 2>tell nessus to hide a specific finding or maybe change

154
00:07:50.519 --> 00:07:53.319
<v Speaker 2>its risk level if you have a compensating control in place.

155
00:07:53.839 --> 00:07:57.519
<v Speaker 2>Super helpful for managing reports from large scans AH reducing

156
00:07:57.600 --> 00:08:01.680
<v Speaker 2>noise exactly, and for consultants internal reporting, you can generate

157
00:08:01.720 --> 00:08:05.439
<v Speaker 2>customized reports, even adding your company logo and tailoring the summaries.

158
00:08:05.800 --> 00:08:09.759
<v Speaker 1>And what about the basic nessis settings security configuration.

159
00:08:10.040 --> 00:08:12.360
<v Speaker 2>Yeah, it's built with that in mind. You can set

160
00:08:12.360 --> 00:08:15.639
<v Speaker 2>a master password to enquip sensitive things like stored credentials.

161
00:08:16.040 --> 00:08:18.319
<v Speaker 2>You can gifigure proxy servers if NESSAS needs to go

162
00:08:18.319 --> 00:08:21.639
<v Speaker 2>through under reach the internet or scan targets. Okay, you

163
00:08:21.680 --> 00:08:24.560
<v Speaker 2>can set up SMTP so it automatically emails you when

164
00:08:24.560 --> 00:08:27.800
<v Speaker 2>scans are done, and there's robust password management to secure

165
00:08:27.839 --> 00:08:30.000
<v Speaker 2>the NESSUS console itself. It's pretty why I thought out.

166
00:08:30.319 --> 00:08:33.039
<v Speaker 1>Okay, NESSUS covered, Let's switch to the other big name,

167
00:08:33.440 --> 00:08:37.440
<v Speaker 1>end map. What makes nmap the Swiss army knife. Everyone

168
00:08:37.480 --> 00:08:37.879
<v Speaker 1>calls it.

169
00:08:38.159 --> 00:08:42.919
<v Speaker 2>Endmap is well tree, It's open source, and it's incredibly versatile.

170
00:08:43.000 --> 00:08:45.799
<v Speaker 2>It's primarily a command line tool. Its main job is

171
00:08:45.840 --> 00:08:48.039
<v Speaker 2>to help you map out a network, figure out what

172
00:08:48.080 --> 00:08:50.440
<v Speaker 2>hosts are up, what ports are open on those hosts,

173
00:08:50.679 --> 00:08:52.759
<v Speaker 2>and what services are running. It gives you a detailed

174
00:08:52.759 --> 00:08:54.559
<v Speaker 2>picture of your network's posture and.

175
00:08:54.559 --> 00:08:56.679
<v Speaker 1>Vers It all seems like an understatement. The options look

176
00:08:56.720 --> 00:08:59.279
<v Speaker 1>almost endless. You can be really precise or sneaky.

177
00:08:59.480 --> 00:09:01.799
<v Speaker 2>That's a good way to put it. Take host discovery.

178
00:09:02.879 --> 00:09:05.240
<v Speaker 2>N MAP can find live systems even if they block

179
00:09:05.279 --> 00:09:09.919
<v Speaker 2>standard pings. It uses cleverer probes like syn pings, devil

180
00:09:10.000 --> 00:09:13.759
<v Speaker 2>M pants or azkpings civil p that often slip past

181
00:09:13.799 --> 00:09:16.720
<v Speaker 2>firewalls that just look for normal ICMP.

182
00:09:16.480 --> 00:09:19.960
<v Speaker 1>Pings sneaky indeed, and the scanning.

183
00:09:19.519 --> 00:09:22.759
<v Speaker 2>Itself huge variety and scan techniques. You can choose based

184
00:09:22.799 --> 00:09:28.240
<v Speaker 2>on speed and stealth. There's the tcpsyn scan SSS. They

185
00:09:28.240 --> 00:09:30.279
<v Speaker 2>have open scan, which is fast and quiet because it

186
00:09:30.279 --> 00:09:33.519
<v Speaker 2>doesn't complete the connection, or the full TCP connect scan

187
00:09:33.759 --> 00:09:37.000
<v Speaker 2>dash ST which is more reliable but noisier, and it

188
00:09:37.039 --> 00:09:40.480
<v Speaker 2>handles other protocols too, like UDP scans dashes you which

189
00:09:40.480 --> 00:09:42.759
<v Speaker 2>are important because attackers use UDP too, and you.

190
00:09:42.759 --> 00:09:45.039
<v Speaker 1>Can tell it exactly which ports to check.

191
00:09:45.000 --> 00:09:48.840
<v Speaker 2>Absolutely for ports specification by default, and map scans the

192
00:09:48.879 --> 00:09:51.360
<v Speaker 2>top one thousand most common ports, which is usually a

193
00:09:51.360 --> 00:09:53.279
<v Speaker 2>good start, but you can tell it to scan a

194
00:09:53.320 --> 00:09:56.279
<v Speaker 2>specific range like dash EP one sixty five five three

195
00:09:56.320 --> 00:09:59.000
<v Speaker 2>five for every single port, although that takes time, or

196
00:09:59.039 --> 00:10:01.519
<v Speaker 2>you can do a fast scan dashes F for just

197
00:10:01.559 --> 00:10:02.639
<v Speaker 2>the top one hundred ports.

198
00:10:02.759 --> 00:10:05.639
<v Speaker 1>Super flexible and it doesn't just find open ports, does it. It

199
00:10:05.679 --> 00:10:08.879
<v Speaker 1>tells you what's running. It's exactly its service and OS

200
00:10:08.960 --> 00:10:12.440
<v Speaker 1>detection is fantastic. Use the NSSV flag and n MAP

201
00:10:12.519 --> 00:10:15.399
<v Speaker 1>will try to determine the exact application and version running

202
00:10:15.440 --> 00:10:18.720
<v Speaker 1>on a port. Use NSO and it'll try to guess

203
00:10:18.720 --> 00:10:21.799
<v Speaker 1>the operating system of the target machine. Really valuable intel.

204
00:10:21.879 --> 00:10:24.440
<v Speaker 2>Okay, but here's where NMP gets really interesting. According to

205
00:10:24.480 --> 00:10:29.000
<v Speaker 2>the sources, evasion and spoofing sounds like spycraft.

206
00:10:28.799 --> 00:10:31.120
<v Speaker 1>It kind of is. This is where a skilled end

207
00:10:31.159 --> 00:10:34.799
<v Speaker 1>MAP user can try to bypass network defenses like firewalls

208
00:10:34.919 --> 00:10:41.120
<v Speaker 1>or intrusion detection systems. Techniques like packet fragmentation. This breaks

209
00:10:41.200 --> 00:10:44.759
<v Speaker 1>the probe packets into tiny pieces. Some older firewalls struggle

210
00:10:44.799 --> 00:10:46.759
<v Speaker 1>to reassemble and inspect these fragments properly.

211
00:10:46.919 --> 00:10:47.240
<v Speaker 2>Clever.

212
00:10:47.639 --> 00:10:50.679
<v Speaker 1>Or you can use decoy addresses digit D. This makes

213
00:10:50.679 --> 00:10:53.879
<v Speaker 1>the scan look like it's coming from multiple IP addresses, simultaneously,

214
00:10:54.200 --> 00:10:56.799
<v Speaker 1>helping to hide your real source IP among the noise.

215
00:10:57.519 --> 00:11:00.799
<v Speaker 1>You can even spoof your MSc address spoof if the

216
00:11:00.799 --> 00:11:03.840
<v Speaker 1>network has controls based on physical addresses. It's all about

217
00:11:03.879 --> 00:11:07.919
<v Speaker 1>being stealthy and making reconnaissance harder to detect or block. So, okay,

218
00:11:08.159 --> 00:11:11.320
<v Speaker 1>you run these incredibly detailed scans. You get a ton

219
00:11:11.399 --> 00:11:15.519
<v Speaker 1>of information back. How does NMAP present this? What do

220
00:11:15.559 --> 00:11:16.519
<v Speaker 1>the outputs look like?

221
00:11:16.919 --> 00:11:19.440
<v Speaker 2>And map gives you options. It can just print the

222
00:11:19.440 --> 00:11:21.799
<v Speaker 2>results straight to your terminal screen, which is fine for

223
00:11:21.879 --> 00:11:25.240
<v Speaker 2>quick scans, yeah, but for saving and analyzing. It has

224
00:11:25.279 --> 00:11:29.200
<v Speaker 2>several formats. Normal text dash on en is just a

225
00:11:29.240 --> 00:11:33.279
<v Speaker 2>readable text file xml ox is great because other security

226
00:11:33.279 --> 00:11:35.240
<v Speaker 2>tools can easily parse and import.

227
00:11:34.919 --> 00:11:36.559
<v Speaker 1>It right for automation exactly.

228
00:11:37.000 --> 00:11:40.759
<v Speaker 2>There's also greepable format dash og, which is designed to

229
00:11:40.799 --> 00:11:44.399
<v Speaker 2>be easily searched with command line tools like GP very

230
00:11:44.399 --> 00:11:48.519
<v Speaker 2>handy for scripting or quickly finding specific results in large outputs.

231
00:11:48.840 --> 00:11:51.519
<v Speaker 2>And if you want all three, just USEA and it

232
00:11:51.600 --> 00:11:52.960
<v Speaker 2>says in all formats at once.

233
00:11:53.159 --> 00:11:56.120
<v Speaker 1>Convenient and Nessa's, being more of an enterprise tool, probably

234
00:11:56.159 --> 00:11:58.000
<v Speaker 1>has more formal reporting it does.

235
00:11:58.200 --> 00:12:01.559
<v Speaker 2>Nessa's supports are generally more power and aimed at different audiences.

236
00:12:01.600 --> 00:12:04.440
<v Speaker 2>You can export in its own NES's format, which is

237
00:12:04.519 --> 00:12:08.159
<v Speaker 2>useful for sharing results between different nessas installations. The HTML

238
00:12:08.200 --> 00:12:11.440
<v Speaker 2>reports are probably the most common output. They're self contained,

239
00:12:11.720 --> 00:12:16.360
<v Speaker 2>highly detailed, easy to navigate, and usually include an executive summarsection,

240
00:12:16.759 --> 00:12:20.360
<v Speaker 2>perfect for management who don't need the nitty gritty technical details.

241
00:12:21.000 --> 00:12:24.240
<v Speaker 2>And you can also export to CSV common separated values,

242
00:12:24.480 --> 00:12:27.519
<v Speaker 2>which is perfect for pulling the data into spreadsheets for

243
00:12:27.600 --> 00:12:30.120
<v Speaker 2>further analysis, trending, or customer reporting.

244
00:12:30.399 --> 00:12:32.879
<v Speaker 1>Okay, this feels like a really critical point, maybe the

245
00:12:32.919 --> 00:12:37.679
<v Speaker 1>biggest aha moment here confirming vulnerabilities. Why is it so

246
00:12:37.840 --> 00:12:41.960
<v Speaker 1>absolutely vital to manually double check what these powerful scanners

247
00:12:42.000 --> 00:12:42.320
<v Speaker 1>tell you?

248
00:12:42.559 --> 00:12:47.679
<v Speaker 2>Because bottom line scanners make mistakes, They can and do generate.

249
00:12:47.320 --> 00:12:49.320
<v Speaker 1>False positives, ghost vulnerabilities.

250
00:12:49.440 --> 00:12:52.960
<v Speaker 2>Exactly, You simply cannot afford to waste time and resources

251
00:12:53.200 --> 00:12:57.000
<v Speaker 2>fixing problems that don't actually exist. Manually confirming findings is

252
00:12:57.039 --> 00:13:00.279
<v Speaker 2>about smart resource allocation. It ensures your team is focused

253
00:13:00.320 --> 00:13:03.600
<v Speaker 2>on fixing real, exploitable threats. It's the crucial step that

254
00:13:03.639 --> 00:13:06.440
<v Speaker 2>separates automated noise from actionable intelligence.

255
00:13:06.559 --> 00:13:08.679
<v Speaker 1>Let's make this concrete. The sources had some great real

256
00:13:08.679 --> 00:13:12.480
<v Speaker 1>world examples. First, a critical risk NESSUS reports a bind

257
00:13:12.519 --> 00:13:13.399
<v Speaker 1>shell back door.

258
00:13:13.720 --> 00:13:16.639
<v Speaker 2>Right, so NESSUS flags a specific port, say port one

259
00:13:16.679 --> 00:13:19.480
<v Speaker 2>teen twenty four on a machine, reporting it allows roots

260
00:13:19.480 --> 00:13:21.679
<v Speaker 2>shell access with no password needed.

261
00:13:22.240 --> 00:13:24.559
<v Speaker 1>That sounds really bad, extremely bad.

262
00:13:24.679 --> 00:13:26.279
<v Speaker 2>So how do you confirm? You could use a simple

263
00:13:26.320 --> 00:13:28.200
<v Speaker 2>tool like tell net connect to the IP address one

264
00:13:28.240 --> 00:13:30.159
<v Speaker 2>h two point one six eight point one zero three

265
00:13:30.200 --> 00:13:32.639
<v Speaker 2>point one two nine on that port one teen twenty four.

266
00:13:32.679 --> 00:13:34.960
<v Speaker 2>If you get a prompt, type the command d if

267
00:13:34.960 --> 00:13:38.399
<v Speaker 2>it comes back showing wid zero zero zero root. Well,

268
00:13:38.440 --> 00:13:40.879
<v Speaker 2>you've just manually confirmed you have root access. It's real

269
00:13:41.200 --> 00:13:42.080
<v Speaker 2>critical priority.

270
00:13:42.200 --> 00:13:46.679
<v Speaker 1>Okay, confirmed critical. Next example, a high risk SSL version

271
00:13:46.720 --> 00:13:50.080
<v Speaker 1>two and three detected old insecure protocols.

272
00:13:50.159 --> 00:13:54.279
<v Speaker 2>Yeah. NESSUS often flags this because using old SSLTLS versions

273
00:13:54.320 --> 00:13:58.360
<v Speaker 2>is risky. So it reports say port twenty five typically

274
00:13:58.440 --> 00:14:00.799
<v Speaker 2>smtpmail is using these out data protocols.

275
00:14:00.879 --> 00:14:02.279
<v Speaker 1>Sounds plausible, it does.

276
00:14:02.120 --> 00:14:03.919
<v Speaker 2>But this is where you need to dig deeper. You

277
00:14:03.919 --> 00:14:07.240
<v Speaker 2>could use n maps script engine, maybe run the ressoblescript

278
00:14:07.360 --> 00:14:10.360
<v Speaker 2>or sln dom ciphers against that specific port.

279
00:14:10.159 --> 00:14:10.960
<v Speaker 1>And what might you find?

280
00:14:11.080 --> 00:14:13.559
<v Speaker 2>This specific case from the source running those end map

281
00:14:13.559 --> 00:14:16.960
<v Speaker 2>scripts showed no SSL negotiation at all. The port wasn't

282
00:14:17.039 --> 00:14:20.120
<v Speaker 2>using SSLv two or v three. He wasn't using SSL period.

283
00:14:20.200 --> 00:14:21.960
<v Speaker 2>It was likely just plain text communication.

284
00:14:22.159 --> 00:14:23.919
<v Speaker 1>Ah, So Nessa's was wrong.

285
00:14:24.120 --> 00:14:26.720
<v Speaker 2>Essentially, yes, it was a false positive. It might have

286
00:14:26.799 --> 00:14:30.639
<v Speaker 2>misinterpreted some banner or response. This completely changes the risk

287
00:14:30.720 --> 00:14:34.320
<v Speaker 2>picture and highlights why manual verification is non negotiable.

288
00:14:34.440 --> 00:14:37.919
<v Speaker 1>That's a fantastic example. Okay, one more medium risk Apache

289
00:14:38.000 --> 00:14:39.639
<v Speaker 1>Tomcat default files found.

290
00:14:39.879 --> 00:14:43.240
<v Speaker 2>This one's simpler. Nessa's points out that default documentation or

291
00:14:43.279 --> 00:14:46.679
<v Speaker 2>example files are accessible on a Tomcat web server, maybe

292
00:14:46.679 --> 00:14:49.440
<v Speaker 2>on port A one eighty. How to check easiest way

293
00:14:49.799 --> 00:14:52.039
<v Speaker 2>just open your web browser and go to the url

294
00:14:52.120 --> 00:14:54.799
<v Speaker 2>Nessus indicated something like http dot one nine to two

295
00:14:54.879 --> 00:14:57.480
<v Speaker 2>point one sixty eight point one zero three point one

296
00:14:57.480 --> 00:15:01.200
<v Speaker 2>two nine point eight one eight zero tomcat dot com html.

297
00:15:01.840 --> 00:15:05.240
<v Speaker 2>If the default Tomcat documentation page loads up without asking

298
00:15:05.240 --> 00:15:07.879
<v Speaker 2>for a password, then yes, the finding is concerned. A

299
00:15:07.879 --> 00:15:09.559
<v Speaker 2>medium risk needs cleaning up.

300
00:15:10.039 --> 00:15:12.759
<v Speaker 1>These examples really show it's not just about running the tool.

301
00:15:12.799 --> 00:15:15.320
<v Speaker 1>It's about the analyst using the tool's output as a

302
00:15:15.320 --> 00:15:18.320
<v Speaker 1>starting point, then applying critical thinking to confirm what's real

303
00:15:18.320 --> 00:15:18.840
<v Speaker 1>and what's not.

304
00:15:19.000 --> 00:15:21.720
<v Speaker 2>Couldn't agree more. The real power isn't just the scanner.

305
00:15:21.759 --> 00:15:24.600
<v Speaker 2>It's the combination of the scanner and an informed analyst.

306
00:15:24.919 --> 00:15:27.320
<v Speaker 2>And speaking of power, both tools offer great ways to

307
00:15:27.360 --> 00:15:30.200
<v Speaker 2>customize them even further, let's talk about an end map

308
00:15:30.279 --> 00:15:32.000
<v Speaker 2>script engine NSE. Right.

309
00:15:32.159 --> 00:15:35.759
<v Speaker 1>NSE you mentioned it for a discovery It lets users

310
00:15:35.799 --> 00:15:38.960
<v Speaker 1>write their own scripts in LUA. Right, what kind of

311
00:15:38.960 --> 00:15:39.840
<v Speaker 1>things can you do with that?

312
00:15:40.360 --> 00:15:44.799
<v Speaker 2>NSESE really extends endmap way beyond basic port scanning. You

313
00:15:44.799 --> 00:15:49.320
<v Speaker 2>can write scripts for almost anything network related, more sophisticated

314
00:15:49.320 --> 00:15:54.240
<v Speaker 2>host discovery, detecting very specific or unusual services, checking for

315
00:15:54.279 --> 00:15:57.559
<v Speaker 2>specific vulnerabilities that maybe aren't in the main databases yet,

316
00:15:57.799 --> 00:16:01.679
<v Speaker 2>even performing basic authentication checks, or in some cases safely

317
00:16:01.759 --> 00:16:06.000
<v Speaker 2>testing exploits. Wow. These scripts fall into categories like auth discovery,

318
00:16:06.320 --> 00:16:10.080
<v Speaker 2>VULN exploit, and writing a basic one isn't super complex.

319
00:16:10.360 --> 00:16:13.399
<v Speaker 2>They have a standard structure, a head part with info

320
00:16:13.440 --> 00:16:16.120
<v Speaker 2>about the script, a rule part saying when it should run,

321
00:16:16.159 --> 00:16:17.799
<v Speaker 2>and an action part saying what it should do.

322
00:16:18.039 --> 00:16:21.039
<v Speaker 1>So, like that Tomcat example, you could write a specific

323
00:16:21.159 --> 00:16:24.440
<v Speaker 1>ns script just to check for those default files exactly.

324
00:16:24.480 --> 00:16:27.360
<v Speaker 2>Instead of relying on a broad vulnerability scan, you could

325
00:16:27.399 --> 00:16:30.200
<v Speaker 2>have a targeted NSE script that does just that one

326
00:16:30.279 --> 00:16:34.240
<v Speaker 2>check very efficiently. It's incredibly powerful for tailoring and MAAP

327
00:16:34.279 --> 00:16:35.519
<v Speaker 2>to your specific needs.

328
00:16:35.519 --> 00:16:39.039
<v Speaker 1>And Nessa says customization too, especially around compliance and auditing.

329
00:16:39.279 --> 00:16:43.360
<v Speaker 2>Yes, particularly with its audit policies. These use custom XML

330
00:16:43.480 --> 00:16:47.519
<v Speaker 2>based files, often called dot audit files. These files contain

331
00:16:47.639 --> 00:16:50.240
<v Speaker 2>rules that compare the actual configuration of a system, say

332
00:16:50.639 --> 00:16:53.840
<v Speaker 2>settings in the operating system or an application against a

333
00:16:53.879 --> 00:16:56.320
<v Speaker 2>predefined security baseliner.

334
00:16:55.759 --> 00:16:57.840
<v Speaker 1>Standard like CIS benchmarks.

335
00:16:57.879 --> 00:17:02.159
<v Speaker 2>Precisely things like CIS benchmarks, decist eggs, or even hypo requirements.

336
00:17:02.440 --> 00:17:05.000
<v Speaker 2>This is essential for white box assessments where you have

337
00:17:05.079 --> 00:17:07.920
<v Speaker 2>credentials to log into the system and check its internal

338
00:17:07.920 --> 00:17:11.359
<v Speaker 2>configuration thoroughly. You can even write your own custom checks

339
00:17:11.400 --> 00:17:15.039
<v Speaker 2>in XML for company specific policies. It moves beyond just

340
00:17:15.039 --> 00:17:18.599
<v Speaker 2>network vulnerabilities into configuration hardening and compliance.

341
00:17:18.640 --> 00:17:21.519
<v Speaker 1>Okay, this is all fascinating for standard IT networks, but

342
00:17:21.599 --> 00:17:25.319
<v Speaker 1>let's shift focus to something even more critical. Scanning industrial

343
00:17:25.319 --> 00:17:30.359
<v Speaker 1>control systems, IoT devices, the operational technology or OT world.

344
00:17:30.440 --> 00:17:33.599
<v Speaker 2>Ah, Yes, OT and ICs. This is where network security

345
00:17:33.640 --> 00:17:36.960
<v Speaker 2>gets well potentially kinetic. We're talking about the systems that

346
00:17:37.079 --> 00:17:44.279
<v Speaker 2>manage physical industrial processes, power generation, manufacturing lines, water treatment plants, building, automation,

347
00:17:44.720 --> 00:17:48.319
<v Speaker 2>and the list goes on. Industrial control systems ICs are

348
00:17:48.319 --> 00:17:49.000
<v Speaker 2>the heart of it.

349
00:17:48.880 --> 00:17:50.440
<v Speaker 1>And SCATI fits in here too. Yes.

350
00:17:50.519 --> 00:17:54.440
<v Speaker 2>Scatter supervisory control and data acquisition systems are often used

351
00:17:54.480 --> 00:17:58.759
<v Speaker 2>to provide that remote monitoring and control interface for ICs environments.

352
00:17:59.119 --> 00:18:02.319
<v Speaker 2>They're designed for high availability keeping processes running.

353
00:18:02.400 --> 00:18:05.960
<v Speaker 1>The risk here seems enormous. A failure isn't just data loss,

354
00:18:06.000 --> 00:18:07.599
<v Speaker 1>it could be much worse.

355
00:18:07.839 --> 00:18:11.839
<v Speaker 2>Exactly, A misconfiguration or exploited vulnerability in a SCATA or

356
00:18:12.079 --> 00:18:17.079
<v Speaker 2>ICs system could have catastrophic physical consequences and complicating matters.

357
00:18:17.200 --> 00:18:20.279
<v Speaker 2>Many of these systems are old. They were designed decades ago,

358
00:18:20.440 --> 00:18:23.519
<v Speaker 2>long before cybersecurity was a major concern, so they can

359
00:18:23.559 --> 00:18:25.960
<v Speaker 2>be incredibly fragile and full of vulnerabilities.

360
00:18:26.039 --> 00:18:29.000
<v Speaker 1>So can you even use tools like enmap and NESSUS

361
00:18:29.000 --> 00:18:31.119
<v Speaker 1>on these systems safely? It sounds risky.

362
00:18:31.400 --> 00:18:34.240
<v Speaker 2>You can, but you have to be extremely careful and knowledgeable.

363
00:18:34.440 --> 00:18:37.279
<v Speaker 2>In Map, for instance, has specific NSE scripts designed for

364
00:18:37.319 --> 00:18:40.920
<v Speaker 2>common ICs protocols. There's S seven dash info dot NZA

365
00:18:41.000 --> 00:18:45.000
<v Speaker 2>for Siemens S seven controllers and Modbus Dash Discover dot

366
00:18:45.119 --> 00:18:48.920
<v Speaker 2>NSA for modbus devices. These are widely used. They usually

367
00:18:48.960 --> 00:18:52.039
<v Speaker 2>talk on specific ports like TCP Port one oh two

368
00:18:52.200 --> 00:18:55.400
<v Speaker 2>for Semens S seven and port five oh two for Modbus.

369
00:18:56.039 --> 00:18:59.599
<v Speaker 2>NMAP can identify these systems and ness's nessis also has

370
00:18:59.640 --> 00:19:04.279
<v Speaker 2>dedicated plug in families specifically for SCATA and ICs devices. But,

371
00:19:04.799 --> 00:19:08.359
<v Speaker 2>and this is critical, you must configure NESSUS very carefully.

372
00:19:08.680 --> 00:19:11.839
<v Speaker 2>There's often an option like performed thorough tests or similar

373
00:19:11.960 --> 00:19:14.960
<v Speaker 2>unsafe checks. You absolutely want to make sure those dangerous

374
00:19:15.000 --> 00:19:18.599
<v Speaker 2>options are disabled when scanning sensitive ICs environments to avoid

375
00:19:18.680 --> 00:19:21.319
<v Speaker 2>crashing PLCs or disrupting critical processes.

376
00:19:21.400 --> 00:19:24.279
<v Speaker 1>That distinction is absolutely vital. Don't break the power plant

377
00:19:24.319 --> 00:19:25.640
<v Speaker 1>while trying to secure.

378
00:19:25.319 --> 00:19:28.559
<v Speaker 2>It, please don't. It really underscores that understanding these tools

379
00:19:28.599 --> 00:19:31.359
<v Speaker 2>isn't just about corporate IT security anymore. It's about the

380
00:19:31.359 --> 00:19:33.599
<v Speaker 2>broader security of our physical infrastructure too.

381
00:19:33.599 --> 00:19:36.440
<v Speaker 1>Right, and once you find these vulnerabilities, other tools might

382
00:19:36.440 --> 00:19:37.000
<v Speaker 1>come into play.

383
00:19:37.119 --> 00:19:41.400
<v Speaker 2>Unfortunately, Yes, frameworks like Metasploid also contained modules specifically designed

384
00:19:41.400 --> 00:19:45.000
<v Speaker 2>to exploit known SCATA and ICs vulnerabilities. It highlights the

385
00:19:45.119 --> 00:19:48.480
<v Speaker 2>urgent need for proactive discovery and careful mitigation in these

386
00:19:48.480 --> 00:19:49.440
<v Speaker 2>critical environments.

387
00:19:49.720 --> 00:19:52.960
<v Speaker 1>So we've really taken a deep dive today. We've gone

388
00:19:53.039 --> 00:19:56.799
<v Speaker 1>through the practical world of network security scanning, looked closely

389
00:19:56.839 --> 00:20:00.279
<v Speaker 1>at ENMP and NESSUS. Hopefully you listening now have a

390
00:20:00.359 --> 00:20:02.880
<v Speaker 1>much better grasp of not just what they do, but

391
00:20:03.000 --> 00:20:05.839
<v Speaker 1>why they do it, how to read their outputs, and crucially,

392
00:20:06.119 --> 00:20:09.640
<v Speaker 1>how to apply that critical thinking to confirm what really matters.

393
00:20:09.759 --> 00:20:12.240
<v Speaker 2>And remember it's not a one and done thing. Network

394
00:20:12.319 --> 00:20:17.640
<v Speaker 2>security is absolutely a continuous cycle. Assess analyze, mitigate, and

395
00:20:17.680 --> 00:20:19.960
<v Speaker 2>then start again constant vigilance.

396
00:20:20.160 --> 00:20:22.599
<v Speaker 1>So here's a final thought to leave you with. In

397
00:20:22.640 --> 00:20:26.960
<v Speaker 1>a world where everything, even our critical industrial systems, is

398
00:20:27.000 --> 00:20:31.079
<v Speaker 1>connected and potentially vulnerable, how does really understanding these deep

399
00:20:31.079 --> 00:20:34.440
<v Speaker 1>dive scanning techniques empower you not just to protect networks,

400
00:20:34.440 --> 00:20:37.200
<v Speaker 1>but to critically evaluate all the security information you encounter

401
00:20:37.440 --> 00:20:39.920
<v Speaker 1>and ultimately become a more informed guardian of both our

402
00:20:39.960 --> 00:20:41.400
<v Speaker 1>digital and our physical world.