WEBVTT 1 00:00:00.000 --> 00:00:02.240 You know, when you look at cybersecurity, it really feels 2 00:00:02.600 --> 00:00:08.160 less like some orderly game like chess and more like this, 3 00:00:08.439 --> 00:00:10.320 I don't know, this endless game of hide and seek, 4 00:00:11.320 --> 00:00:12.800 but with really high stakes. 5 00:00:12.919 --> 00:00:15.000 Yeah, it's a constant push and pull, isn't it a 6 00:00:15.000 --> 00:00:17.719 real cat and mouse situation between the attackers trying to 7 00:00:17.760 --> 00:00:21.239 breach systems and the defenders, you know, scrambling to keep. 8 00:00:21.079 --> 00:00:24.280 Them out exactly, And it goes way beyond just the tech, 9 00:00:24.440 --> 00:00:29.480 the firewalls and stuff. It's so much about strategy, deception 10 00:00:30.120 --> 00:00:32.479 and just trying to adapt faster than the other side. 11 00:00:32.560 --> 00:00:35.600 It really is a continuous loop, like attackers find a 12 00:00:35.600 --> 00:00:37.799 new way in, defenders build a patch or a detection 13 00:00:37.920 --> 00:00:40.240 for it. Then the attackers have to tweet their method, 14 00:00:40.359 --> 00:00:42.719 maybe bypass the new defense, and the whole cycle just 15 00:00:42.759 --> 00:00:43.359 speeds up. 16 00:00:43.679 --> 00:00:46.679 And really getting inside that dynamic understanding how it works. 17 00:00:47.560 --> 00:00:49.119 That's what we want to do in this deep dive. 18 00:00:49.320 --> 00:00:53.039 We're pulling insights directly from the book Adversarial Tradecraft and 19 00:00:53.079 --> 00:00:57.520 Cybersecurity Offense Versus Defense, and well specifically focusing on the 20 00:00:57.560 --> 00:01:00.560 parts about practical techniques and the sort of the ideas 21 00:01:00.600 --> 00:01:01.520 driving this conflict. 22 00:01:01.799 --> 00:01:05.079 Right The author Dan Boris. He brings this really interesting 23 00:01:05.200 --> 00:01:08.719 mix of experience. He's worked in the real world, you know, 24 00:01:08.760 --> 00:01:12.239 places like uber Mandy and CrowdStrike, but he also has 25 00:01:12.359 --> 00:01:17.159 deep experience in those big collegiate cyber competitions like CCDC 26 00:01:17.480 --> 00:01:21.480 and CPTC, so he's seen it all from multiple angles. 27 00:01:21.599 --> 00:01:27.040 Yeah, and that perspective shows the book seems aimed at practitioners, 28 00:01:27.079 --> 00:01:29.640 people actually doing the work, maybe folks starting out who 29 00:01:29.719 --> 00:01:31.760 might need to google a few things, up to say 30 00:01:31.799 --> 00:01:35.680 intermediate level people. It shows how lessons from those competitions 31 00:01:35.719 --> 00:01:39.920 really do apply to real world enterprise security absolutely. 32 00:01:40.079 --> 00:01:42.799 So our mission here really is to give you a shortcut. 33 00:01:43.040 --> 00:01:45.680 We want to distill the key takeaways, the most important 34 00:01:45.680 --> 00:01:48.000 bits from this source material to give you a clearer 35 00:01:48.000 --> 00:01:52.200 picture of the strategies, the tools, the techniques attackers use. 36 00:01:52.280 --> 00:01:54.640 And then how defenders try to counter that, and how 37 00:01:54.680 --> 00:01:56.799 each side is constantly reacting to the other. 38 00:01:56.959 --> 00:01:59.359 Exactly understanding that interaction is key. 39 00:01:59.480 --> 00:02:02.159 Okay, let's unpack this. The source starts by laying out 40 00:02:02.200 --> 00:02:06.000 some foundational building blocks for information security. Talks about the 41 00:02:06.000 --> 00:02:07.239 CION attributes. 42 00:02:07.640 --> 00:02:14.240 Ah, yes, CIAN that's confidentiality, integrity, availability, authentication, authorization, and 43 00:02:15.800 --> 00:02:19.080 non repudiation. Right, think of these as the sort of 44 00:02:19.159 --> 00:02:22.800 fundamental qualities of data and systems. They're what the attackers 45 00:02:22.840 --> 00:02:25.439 are trying to undermine and what the defenders are desperately 46 00:02:25.439 --> 00:02:26.280 trying to protect. 47 00:02:26.400 --> 00:02:30.439 And the Source really highlights non repudiation because of the 48 00:02:30.479 --> 00:02:34.120 defender's eyes and ears. What does that mean? Practically speaking? 49 00:02:34.319 --> 00:02:39.759 It basically means logging, good logging, creating solid, ideally unchangeable 50 00:02:39.960 --> 00:02:42.360 records of who did what, when they did it, where 51 00:02:42.400 --> 00:02:45.039 they did it from. If you don't capture that information, 52 00:02:45.199 --> 00:02:48.039 especially stuff that only happens in memory and disappears, well 53 00:02:48.080 --> 00:02:51.159 it's just gone pretty much. It's the main way defenders 54 00:02:51.199 --> 00:02:54.240 can piece together what happened after an incident or spot 55 00:02:54.319 --> 00:02:55.319 something shady going on. 56 00:02:55.520 --> 00:02:58.759 So if an attacker can mess with those logs, can 57 00:02:58.800 --> 00:03:01.919 erase their tracks effectively like blinding the defenders. 58 00:03:02.080 --> 00:03:05.199 Oh yeah, right. Beyond those basic attributes, the Source digs 59 00:03:05.199 --> 00:03:09.680 into several key principles of this computer conflict ideas that 60 00:03:09.719 --> 00:03:12.080 seem to guide the strategies for both sides. What are 61 00:03:12.080 --> 00:03:12.879 some of the big ones. 62 00:03:13.080 --> 00:03:15.080 Well, the principle of deception seems huge. 63 00:03:15.199 --> 00:03:19.199 Oh, absolutely, It's all about making abnormal things look totally normal. 64 00:03:19.599 --> 00:03:22.479 For an attacker, this is critical. If they can blend in, 65 00:03:22.639 --> 00:03:25.400 they can operate for much longer without getting caught. 66 00:03:25.400 --> 00:03:28.039 Like hiding in plain sight. And you can't really talk 67 00:03:28.080 --> 00:03:30.960 about this stuff without bringing in the human factor, right, 68 00:03:31.039 --> 00:03:32.240 the principle of humanity. 69 00:03:32.360 --> 00:03:37.159 Definitely, there's always a person involved somewhere targeting people, you know, 70 00:03:37.759 --> 00:03:42.599 social engineering, phishing emails that can often bypass even the 71 00:03:42.639 --> 00:03:46.479 best technical defenses. The source mentions that old classic getting 72 00:03:46.479 --> 00:03:48.879 a password off an employee at a bar faily works 73 00:03:48.960 --> 00:03:53.319 huh surprisingly often. Yeah. Then there's the principle of physical access. 74 00:03:53.639 --> 00:03:55.639 This one's pretty fundamental. 75 00:03:55.240 --> 00:03:58.199 Meaning if you can actually touch the machine, or if. 76 00:03:58.120 --> 00:04:01.639 You own the management interface for cloud stuff like AWS 77 00:04:01.759 --> 00:04:04.919 or the hypervisor like ESXi. If you have that level 78 00:04:04.919 --> 00:04:07.080 of a control, you generally win. You can dump the memory, 79 00:04:07.159 --> 00:04:09.800 reinstall the OS, just walk away with the hardware. Sometimes 80 00:04:10.080 --> 00:04:12.080 it usually trump's purely digital. 81 00:04:12.120 --> 00:04:16.720 Remote access makes sense total control versus like partial access 82 00:04:16.759 --> 00:04:19.959 through the network. Planning also seems key, oh for sure. 83 00:04:20.199 --> 00:04:23.639 The principle of planning. The book quotes sense, you know, 84 00:04:23.920 --> 00:04:26.759 plan for what is difficult while it is easy. You've 85 00:04:26.800 --> 00:04:29.560 got to have a plan, write it down, even practice it. 86 00:04:29.600 --> 00:04:31.439 If you can identify the weak. 87 00:04:31.240 --> 00:04:33.480 Spots, and that applies to both guides. 88 00:04:33.240 --> 00:04:37.519 Absolutely offense planning their attack path, defense planning their detection 89 00:04:37.639 --> 00:04:40.399 and response strategy. It's crucial for everyone. 90 00:04:40.680 --> 00:04:43.319 And then there's timing, the principle of time. 91 00:04:43.519 --> 00:04:46.680 Yeah, timing is critical in strategy. The source makes a 92 00:04:46.720 --> 00:04:50.360 good point about how the environment changes things. Short competitions 93 00:04:50.560 --> 00:04:56.360 like CCDC might allow for really noisy, aggressive tactics because time. 94 00:04:56.120 --> 00:04:57.800 Is limited, but in the real world. 95 00:04:57.920 --> 00:05:00.319 In the real world, attackers often need to be much 96 00:05:00.319 --> 00:05:03.920 more patient, slow, and low, you know, to maintain access 97 00:05:03.920 --> 00:05:07.560 long term without tripping alarms. Defenders, on the other hand, 98 00:05:07.759 --> 00:05:10.480 use time to build up those complex layered defenses we 99 00:05:10.519 --> 00:05:11.600 talked about gotcha. 100 00:05:11.680 --> 00:05:14.279 And finally, innovation non negotiable. 101 00:05:14.399 --> 00:05:17.800 The source quotes the MMA fighter Georgia Saint Pierre basically 102 00:05:17.839 --> 00:05:21.639 saying standing still is asking for failure. Both sides have 103 00:05:21.680 --> 00:05:25.959 to constantly adapt, create new techniques, find ways around existing. 104 00:05:25.600 --> 00:05:27.600 Ones, because as soon as your trick is known. 105 00:05:27.639 --> 00:05:30.800 It's effectiveness drops sometimes to zero. So if your tool 106 00:05:30.839 --> 00:05:33.639 gets detected, you need a plan B, maybe a Plan C. 107 00:05:33.920 --> 00:05:37.319 You have to pivot fast. That constant need to innovate 108 00:05:37.439 --> 00:05:39.600 really drives this whole adversarial game. 109 00:05:39.759 --> 00:05:43.480 Okay, that gives us a really solid strategic foundation. Now 110 00:05:44.079 --> 00:05:46.560 let's get into the specifics. What does the offensive playbook 111 00:05:46.600 --> 00:05:50.040 actually look like? How do attackers get in, and maybe 112 00:05:50.040 --> 00:05:53.519 more importantly, how do they stay hidden? The source mentioned 113 00:05:53.720 --> 00:05:57.319 a big shift away from like traditional disc forensics. 114 00:05:57.519 --> 00:05:59.759 Yeah, that's a really key point. For a long time 115 00:05:59.800 --> 00:06:02.839 to defenders could often find attacker tools and evidence by 116 00:06:02.879 --> 00:06:05.399 analyzing the hard drive after the fact. You know, dead 117 00:06:05.439 --> 00:06:08.920 disc forensics. Right, So attackers adapted. They started moving their 118 00:06:08.959 --> 00:06:13.360 operations beyond the disc. They operate live in memory in RAM, 119 00:06:13.519 --> 00:06:16.399 and the big difference there is volatility. When the malicious 120 00:06:16.399 --> 00:06:19.800 process stops or the computer reboots, poof the evidence in 121 00:06:19.879 --> 00:06:23.800 RAM is gone. This makes life much much harder for 122 00:06:23.879 --> 00:06:27.120 defenders relying only on those older disc based methods. 123 00:06:27.240 --> 00:06:30.480 Wow, operating purely a memory that sounds like a defender's nightmare. 124 00:06:30.480 --> 00:06:31.959 What kind of techniques do they use for that? 125 00:06:32.240 --> 00:06:35.000 Well, process injection is a really common one. The basic 126 00:06:35.040 --> 00:06:37.800 idea is to run your malicious code, often something called 127 00:06:37.879 --> 00:06:41.160 shell code, which is just low level machine instructions inside 128 00:06:41.160 --> 00:06:45.079 the memory space of a completely legitimate, trusted process that's 129 00:06:45.120 --> 00:06:46.000 already running. 130 00:06:46.560 --> 00:06:50.800 So instead of running like Evil dot ex. They sneak 131 00:06:50.839 --> 00:06:54.399 their code into something that looks normal. Maybe explore dot 132 00:06:54.439 --> 00:06:56.319 ex on Windbows exactly. 133 00:06:56.360 --> 00:06:59.040 That. The whole point is deception. It makes the malicious 134 00:06:59.079 --> 00:07:02.120 activity look like it's part of a normal, trusted program, 135 00:07:02.360 --> 00:07:04.519 so it's way harder for security tools to flag it. 136 00:07:04.639 --> 00:07:07.279 S suspicious. Very common on Windows, and there are different 137 00:07:07.319 --> 00:07:08.839 ways to do it, like DLL. 138 00:07:08.439 --> 00:07:09.920 Injection DL injection. 139 00:07:10.079 --> 00:07:13.759 Yeah, injecting a malicious dynamic link library a DLL file 140 00:07:14.000 --> 00:07:17.000 into another process is memory space, so that process loads 141 00:07:17.040 --> 00:07:18.399 and runs the malicious code. 142 00:07:18.480 --> 00:07:21.319 Okay, so they're hiding where their code is running, but 143 00:07:21.399 --> 00:07:24.120 they still need to communicate back home right to their 144 00:07:24.120 --> 00:07:26.720 command and control server, their C two. How do they 145 00:07:26.759 --> 00:07:27.120 hide that? 146 00:07:27.560 --> 00:07:30.600 Ah? Right, that's where covert C two comes in command 147 00:07:30.600 --> 00:07:34.199 and control. They need to maintain that connection for instructions 148 00:07:34.199 --> 00:07:37.600 and sending data back, but without their network traffic setting 149 00:07:37.600 --> 00:07:39.600 off alarms. So they try to make it blend in. 150 00:07:39.720 --> 00:07:42.879 Oh, by using protocols you'd expect to see anyway. 151 00:07:42.639 --> 00:07:46.839 Precisely tunneling their C two data over common stuff like ICMP, 152 00:07:47.120 --> 00:07:50.680 which is normally used for ping requests or DNS, the 153 00:07:50.800 --> 00:07:54.720 Domain Name lookup system, the source mentions tools like ikempdoor, 154 00:07:55.000 --> 00:07:57.920 or how the popular C two framework Sliver can use 155 00:07:58.000 --> 00:07:59.560 DNS for its C two channel. 156 00:07:59.839 --> 00:08:02.240 There was that specific example, and the source about Sliver 157 00:08:02.319 --> 00:08:03.360 and innovation wasn't there. 158 00:08:03.560 --> 00:08:06.759 Yes, good point. It mentions that Sliver's default setting for 159 00:08:06.839 --> 00:08:10.279 checking in over DNS might be, say, every second, which 160 00:08:10.279 --> 00:08:12.800 is pretty frequent. Potentially noisy on a network. 161 00:08:12.519 --> 00:08:13.759 Could get spotted. Good. 162 00:08:13.839 --> 00:08:17.319 Yeah, But because Sliver is often open source, an attacker 163 00:08:17.319 --> 00:08:19.120 can just go into the code and change that interval, 164 00:08:19.319 --> 00:08:21.519 maybe make it check in only every sixty seconds or 165 00:08:21.560 --> 00:08:25.920 even longer. Slower, but stealthier, much stealthier. It's a perfect 166 00:08:25.959 --> 00:08:29.480 example of that principle of innovation in action, taking an 167 00:08:29.519 --> 00:08:33.639 existing tool, tweaking it slightly based on defensive knowledge, and 168 00:08:33.679 --> 00:08:35.399 making it way harder to detect. 169 00:08:35.600 --> 00:08:38.799 That's fascinating. Such a small change, big impact. Okay, so 170 00:08:38.840 --> 00:08:40.840 they're in their communicating stealthily. 171 00:08:41.000 --> 00:08:41.639 Yeah. 172 00:08:41.679 --> 00:08:44.200 What about covering their tracks after they've done something on 173 00:08:44.240 --> 00:08:44.759 a system? 174 00:08:44.919 --> 00:08:47.120 Yeah, this is crucial if they want to stick around. 175 00:08:47.159 --> 00:08:51.360 Remember non repudiation, the logs being the defender's eyes. Will 176 00:08:51.399 --> 00:08:55.840 attackers know that? So clearing logs is a fundamental offensive technique. 177 00:08:55.919 --> 00:08:57.639 How do they do that? Just delete the files? 178 00:08:57.960 --> 00:09:02.080 Sometimes it's that crude, but smart attackers use more sophisticated methods, 179 00:09:02.159 --> 00:09:06.000 especially on Windows. Tools like event cleaner might use Windows 180 00:09:06.000 --> 00:09:10.039 API functions to manipulate the event log files directly, sometimes 181 00:09:10.080 --> 00:09:12.879 bypassing the usual ways files are locked, making it harder 182 00:09:12.919 --> 00:09:16.240 to spot the tampering. The source even mentions older techniques 183 00:09:16.279 --> 00:09:19.159 that could modify specific records or fix id numbers to 184 00:09:19.240 --> 00:09:19.919 make it look. 185 00:09:19.759 --> 00:09:23.480 Seamless, wow actually rewriting the history inside the logs, but 186 00:09:23.519 --> 00:09:26.480 the source said defenders can sometimes still spot this often. 187 00:09:26.639 --> 00:09:29.440 Yes, if you look closely, you might see gaps in 188 00:09:29.480 --> 00:09:33.240 record numbers, or the file size or modification times might 189 00:09:33.279 --> 00:09:36.480 look weird. On Linux, maybe they just pipe logs through 190 00:09:36.480 --> 00:09:39.080 e repdac V to filter out their activity, but that 191 00:09:39.120 --> 00:09:40.240 can leave traces. 192 00:09:39.919 --> 00:09:42.039 Too, So a more subtle. 193 00:09:41.679 --> 00:09:45.320 Way, the source suggests backdooring the service that creates the 194 00:09:45.360 --> 00:09:48.360 logs in the first place, like using a modified Apache 195 00:09:48.399 --> 00:09:51.440 web server module. A patchy to backdoor mod is mentioned 196 00:09:51.679 --> 00:09:55.159 that just doesn't write log entries for the attackers' specific actions. 197 00:09:55.360 --> 00:09:58.679 Ah, so the incriminating log entries never even created. Much 198 00:09:58.720 --> 00:09:59.440 harder to find what. 199 00:09:59.399 --> 00:10:02.039 Isn't there exactly, and that leads into the last big 200 00:10:02.120 --> 00:10:04.159 hiding technique mentioned root kits. 201 00:10:04.360 --> 00:10:06.639 Root kits that sounds serious It can be. 202 00:10:07.399 --> 00:10:10.840 Broadly speaking, root kits are techniques designed to actively change 203 00:10:10.879 --> 00:10:14.600 how the operating system or defensive tools perceive the system state. 204 00:10:15.000 --> 00:10:17.679 Their goal is to hide the attacker's presence, their files, 205 00:10:17.720 --> 00:10:20.320 their running processes, network connections, you name it. 206 00:10:20.399 --> 00:10:23.919 So they're not just hiding passively. They're actively manipulating what 207 00:10:23.960 --> 00:10:27.440 the system reports, like lying to tools like task manager 208 00:10:27.639 --> 00:10:28.080 or else. 209 00:10:28.399 --> 00:10:31.120 That's the core idea. Whether it's deep down in the 210 00:10:31.200 --> 00:10:34.360 kernel or using user level tricks, the goal is deception, 211 00:10:35.080 --> 00:10:38.960 make the malicious stuff invisible to standard system checks. Another 212 00:10:39.039 --> 00:10:40.799 direct hit on that principle of deception. 213 00:10:41.279 --> 00:10:45.000 Understanding all these offensive moves must be critical for the defenders. 214 00:10:45.320 --> 00:10:48.279 Oh absolutely, You can't build effective defenses if you don't 215 00:10:48.360 --> 00:10:51.519 understand how the attackers think and what techniques they're likely 216 00:10:51.559 --> 00:10:52.799 to use, which brings. 217 00:10:52.639 --> 00:10:55.559 Us perfectly to the defensive side of things. The source 218 00:10:56.120 --> 00:10:59.960 really hammers home that difficulty defenders face. They have to 219 00:11:00.120 --> 00:11:02.720 be right essentially one hundred percent of the time stop 220 00:11:02.759 --> 00:11:06.279 every attack, but the offense they just need one success 221 00:11:06.399 --> 00:11:07.000 one way in. 222 00:11:07.320 --> 00:11:10.279 It's a fundamental asymmetry, a real challenge and That's why 223 00:11:10.279 --> 00:11:14.080 the source emphasizes that preparation is paramount for defenders. You 224 00:11:14.120 --> 00:11:17.960 have to patiently, methodically build your defenses. The analogy used 225 00:11:18.000 --> 00:11:19.919 is like a spider building a web, but maybe a 226 00:11:19.919 --> 00:11:21.039 web with many, many. 227 00:11:20.879 --> 00:11:24.279 Layers, so that concept of defense in depth precisely. 228 00:11:24.639 --> 00:11:27.360 The goal isn't always to prevent that initial breach, because 229 00:11:27.360 --> 00:11:30.320 sometimes you just can't. It's about having multiple layers of 230 00:11:30.360 --> 00:11:33.559 detection and control so you can spot the attacker as 231 00:11:33.600 --> 00:11:35.960 they try to move deeper into the network or achieve 232 00:11:36.000 --> 00:11:37.159 their objectives. 233 00:11:36.759 --> 00:11:38.159 And preparing for the inevitable. 234 00:11:38.320 --> 00:11:41.759 Yes, preparing your response processes too, because realistically you will 235 00:11:41.759 --> 00:11:44.559 get compromised at some point. Knowing what to do when 236 00:11:44.559 --> 00:11:47.240 that happens is just as vital as trying to prevent it. 237 00:11:47.600 --> 00:11:51.799 Okay, so how do they build this defensive web and 238 00:11:51.840 --> 00:11:54.039 how do they spot the attacker moving around inside? It 239 00:11:54.200 --> 00:11:56.480 sounds like it all comes down to data data. 240 00:11:56.679 --> 00:12:00.639 It really does. Defenders are hugely reliant on monitoring and logging, 241 00:12:00.919 --> 00:12:03.919 collecting as much relevant data as possible from everywhere they. 242 00:12:03.759 --> 00:12:06.879 Can, starting on the individual computers, the endpoints. 243 00:12:06.559 --> 00:12:10.720 YEP host based data. This is where modern EDR endpoint 244 00:12:10.759 --> 00:12:14.360 detection and response platforms are so important. Tools like oscary, 245 00:12:14.759 --> 00:12:19.320 gr Rapid Response, Wazoo, velociraptor. There are great open source 246 00:12:19.360 --> 00:12:20.759 options plus commercial ones. 247 00:12:20.840 --> 00:12:22.320 What did These eder tools give. 248 00:12:22.200 --> 00:12:28.039 You incredible visibility, detailed telemetry about processes like what programs started, what, 249 00:12:28.039 --> 00:12:31.080 what files did it touch? What network connections did it make? 250 00:12:31.399 --> 00:12:35.159 They also look at behavior spotting anomalies, and many offer 251 00:12:35.279 --> 00:12:40.039 live response capabilities, letting defenders investigate or contain a machine remotely. 252 00:12:40.440 --> 00:12:43.320 So it's not just about looking for known bad files, 253 00:12:43.399 --> 00:12:46.480 it's watching what things do exactly. 254 00:12:46.600 --> 00:12:49.559 Watching behavior is key and all this data is also 255 00:12:49.720 --> 00:12:53.720 crucial for threat hunting, where analysts proactively search through the 256 00:12:53.799 --> 00:12:57.799 data using hypotheses about potential threats. Looking for subtle signs 257 00:12:57.799 --> 00:13:00.639 of compromise that might not have triggered an automated alert. 258 00:13:00.600 --> 00:13:03.039 Makes sense, but you also need eyes on the traffic 259 00:13:03.039 --> 00:13:04.480 between machines right absolutely. 260 00:13:04.639 --> 00:13:07.399 Network based data is the other critical piece. You get 261 00:13:07.440 --> 00:13:10.639 this by setting up network taps or using inline devices 262 00:13:10.679 --> 00:13:14.480 like firewalls or intrusion prevention systems IPS. These let you 263 00:13:14.480 --> 00:13:16.960 see the traffic flowing across the network. 264 00:13:16.600 --> 00:13:18.759 And the sorts had that analogy, Yeah, it was a 265 00:13:18.759 --> 00:13:19.200 good one. 266 00:13:19.320 --> 00:13:21.600 Host data is like finding a needle in a haystack. 267 00:13:21.679 --> 00:13:25.120 Sometimes network data is more like watching the traffic on 268 00:13:25.159 --> 00:13:30.159 a highway. You can spot unusual patterns like unexpected connections 269 00:13:30.159 --> 00:13:33.559 between servers, data moving where it shouldn't, or those covert 270 00:13:33.759 --> 00:13:35.240 C two channels we talked about. 271 00:13:35.320 --> 00:13:38.600 Okay, and the tools mentioned here were things like snort 272 00:13:38.919 --> 00:13:43.360 cercata Zeke for analyzing protocols, and wire shark or t 273 00:13:43.480 --> 00:13:47.799 shark for really deep packet inspection. Controlling those network joke 274 00:13:47.840 --> 00:13:48.960 points seems vital. 275 00:13:49.080 --> 00:13:52.080 It really is, and you can't forget application logs either. 276 00:13:52.279 --> 00:13:54.360 Logs from specific programs. 277 00:13:53.960 --> 00:13:57.279 Right logs from your security tools themselves, email gateways, web 278 00:13:57.320 --> 00:14:01.279 application firewalls, wafs, but also so logs from your core 279 00:14:01.360 --> 00:14:06.159 business applications think e commerce platforms, internal APIs. These can 280 00:14:06.159 --> 00:14:09.279 show things like weird log in patterns, super fast browsing 281 00:14:09.320 --> 00:14:11.919 that looks like scraping, or other signs of abuse. 282 00:14:12.080 --> 00:14:14.720 Okay, that is a mountain of data coming from endpoints, 283 00:14:14.799 --> 00:14:18.120 the network applications. How on earth do defenders actually make 284 00:14:18.159 --> 00:14:18.759 sense of it all. 285 00:14:18.840 --> 00:14:22.600 That's where SIME and SORE platforms come in. SIME stands 286 00:14:22.600 --> 00:14:26.639 for Security Information and Event Management, SAR is security orchestration 287 00:14:26.720 --> 00:14:30.799 automation and response tools like Splunk or the open source 288 00:14:30.840 --> 00:14:36.000 ELK stack Elastic Search Logstash cabana, sometimes called HLK. They 289 00:14:36.080 --> 00:14:39.559 exist to pull all this diverse log data into one central. 290 00:14:39.240 --> 00:14:41.639 Place, so you can actually search across everything at once. 291 00:14:41.799 --> 00:14:44.960 Yes, and maybe even more importantly, you can correlate events 292 00:14:44.960 --> 00:14:48.679 across different data sources. A single weird login attempt from 293 00:14:48.679 --> 00:14:51.399 the firewall might not be alarming. But if you see 294 00:14:51.440 --> 00:14:54.559 that plus some strange process starting on the target machine 295 00:14:54.559 --> 00:14:56.600 in your EDER logs at the exact same time. 296 00:14:56.480 --> 00:14:58.320 Okay, now that looks suspicious exactly. 297 00:14:58.360 --> 00:15:01.960 That correlation is powerful. This is where defenders can figure alerts, 298 00:15:02.039 --> 00:15:05.519 often using complex logic. If you see event A and D, 299 00:15:05.639 --> 00:15:08.200 event boor event C, then trigger an alert. 300 00:15:08.360 --> 00:15:11.519 And the sore part adds automation like playbooks. 301 00:15:11.799 --> 00:15:15.639 Right, If a really high confidence alert fires, a saucer 302 00:15:15.679 --> 00:15:20.360 system can automatically run a predefined playbook. Maybe it quarantines 303 00:15:20.399 --> 00:15:23.840 the affected computer off the network, blocks the suspicious IP 304 00:15:23.879 --> 00:15:27.440 address at the firewall, or temporarily disables the user's account, 305 00:15:27.759 --> 00:15:30.080 all without needing immediate human intervention. 306 00:15:30.279 --> 00:15:33.600 Okay, So all this infrastructure, the data collection, the sign 307 00:15:33.679 --> 00:15:37.039 the alerts, it's all geared towards finding the threat. The 308 00:15:37.080 --> 00:15:41.519 source really emphasizes that idea, no normal find evil. 309 00:15:41.799 --> 00:15:44.720 It's a fundamental concept in defense. If you have a 310 00:15:44.799 --> 00:15:48.399 solid understanding of what normal, legitimate activity looks like on 311 00:15:48.440 --> 00:15:51.840 your network and your systems, what processes usually run, who 312 00:15:52.000 --> 00:15:55.120 usually logs in from where, what traffic patterns are typical, 313 00:15:55.159 --> 00:15:57.919 then the anomalies the evil will stand out much more clearly. 314 00:15:57.960 --> 00:16:00.759 It requires baselining, and once they do find a threat, 315 00:16:01.039 --> 00:16:03.600 The source talks about the importance of root cause analysis 316 00:16:03.720 --> 00:16:07.240 or RCA. Why is digging into the how so critical? 317 00:16:07.360 --> 00:16:09.639 Because just kicking the attacker out isn't enough if you 318 00:16:09.720 --> 00:16:11.799 don't figure out how they got in originally. Was it 319 00:16:11.840 --> 00:16:15.919 a phishing link, an unpatched server, stolen credentials, You haven't 320 00:16:15.960 --> 00:16:18.120 fixed the underlying vulnerability. 321 00:16:17.600 --> 00:16:19.600 And they'll just get back in the same way exactly. 322 00:16:19.639 --> 00:16:22.519 You have to close the door they used, otherwise you're 323 00:16:22.559 --> 00:16:25.240 just playing whack a mole. RCA is about learning from 324 00:16:25.240 --> 00:16:27.080 the incident to prevent it from happening. 325 00:16:26.759 --> 00:16:30.440 Again, and defenders use all this data and analysis to 326 00:16:30.480 --> 00:16:33.360 try and spot the attacker's attempts at deception, like the 327 00:16:33.440 --> 00:16:35.320 root kits and covert c two. 328 00:16:35.399 --> 00:16:39.720 We discussed absolutely. Detecting root kits might involve looking for 329 00:16:39.799 --> 00:16:43.480 weird inconsistencies like a process is running but doesn't show 330 00:16:43.559 --> 00:16:46.840 up in task manager, or you can CD into a 331 00:16:46.879 --> 00:16:51.080 directory that sells claims doesn't exist. For covert C two, 332 00:16:51.240 --> 00:16:54.639 they might use frequency analysis on DNS requests, looking for 333 00:16:54.720 --> 00:16:58.840 hosts making unusually regular lookups, or analyzed traffic patterns for 334 00:16:58.879 --> 00:16:59.559 other anomalies. 335 00:16:59.600 --> 00:17:02.039 I thought it was interesting that source also mentioned defenders 336 00:17:02.200 --> 00:17:03.559 using deception themselves. 337 00:17:03.759 --> 00:17:07.240 Yeah, fighting fire with fire, right, Yeah, deploying deception technologies 338 00:17:07.279 --> 00:17:10.640 like honeypots. These are decoy systems deliberately made to look 339 00:17:10.680 --> 00:17:14.839 attractive to attackers, like bait exactly. They sit there looking vulnerable, 340 00:17:14.920 --> 00:17:17.480 and the moment an attacker touches them, alarms go off. 341 00:17:17.920 --> 00:17:20.880 Tools like teapotter artillery can set these up, or you 342 00:17:20.880 --> 00:17:26.119 can use honey tokens things like fake awskeys, fake database credentials, 343 00:17:26.200 --> 00:17:28.759 or even fake user accounts scattered around. 344 00:17:28.519 --> 00:17:29.680 And if anyone tries. 345 00:17:29.480 --> 00:17:32.240 To use them, bingo, you know someone's poking around where 346 00:17:32.240 --> 00:17:35.400 they shouldn't be. It turns the attacker's own methods against them. 347 00:17:35.480 --> 00:17:39.640 Clever, Okay, So an attacker is found, maybe the root 348 00:17:39.720 --> 00:17:44.559 cause is being investigated. What are the immediate actions defenders. 349 00:17:44.119 --> 00:17:48.079 Take response and containment. You need to stop the bleeding 350 00:17:48.200 --> 00:17:50.759 and get the attacker out. This can range from simple 351 00:17:50.759 --> 00:17:53.640 things like killing their processes kill nine toutch nine on 352 00:17:53.720 --> 00:17:57.279 Linux as the classic, or blocking their IP addresses using 353 00:17:57.279 --> 00:18:01.240 firewall rules like with iptables. More significant yeah like network 354 00:18:01.319 --> 00:18:04.920 quarantine taking the compromise machine completely off the main network. 355 00:18:05.079 --> 00:18:07.200 This stops the attacker from using it to jump to 356 00:18:07.279 --> 00:18:11.039 other systems lateral movement while the security team investigates and 357 00:18:11.079 --> 00:18:11.680 cleans it up. 358 00:18:12.039 --> 00:18:14.680 The source also mentioned ways to lock down files even 359 00:18:14.720 --> 00:18:17.039 if the attacker gets high privileges. 360 00:18:16.880 --> 00:18:20.319 Right using native OS features. On Linux, there's a command 361 00:18:20.440 --> 00:18:24.079 chat wise plus I. Setting the immutable flag on a 362 00:18:24.119 --> 00:18:27.400 file means nobody, not even the root user, can modify 363 00:18:27.480 --> 00:18:30.720 or delete it without first removing that flag. It's a 364 00:18:30.720 --> 00:18:33.640 great way to protect critical configuration files. 365 00:18:33.359 --> 00:18:37.200 Or logs, simple but effective, and limiting the blast radius 366 00:18:37.200 --> 00:18:37.920 if they do get in. 367 00:18:38.480 --> 00:18:42.279 Using techniques like crute. This basically creates a little jail 368 00:18:42.319 --> 00:18:45.279 for a process, restricting its view of the filesystem to 369 00:18:45.440 --> 00:18:49.480 just one specific directory. So if an attacker compromises, say 370 00:18:49.920 --> 00:18:52.720 a web server running inside a cruite jail, for Verlado. 371 00:18:53.039 --> 00:18:56.160 They can only see and affect files within Varderdoo. They 372 00:18:56.160 --> 00:18:58.119 can't easily access the rest of the system. 373 00:18:58.440 --> 00:19:01.079 Not perfect security, but slows them exactly. 374 00:19:01.240 --> 00:19:03.680 It limits the scope of the compromise. And of course 375 00:19:03.720 --> 00:19:06.880 a crucial step is always rotating any passwords or credentials 376 00:19:06.920 --> 00:19:08.519 that might have been exposed during the incident. 377 00:19:08.599 --> 00:19:10.960 Okay, we've covered a lot of the tactical back and forth, 378 00:19:11.440 --> 00:19:14.039 but the source also widens the lens a bit. Talks 379 00:19:14.039 --> 00:19:15.839 about this ongoing intelligence war. 380 00:19:16.200 --> 00:19:19.559 Yeah, both sides are constantly doing research and gathering intel. 381 00:19:19.839 --> 00:19:24.519 For attackers, it's offensive research before they even launch an attack. 382 00:19:24.559 --> 00:19:28.319 They're mapping the target's network, trying to understand user privileges, 383 00:19:28.839 --> 00:19:32.160 figuring out the org chart for potential social engineering targets. 384 00:19:32.160 --> 00:19:32.880 Why do they do that? 385 00:19:33.160 --> 00:19:37.279 Tools like Bloodhound are amazing for visualizing relationships in Windows 386 00:19:37.319 --> 00:19:42.160 active directory environments, finding attack paths. They might scrape internal 387 00:19:42.200 --> 00:19:46.039 company wikis if they get access, look for leaked passwords online, 388 00:19:46.480 --> 00:19:49.440 or use tools like Hydra to try and guest passwords 389 00:19:49.480 --> 00:19:51.960 by spraying common ones across many. 390 00:19:51.759 --> 00:19:54.440 Accounts, basically casing the joint before the break. 391 00:19:54.240 --> 00:19:56.720 In pretty much, and defenders are doing their own defensive 392 00:19:56.720 --> 00:20:00.279 research and threat hunting. This involves threat modeling basically trying 393 00:20:00.279 --> 00:20:02.759 to think like an attacker, where are weak spots, how 394 00:20:02.799 --> 00:20:03.559 would someone try to. 395 00:20:03.519 --> 00:20:05.839 Get in, anticipating moves right, and. 396 00:20:05.920 --> 00:20:09.559 Threat hunting, which we touched on proactively searching through all 397 00:20:09.559 --> 00:20:12.119 that log data for signs of threats based on the 398 00:20:12.160 --> 00:20:16.720 latest intelligence about attacker techniques or just based on security hypotheses. 399 00:20:16.960 --> 00:20:20.240 The source had that example of the University Virginia CCDC 400 00:20:20.400 --> 00:20:22.880 team building their own tool, blue Spawn. 401 00:20:23.079 --> 00:20:26.599