WEBVTT 1 00:00:00.120 --> 00:00:02.640 Welcome to the deep dive. You give it some really 2 00:00:02.680 --> 00:00:08.119 interesting material here, focusing on Windows security internals and PowerShell. 3 00:00:08.240 --> 00:00:09.880 Yeah, it's a great combination to look at. 4 00:00:09.960 --> 00:00:13.080 So that's our focus today. Our mission really is to 5 00:00:13.119 --> 00:00:15.560 pull out the core ideas, give you a shortcut to 6 00:00:15.640 --> 00:00:20.519 understanding how Windows handles security management and how PowerShell fits 7 00:00:20.519 --> 00:00:23.120 in as well, like an investigative. 8 00:00:22.440 --> 00:00:24.679 Tool, right without getting totally lost in the weeds. There's 9 00:00:24.719 --> 00:00:26.600 a lot of detail in these sources exactly. 10 00:00:26.640 --> 00:00:30.640 We're aiming for those aha moments, you know, finding the 11 00:00:30.719 --> 00:00:34.960 surprising bits about Windows security that PowerShell helps uncover. 12 00:00:35.200 --> 00:00:37.719 And what's really cool is how the sources link these 13 00:00:37.960 --> 00:00:41.920 like abstract security concepts directly to practical PowerShell commands. 14 00:00:42.000 --> 00:00:43.560 So it's not just theory, not at all. 15 00:00:43.600 --> 00:00:46.240 We'll actually see how PowerShell can light up the internals. 16 00:00:46.240 --> 00:00:49.560 Okay, let's dive in. The material starts by emphasizing setting 17 00:00:49.640 --> 00:00:53.280 up a PowerShell testing environment. Why is that the first 18 00:00:53.479 --> 00:00:54.280 crucial step. 19 00:00:54.679 --> 00:00:58.000 Well, it's super important because you need a safe place, 20 00:00:58.079 --> 00:01:01.039 a sandbox, right to try out these commands without messing 21 00:01:01.079 --> 00:01:02.039 up your actual system. 22 00:01:02.320 --> 00:01:05.599 Makes sense, you don't want to break anything accidentally exactly. 23 00:01:05.400 --> 00:01:08.959 And the source talks about set execution policy. Think of 24 00:01:09.000 --> 00:01:12.760 that as your first safety net stops accidental script running. 25 00:01:12.519 --> 00:01:14.400 Which can be a security risk in itself. 26 00:01:14.480 --> 00:01:17.200 Oh definitely. And the key thing is that set scope 27 00:01:17.280 --> 00:01:18.680 current user option for. 28 00:01:18.719 --> 00:01:21.400 Keeping tests just within your user account. 29 00:01:21.079 --> 00:01:24.400 Right, isolated testing. If you want system wide changes, well 30 00:01:24.400 --> 00:01:26.879 that's different. You'd need admin privileges for that, and you 31 00:01:26.920 --> 00:01:28.159 wouldn't use the scope parameter. 32 00:01:28.239 --> 00:01:31.120 Then gotcha. And the source notes that some setups, like 33 00:01:31.200 --> 00:01:35.959 maybe open source PowerShell or newer server versions might already 34 00:01:35.959 --> 00:01:37.959 have remote signed as the default. 35 00:01:38.159 --> 00:01:40.879 Yeah, so it's always smart to just check first, know 36 00:01:40.920 --> 00:01:41.640 where you stand. 37 00:01:41.719 --> 00:01:46.239 Okay, Next up PowerShell language basics. For someone diving into 38 00:01:46.239 --> 00:01:49.799 this material, what are the foundational bits that really give 39 00:01:49.840 --> 00:01:50.599 you leverage here? 40 00:01:50.760 --> 00:01:53.920 The sources bring up a few key things special variables 41 00:01:53.959 --> 00:01:57.439 like null p TOBE for your current directory pobid that's. 42 00:01:57.319 --> 00:01:59.120 The PowerShell process idea itself. 43 00:01:59.480 --> 00:02:03.079 Yeah, exactly, and ORNA four for environment variables like EnEv 44 00:02:03.400 --> 00:02:08.120 windeer knowing innovator D is surprisingly useful for security scripting 45 00:02:08.400 --> 00:02:09.840 context matters. 46 00:02:09.680 --> 00:02:12.599 And the difference between single and double quotes crucial. 47 00:02:12.879 --> 00:02:15.759 Double quotes allow string interpolation. 48 00:02:15.599 --> 00:02:18.360 So variables get automatically substituted in right. 49 00:02:18.479 --> 00:02:22.520 Makes building dynamic commands way easier, no messy string joining 50 00:02:22.840 --> 00:02:25.960 single quotes. They treat everything literally good when you need 51 00:02:25.960 --> 00:02:27.120 that exact string. 52 00:02:27.120 --> 00:02:30.560 That interpolation is a huge time saver. The source also 53 00:02:30.599 --> 00:02:34.960 mentions creating objects a new object using a GID as 54 00:02:34.960 --> 00:02:35.400 an example. 55 00:02:35.439 --> 00:02:39.360 Yeah, basic object creation and the naming convention for commands 56 00:02:39.639 --> 00:02:41.800 verb noun like a get item. 57 00:02:41.960 --> 00:02:44.039 Seems designed to make things easier to find. 58 00:02:44.199 --> 00:02:46.759 It really does help. You can often guess command names 59 00:02:46.800 --> 00:02:50.599 and then parameters like megapath with get item, let you focus. 60 00:02:50.280 --> 00:02:52.400 The command so you can target specific. 61 00:02:52.000 --> 00:02:54.240 Things exactly, and we'll get to get member later. But 62 00:02:54.280 --> 00:02:56.599 think of that as your magnifying glass for figuring out 63 00:02:56.599 --> 00:02:58.319 what an object is and what you can do with it. 64 00:02:58.560 --> 00:03:00.479 Okay, so you have these basic tools, how do you 65 00:03:00.520 --> 00:03:02.719 learn to use them effectively? The source talks a lot 66 00:03:02.719 --> 00:03:03.400 about get help. 67 00:03:03.560 --> 00:03:07.960 Oh, get help is your best friend in PowerShell, seriously indispensable. 68 00:03:08.080 --> 00:03:08.840 What does it give you? 69 00:03:08.919 --> 00:03:12.159 The synopsis, the full syntax, detailed descriptions, and what's really 70 00:03:12.159 --> 00:03:14.759 handy is using wild cards for parameter. 71 00:03:14.439 --> 00:03:18.199 Names like the ubjet example to find parameters starting with. 72 00:03:18.159 --> 00:03:21.800 Objeck exactly and the example's parameter that's often the best 73 00:03:21.800 --> 00:03:25.599 part real world usage examples invaluable can't. 74 00:03:25.360 --> 00:03:28.400 Be practical examples. Okay, now, what about making your own 75 00:03:28.479 --> 00:03:32.919 PowerShell tools. The material covers functions. What's key there, Well. 76 00:03:32.840 --> 00:03:36.599 The basics are the function keyword, then your function name. 77 00:03:37.039 --> 00:03:39.800 It's good practice to stick to that verb noun convention 78 00:03:40.120 --> 00:03:43.400 even for your own stuff. Keeps things consistent, makes sense, 79 00:03:43.879 --> 00:03:47.560 and parameters defined in the tarum block. You can specify 80 00:03:47.599 --> 00:03:50.199 types like string name, but you don't have to. PowerShell's 81 00:03:50.199 --> 00:03:50.919 pretty flexible. 82 00:03:51.000 --> 00:03:52.680 What if you don't use param. 83 00:03:52.599 --> 00:03:54.639 Then any arguments you pass just end up in the 84 00:03:54.800 --> 00:03:57.599 arg's array. You access them by number, like ARGs dollars 85 00:03:57.639 --> 00:03:58.639 or r T one. 86 00:03:58.439 --> 00:04:02.520 So named parameters are just numbered arguments. Good flexibility. Okay. 87 00:04:02.599 --> 00:04:06.199 The deep dive then shifts to output. How PowerShell shows 88 00:04:06.240 --> 00:04:07.719 you stuff and how you can control it. 89 00:04:08.000 --> 00:04:11.199 Right, So, when a command runs and you don't assign 90 00:04:11.199 --> 00:04:14.319 the output to a variable, PowerShell steps in and tries 91 00:04:14.360 --> 00:04:17.079 to display it nicely, usually a table or a list. 92 00:04:17.240 --> 00:04:18.959 It guesses the best format. 93 00:04:18.920 --> 00:04:22.600 Kind of yeah, based on the object's properties, but you 94 00:04:22.680 --> 00:04:26.079 have control. Select object is key for picking just the 95 00:04:26.120 --> 00:04:28.959 properties you care about. Cuts down the noise. 96 00:04:29.120 --> 00:04:32.199 Nice and format list forces. 97 00:04:31.800 --> 00:04:35.360 It into a list view one property per line. Basically 98 00:04:35.600 --> 00:04:37.319 great when you want to see all the details for 99 00:04:37.319 --> 00:04:39.439 a single object rather than a wide table. 100 00:04:39.600 --> 00:04:41.839 And if you don't even know what properties are available, 101 00:04:42.160 --> 00:04:44.639 that's where get member comes in again, right with DJ 102 00:04:44.800 --> 00:04:45.959 type property. 103 00:04:45.680 --> 00:04:48.079 Exactly if pipe your command output to get member iban 104 00:04:48.120 --> 00:04:50.240 type property and boom, you get the full list of 105 00:04:50.319 --> 00:04:52.759 data points you can access on those objects. It's like asking, 106 00:04:52.920 --> 00:04:54.399 what can you tell me about yourself? 107 00:04:54.480 --> 00:04:57.800 The decoder ring analogy works. Yeah, and sort object to 108 00:04:57.920 --> 00:04:59.279 organize it, yep, sort. 109 00:04:59.079 --> 00:05:02.199 My name, my side by memory usage, whatever property you need. 110 00:05:02.319 --> 00:05:03.600 Brings order to the chaos. 111 00:05:03.680 --> 00:05:05.759 Okay, so you can view the data how you want 112 00:05:05.759 --> 00:05:07.759 in the console, but what about saving it? 113 00:05:08.319 --> 00:05:12.199 Exporting data out file is the straightforward way. Saves the 114 00:05:12.240 --> 00:05:14.560 text output just as you see it to a file, 115 00:05:14.959 --> 00:05:16.720 then get content reads. 116 00:05:16.480 --> 00:05:17.480 It back end and the symbol. 117 00:05:17.639 --> 00:05:20.560 That's just a shortcut for outfile, quick and easy. But 118 00:05:20.759 --> 00:05:23.680 for like structured data you might want and excel h 119 00:05:23.920 --> 00:05:27.639 that's where export csv comes in. Creates a proper comma 120 00:05:27.680 --> 00:05:31.519 separated value file, much better for spreadsheets or databases. 121 00:05:31.720 --> 00:05:33.680 And that not no type information parameter. 122 00:05:33.800 --> 00:05:37.560 Oh yeah, good catch that just stops PowerShell from Putting 123 00:05:37.759 --> 00:05:41.199 that extra halftag type information line at the top of 124 00:05:41.240 --> 00:05:44.079 the CSV makes it cleaner for other programs to read. 125 00:05:44.279 --> 00:05:47.079 Okay, good tip. We've covered a lot of PowerShell basics. 126 00:05:47.240 --> 00:05:50.199 Now the material shifts gears, heading down into the Windows 127 00:05:50.279 --> 00:05:53.120 kernel and its security role. This feels like the real 128 00:05:53.160 --> 00:05:53.920 deep dive part. 129 00:05:54.040 --> 00:05:56.399 This is where it gets really fascinating. Yeah. The kernel, 130 00:05:56.800 --> 00:05:59.560 that's the absolute core of the OS, where a fundamental 131 00:05:59.560 --> 00:06:00.959 security decisions. 132 00:06:00.600 --> 00:06:03.720 Happen, and the connection point is system calls exactly. 133 00:06:04.040 --> 00:06:07.360 System calls are the bridge the way user mode applications, 134 00:06:07.399 --> 00:06:10.199 the stuff we normally run talk to the privileged kernel 135 00:06:10.199 --> 00:06:13.319 mode where the OS does its heavy lifting and enforcement. 136 00:06:13.240 --> 00:06:16.600 The link between our apps and the OS's security core. Okay, 137 00:06:16.600 --> 00:06:19.680 the material is several key kernel subsystems. Can you give 138 00:06:19.759 --> 00:06:21.360 us the quick security relevance run down? 139 00:06:21.399 --> 00:06:25.560 Sure you've got The object manager manages all kernel objects, 140 00:06:25.639 --> 00:06:29.040 the basic building blocks. The io manager handles data moving 141 00:06:29.040 --> 00:06:32.040 in and out. Process and thread manager creates and manages 142 00:06:32.120 --> 00:06:36.920 running code. Memory manager controls memory use. Configuration manager that's 143 00:06:37.000 --> 00:06:41.360 the registry code integrity. Make sure only trusted code runs. 144 00:06:41.079 --> 00:06:42.000 A lot of managers. 145 00:06:42.879 --> 00:06:49.639 Yeah, and crucially for security, the Security reference monitor, the SRM. 146 00:06:49.920 --> 00:06:52.279 SRM sounds important, the ultimate gatekeeper. 147 00:06:52.319 --> 00:06:54.439 Maybe that's a good way to put it. The SRM 148 00:06:54.519 --> 00:06:57.720 is the kernel component that actually enforces security policy. It 149 00:06:57.759 --> 00:06:59.079 decides who gets access to what. 150 00:06:59.519 --> 00:07:00.319 How does it do that? 151 00:07:00.439 --> 00:07:02.800 It uses two key things mentioned right in your source, 152 00:07:03.079 --> 00:07:06.800 access tokens and security descriptors. Every process has an access 153 00:07:06.839 --> 00:07:09.319 token saying who it is. Every resource, like a file 154 00:07:09.399 --> 00:07:12.519 or registry key, has a security descriptor saying who's allowed 155 00:07:12.519 --> 00:07:13.040 to access. 156 00:07:13.279 --> 00:07:15.079 So the SRN compares the token. 157 00:07:14.839 --> 00:07:19.120 To the descriptor exactly when a process tries to access something, 158 00:07:19.240 --> 00:07:21.959 the SRM looks at its token, looks at the resources 159 00:07:22.000 --> 00:07:26.319 security descriptor, and makes the call allow or deny access. 160 00:07:26.399 --> 00:07:30.160 Tokens and security descriptors yes, central players, yeah, okay. The 161 00:07:30.199 --> 00:07:33.720 material then dives into security descriptors and sids. What's the 162 00:07:33.759 --> 00:07:34.600 relationship there. 163 00:07:35.279 --> 00:07:40.639 Sid's security identifiers are the unique names for users, groups, computers, 164 00:07:40.759 --> 00:07:43.319 anything the system needs to identify for security. 165 00:07:43.759 --> 00:07:46.959 Think of them like unique ideas, and they're inside security 166 00:07:46.959 --> 00:07:47.839 descriptors right. 167 00:07:47.920 --> 00:07:51.480 Security descriptors use sids to specify who is being allowed 168 00:07:51.600 --> 00:07:54.839 or denied access. The source shows using get into SID 169 00:07:54.879 --> 00:07:58.839 to translate the raw SID string like S one five, three, two, five. 170 00:07:58.720 --> 00:08:01.040 Four five into built users. 171 00:08:00.839 --> 00:08:04.879 Exactly, translating the system's internal ID into something we recognize. 172 00:08:04.959 --> 00:08:08.079 So sids are the language of security identity. Next the 173 00:08:08.120 --> 00:08:10.759 object manager and its name space. This sounds like how 174 00:08:10.800 --> 00:08:12.720 the kernel keeps all its objects organized. It is. 175 00:08:12.800 --> 00:08:15.240 Think of the object manager name space the OMNS as 176 00:08:15.319 --> 00:08:17.639 like a hidden file system just for kernel. 177 00:08:17.319 --> 00:08:19.279 Objects, a file system for kernel stuff. 178 00:08:19.399 --> 00:08:22.680 Yeah, it's hierarchical like folders and files. Get ant type 179 00:08:22.720 --> 00:08:27.120 shows you the kinds of objects in there. Directory, symbolic link, token, 180 00:08:27.399 --> 00:08:32.559 process thread, lots more directory objects build the hierarchy and the. 181 00:08:32.519 --> 00:08:35.399 Source mentions the anti object PowerShell drive. 182 00:08:35.559 --> 00:08:38.080 Right that lets you browse this hidden name space using 183 00:08:38.080 --> 00:08:41.519 familiar commands like LS or CD. It's a fantastic way 184 00:08:41.559 --> 00:08:42.080 to explore. 185 00:08:42.320 --> 00:08:46.120 Very cool. And one specific directory gets called out Base 186 00:08:46.279 --> 00:08:48.759 named objects. Why is that one special? 187 00:08:48.919 --> 00:08:51.639 Ah? Base Named objects or B and O. That's the 188 00:08:51.679 --> 00:08:55.559 standard place where different processes potentially running as different users 189 00:08:55.720 --> 00:08:58.799 can create named kernel objects that they can then share. 190 00:08:58.720 --> 00:09:01.559 So for interprocess community sharing resources. 191 00:09:01.600 --> 00:09:04.000 Exactly, if you want two different programs to easily find 192 00:09:04.039 --> 00:09:06.399 and use the same kernel object like a mutex or 193 00:09:06.440 --> 00:09:08.200 an event, putting it in B and O is the 194 00:09:08.200 --> 00:09:10.080 common way to do it. It's the public square for 195 00:09:10.159 --> 00:09:11.200 named kernel objects. 196 00:09:11.279 --> 00:09:14.519 Okay, shared resources go there makes sense. Now back to 197 00:09:14.600 --> 00:09:18.559 system calls. The deep dive mentiones NT and ZW prefixes. 198 00:09:18.840 --> 00:09:21.039 Is there a big difference for us calling. 199 00:09:20.799 --> 00:09:25.320 From user mode? Not really the sources they're mostly interchangeable 200 00:09:25.360 --> 00:09:29.720 from our perspective, and crete mutant ZW crete mutant. They 201 00:09:29.759 --> 00:09:32.039 generally do the same thing when called from an application. 202 00:09:32.360 --> 00:09:35.320 Okay, so just note they signal a system call, right. 203 00:09:35.200 --> 00:09:37.840 And they usually follow that verb noun pattern too, like 204 00:09:38.000 --> 00:09:40.279 create followed by the object type mutant. 205 00:09:40.399 --> 00:09:44.480 Got it. The source also mentions unicodestring structures for parameters, 206 00:09:44.600 --> 00:09:47.080 especially names. What's important about those? 207 00:09:47.559 --> 00:09:51.159 So many system calls take names using this Unicodes string structure. 208 00:09:51.399 --> 00:09:53.600 It's not just a pointer to the characters. It also 209 00:09:53.600 --> 00:09:57.919 includes the strings current length, invites, and the buffer's maximum. 210 00:09:57.399 --> 00:09:59.000 Size self describing strings. 211 00:09:59.120 --> 00:10:01.919 Yeah, and crucial, the length is just the characters used, 212 00:10:02.000 --> 00:10:04.799 not including a null terminator. In fact, you can have 213 00:10:04.919 --> 00:10:07.720 null characters inside object names at this level. 214 00:10:07.840 --> 00:10:10.039 Really, that seems like it could cause problems. 215 00:10:10.279 --> 00:10:14.279 It can mishandling these counted strings versus null terminated strings 216 00:10:14.279 --> 00:10:16.919 has definitely been a source of security bugs over the years. 217 00:10:17.279 --> 00:10:19.000 It uses UCS two encoding. 218 00:10:19.039 --> 00:10:22.200 By the way, good detail. Okay, so a system call runs, 219 00:10:22.360 --> 00:10:27.159 it needs to report back success, failure, what happened. That's 220 00:10:27.159 --> 00:10:28.639 where anti status codes come in. 221 00:10:28.639 --> 00:10:32.320 Exactly, and status codes are the standard return values. They 222 00:10:32.360 --> 00:10:33.559 tell you the outcome, and. 223 00:10:33.480 --> 00:10:36.000 They're more than just error or okay, oh yeah. 224 00:10:36.279 --> 00:10:39.279 The source breaks down the structure. There's a severity level 225 00:10:39.759 --> 00:10:44.279 success info, warning, error, a facility code telling you which 226 00:10:44.279 --> 00:10:47.600 part of the system generated the status like default debugger 227 00:10:47.720 --> 00:10:50.720 win thirty two, and the specific status code number. 228 00:10:50.840 --> 00:10:52.600 So lots of context. 229 00:10:52.200 --> 00:10:55.360 Tons and get end status in the PowerShell module lets 230 00:10:55.360 --> 00:10:57.639 you look up these codes, get the symbolic name and 231 00:10:57.679 --> 00:11:00.320 the message text. Super useful for debugs. 232 00:11:00.320 --> 00:11:03.559 And PowerShell itself often turns these into exceptions. 233 00:11:03.559 --> 00:11:06.559 We see right when a PowerShell command wraps a system 234 00:11:06.559 --> 00:11:09.240 call and gets an error and sisteris it often surfaces 235 00:11:09.240 --> 00:11:11.360 that as a dot net exception. The example of get 236 00:11:11.480 --> 00:11:13.360 ent directory on a non existent. 237 00:11:13.039 --> 00:11:15.759 Path gives that object name not found exception. 238 00:11:15.480 --> 00:11:17.600 Yep, and you can take the error code from that exception, 239 00:11:17.720 --> 00:11:20.200 feed it to get end status and get the underlying 240 00:11:20.200 --> 00:11:23.240 into status info. It shows how PowerShell bridges that low 241 00:11:23.320 --> 00:11:25.600 level kernel world with the managed dot net. 242 00:11:25.519 --> 00:11:31.320 World neat connection. Okay, next topic, object handles. User applications 243 00:11:31.399 --> 00:11:35.279 don't touch kernel objects directly. They use these handles as 244 00:11:35.519 --> 00:11:36.440 like tickets. 245 00:11:36.600 --> 00:11:40.720 Precisely, when you successfully create or open a kernel object 246 00:11:40.879 --> 00:11:44.200 via a system call, the kernel gives your process back 247 00:11:44.240 --> 00:11:46.720 a handle. Think of it as an index number into 248 00:11:46.720 --> 00:11:48.559 your process's private handle table. 249 00:11:48.600 --> 00:11:51.000 And what's in that handle table entry Three key things. 250 00:11:51.399 --> 00:11:54.600 The handle number itself, the access rights that were granted 251 00:11:54.600 --> 00:11:57.799 to your process for that object like read, write, synchronize, 252 00:11:58.080 --> 00:12:00.919 and critically a pointer to the action object down in 253 00:12:01.000 --> 00:12:01.679 kernel memory. 254 00:12:01.840 --> 00:12:05.840 So when my app uses that handle later, say, to 255 00:12:06.000 --> 00:12:07.159 read from a file. 256 00:12:06.960 --> 00:12:09.679 Object, it passes the handle number in another system call. 257 00:12:10.080 --> 00:12:12.279 The kernel uses that number to look up the entry 258 00:12:12.279 --> 00:12:14.919 in your process as handle table. Then it does vital 259 00:12:15.000 --> 00:12:17.759 checks like what First, it checks if the access you're 260 00:12:17.759 --> 00:12:21.399 requesting now, say read access is allowed by the access 261 00:12:21.480 --> 00:12:24.679 rights granted when the handle was created stored in the table. Second, 262 00:12:24.759 --> 00:12:26.720 it checks if the handle actually points to the right 263 00:12:26.759 --> 00:12:29.320 type of object trying to read from a mutex handle 264 00:12:29.360 --> 00:12:30.120 that's going to fail. 265 00:12:30.480 --> 00:12:33.759 Makes sense, access check and type check. Secure way to 266 00:12:33.799 --> 00:12:39.159 manage things, which brings us to access masks those granted 267 00:12:39.240 --> 00:12:39.799 rights right. 268 00:12:39.840 --> 00:12:42.799 The permissions granted are stored as a thirty two bit 269 00:12:42.960 --> 00:12:46.159 number called an access mask. It's a bitfield. Different bits 270 00:12:46.240 --> 00:12:48.039 mean different permissions. 271 00:12:47.480 --> 00:12:50.080 And it's specific to the object type largely. 272 00:12:50.200 --> 00:12:54.200 Yes, the top sixteen bits are generally type specific. So 273 00:12:54.440 --> 00:12:57.279 a file object's access mask will have bits for things 274 00:12:57.320 --> 00:13:00.559 like read data, write data, a pen data, while a 275 00:13:00.600 --> 00:13:04.200 thread object will have bits for terminate, suspend, resume, set information, 276 00:13:04.360 --> 00:13:04.679 and so. 277 00:13:04.720 --> 00:13:08.879 On, granular permissions tailored to the object. The source then 278 00:13:08.960 --> 00:13:12.799 shows duplicating handles with copynt object. Why would you do that? 279 00:13:12.960 --> 00:13:16.159 Copy anti object lets you duplicate an existing handle. You 280 00:13:16.159 --> 00:13:18.320 can just make an identical copy or and this is useful. 281 00:13:18.360 --> 00:13:20.759 You can request different access rights for the new handle. 282 00:13:20.919 --> 00:13:23.600 Ah, so you could create a less privileged version of 283 00:13:23.600 --> 00:13:24.639 a handle exactly. 284 00:13:24.720 --> 00:13:26.720 Maybe you have a handle with full access, but you 285 00:13:26.759 --> 00:13:29.000 want to pass a handle to another part of your 286 00:13:29.039 --> 00:13:32.039 code or another process that only has a query access. 287 00:13:32.360 --> 00:13:35.279 Duplicating the handle with a restricted desired access mask is 288 00:13:35.279 --> 00:13:35.799 how you do that. 289 00:13:36.200 --> 00:13:40.360 Smart and compare and object checks if two handles point 290 00:13:40.399 --> 00:13:42.840 to the same actual kernel object. 291 00:13:42.519 --> 00:13:45.840 Yep, even if they have different access rights. Compare end 292 00:13:45.840 --> 00:13:48.799 to object tells you if they're ultimately referencing the same 293 00:13:48.840 --> 00:13:49.879 thing done in the kernel. 294 00:13:50.519 --> 00:13:54.080 Cool. What about that protect from close attribute sounds obvious? 295 00:13:54.240 --> 00:13:56.440 It is what it sounds like. If you set that 296 00:13:56.559 --> 00:13:59.919 astribute on a handle, the system won't let it be closed. 297 00:14:00.279 --> 00:14:03.919 Palls to close handle will fail with status handle not closeable. 298 00:14:04.000 --> 00:14:06.519 Why to keep a critical handle alive? 299 00:14:06.840 --> 00:14:10.000 Could be maybe you need to guarantee a resource stays 300 00:14:10.000 --> 00:14:13.440 accessible and don't want some stray code closing the handle prematurely. 301 00:14:13.519 --> 00:14:17.519 Okay. The deep dive then talks about enquery information object 302 00:14:17.799 --> 00:14:21.480 and end set information object, sort of generic get and 303 00:14:21.519 --> 00:14:23.000 set for object data. 304 00:14:23.120 --> 00:14:25.720 That's the idea. Instead of having dozens of specific system 305 00:14:25.759 --> 00:14:28.399 calls for every little piece of info about every object type, 306 00:14:28.480 --> 00:14:30.759 the kernel provides these general purpose calls. 307 00:14:30.759 --> 00:14:31.440 How do they work? 308 00:14:31.639 --> 00:14:34.399 You give them the handle, an information class number that 309 00:14:34.399 --> 00:14:37.039 specifies what data you want, and a buffer to put 310 00:14:37.039 --> 00:14:39.559 the data in for query or get from for set. 311 00:14:39.600 --> 00:14:42.440 And how do you know the right information class number? Ah? 312 00:14:42.519 --> 00:14:46.000 Well, get nt object information class can list the known 313 00:14:46.039 --> 00:14:49.360 ones for an object type, but as the source notes, 314 00:14:49.559 --> 00:14:52.759 not all classes are officially documented. Sometimes it involves a 315 00:14:52.759 --> 00:14:54.919 bit of digging or experimentation, like. 316 00:14:54.960 --> 00:14:58.720 Figuring out database fields. The example with querying process info 317 00:14:58.840 --> 00:15:01.919 and getting buffer too small that highlights needing the right 318 00:15:01.960 --> 00:15:03.639 buffer size exactly. 319 00:15:03.799 --> 00:15:05.759 You often have to figure out how much space the 320 00:15:05.799 --> 00:15:08.600 information needs. Sometimes you call it once to get their 321 00:15:08.639 --> 00:15:11.840 required size, allocate a buffer, then call it again, or 322 00:15:12.080 --> 00:15:14.240 just guess with the like parameter until it works. 323 00:15:14.399 --> 00:15:18.240 Got it okay? Quickly. Touching on device objects and symbolic 324 00:15:18.279 --> 00:15:20.080 links in the OMNS. How do they fit in? 325 00:15:20.360 --> 00:15:23.600 Device objects represent hardware or virtual devices. You can see 326 00:15:23.600 --> 00:15:27.720 them under nty object. Device Symbolic links like system root 327 00:15:27.799 --> 00:15:31.159 are just pointers or aliases to other paths in the OMNS. 328 00:15:31.320 --> 00:15:33.279 So when I open see windowsnoepad dot. 329 00:15:33.240 --> 00:15:36.360 Ex, the system uses symbolic links C likely points to 330 00:15:36.399 --> 00:15:39.120 a device hard disc volume X path. Windows might involve 331 00:15:39.159 --> 00:15:41.519 system route to resolve the path down to the actual 332 00:15:41.559 --> 00:15:45.480 file object, passing through the device object representing the disk volume, 333 00:15:45.720 --> 00:15:47.360 all involving the object manager. 334 00:15:47.679 --> 00:15:54.759 Path resolution involves the OMMS. Okay, next, process and thread 335 00:15:54.840 --> 00:15:56.360 manager key security points. 336 00:15:56.720 --> 00:15:59.039 Processes and threads are the things that run code, and 337 00:15:59.039 --> 00:16:02.799 they are securable objects themselves. They have security descriptors, so you. 338 00:16:02.799 --> 00:16:05.120 Need permission to say terminate another process. 339 00:16:05.200 --> 00:16:08.919 Absolutely and importantly you generally can't open a process or 340 00:16:09.000 --> 00:16:12.320 thread just by knowing its name. You need its unique 341 00:16:12.600 --> 00:16:17.679 process ID PID or thread id TID helps prevent arbitrary 342 00:16:17.679 --> 00:16:19.799 interference just based on names. 343 00:16:19.879 --> 00:16:23.200 Right, need the specific ID. Okay. Memory management in sections 344 00:16:23.320 --> 00:16:25.159 sounds like fertile ground for security issues. 345 00:16:25.200 --> 00:16:27.919 Definitely. Sections are blocks of memory that can be shared 346 00:16:27.960 --> 00:16:31.720 between processes. New antisection creates one add in section, maps 347 00:16:31.720 --> 00:16:33.759 it into a process's address space. 348 00:16:33.519 --> 00:16:35.200 And you control permissions on that memory. 349 00:16:35.320 --> 00:16:38.559 Yes crucial. You specify protection like read only read write, 350 00:16:38.600 --> 00:16:42.039 execute read write. The kernel enforces these. Trying to map 351 00:16:42.080 --> 00:16:45.440 a section with incompatible permissions fails, as the example. 352 00:16:45.080 --> 00:16:48.879 Showed and shared ritable sections. The source mentions CVE twenty 353 00:16:48.960 --> 00:16:51.840 nineteen Uro nine, four to three. That sounds bad. 354 00:16:52.080 --> 00:16:55.639 It was a privileged process shared a section. A lower 355 00:16:55.639 --> 00:16:58.840 privileged process could map it as writable modified data the 356 00:16:58.840 --> 00:17:03.120 privileged process trusted and potentially get code execution. Big problem. 357 00:17:03.360 --> 00:17:07.039 Yikes. How would you even find such shared sections? 358 00:17:07.279 --> 00:17:09.680 The source shows using get and handle to look at 359 00:17:09.720 --> 00:17:13.759 all handles and processes, filtering for section objects, and using 360 00:17:13.799 --> 00:17:16.400 test n access mask to see if any have right 361 00:17:16.519 --> 00:17:21.000 access section map right or potentially dangerous combinations like section 362 00:17:21.119 --> 00:17:25.000 exten size. You'd compare handles between a high privilege and 363 00:17:25.039 --> 00:17:26.519 low privileged process, so. 364 00:17:26.440 --> 00:17:30.079 You can hunt for potentially risky sharing configurations and even 365 00:17:30.119 --> 00:17:30.599 fuzz them. 366 00:17:30.720 --> 00:17:33.200 Yeah, if you find a writable shared section, you could 367 00:17:33.279 --> 00:17:36.240 use right anti virtual memory to poke at it, write 368 00:17:36.279 --> 00:17:39.039 unexpected data. See if you can crash or exploit the 369 00:17:39.079 --> 00:17:41.559 other process sharing it. Show in t section even gives 370 00:17:41.559 --> 00:17:43.319 you a x editor GUI for it. 371 00:17:43.359 --> 00:17:46.599 Wow. The big takeaway seems to be writable and executable 372 00:17:46.599 --> 00:17:48.039 memory is inherently dangerous. 373 00:17:48.160 --> 00:17:51.799 Extremely that combo is classic malware territory for code injection. 374 00:17:52.279 --> 00:17:54.480 He's very careful justification if you used at all? 375 00:17:54.880 --> 00:17:57.960 Okay, shifting up a level. Now user mode applications and 376 00:17:58.119 --> 00:18:02.279 Win thirty two APIs. This is where most developers live. Right, 377 00:18:02.319 --> 00:18:03.799 how does this relate to the kernel stuff? 378 00:18:03.960 --> 00:18:06.880 Right? Most apps don't call nt create file directly. They 379 00:18:06.920 --> 00:18:09.960 call the Win thirty two API function create file. These 380 00:18:10.000 --> 00:18:14.240 Win thirty two APIs are the documented stable interface for applications, 381 00:18:14.240 --> 00:18:17.799 the layer of abstraction exactly. They provide functions for everything files, 382 00:18:17.880 --> 00:18:21.079 Windows network registry under the hood. Many of these WIN 383 00:18:21.160 --> 00:18:23.920 thirty two functions eventually translate into one or more and 384 00:18:24.200 --> 00:18:26.640 or ZW system calls to the kernel to do the 385 00:18:26.680 --> 00:18:29.599 actual work. Understanding that translation is key, So. 386 00:18:29.559 --> 00:18:31.920 Win thirty two is the friendly face. System calls are 387 00:18:31.920 --> 00:18:35.599 the engine room. Okay. DLL imports and API sets what 388 00:18:35.680 --> 00:18:36.039 are these? 389 00:18:36.279 --> 00:18:40.759 Ds? Dynamic link libraries are shared code libraries. Apps import 390 00:18:40.759 --> 00:18:43.400 functions from them. Get Win thirty two module import. Let's 391 00:18:43.440 --> 00:18:46.519 you see which functions and app uses from which DLLs. 392 00:18:46.160 --> 00:18:49.079 Useful for understanding dependencies and API. 393 00:18:48.799 --> 00:18:51.359 Sets Introduced in Windows seven. They're like virtual DLLs, and 394 00:18:51.400 --> 00:18:55.000 app might link against apm's wind core process threads LANs 395 00:18:55.000 --> 00:18:57.920 onesaushal on zero dot dll instead of directly against kernel 396 00:18:57.960 --> 00:19:01.240 thirty two dot dll or at VAP thirty two dot dll. 397 00:19:01.480 --> 00:19:04.359 It decouples the app from the exact DLLLL Providing the 398 00:19:04.359 --> 00:19:07.559 function makes it easier for Microsoft to refactor things behind 399 00:19:07.559 --> 00:19:10.799 the scenes without breaking apps. Get n TAPA set. Let's 400 00:19:10.799 --> 00:19:14.319 you see which real DLL actually backs a specific API 401 00:19:14.440 --> 00:19:16.519