1 00:00:05,000 --> 00:00:09,080 First off, I want to thank everybody for being here. I know it's late in the day and having 2 00:00:09,080 --> 00:00:11,980 everybody here is what makes it possible. So I really just appreciate y'all being here. 3 00:00:12,620 --> 00:00:17,640 So now we're design of using legacy Microsoft transports in session architecture. That's 4 00:00:17,640 --> 00:00:22,340 what this is going to be about. But a little bit about me is first and foremost I'm a principal 5 00:00:22,340 --> 00:00:26,080 red teamer at Equinix. And I know we have a lot of Equinix people here. So I definitely 6 00:00:26,080 --> 00:00:32,200 want to give a shout out and definitely thank the support I get from them. Also, I was a 7 00:00:32,200 --> 00:00:36,240 student at Sam Houston State University, computer science. They have a great department and 8 00:00:36,240 --> 00:00:40,440 several faculty, yeah, several faculty are goons here and have been for a really long 9 00:00:40,440 --> 00:00:46,160 time. So I definitely appreciate them. I want to reach out to their shout out to Black Birch. 10 00:00:46,540 --> 00:00:51,720 They do great pen testing consulting. You know, so that's kind of my background is I do a 11 00:00:51,720 --> 00:00:55,740 lot of red teaming, consulting, coding, developing, all that sort of stuff. And 12 00:00:55,740 --> 00:00:56,060 personally, I'm a big fan of Equinix. I'm a big fan of Equinix. I'm a big fan of Equinix. 13 00:00:56,060 --> 00:01:03,080 Primarily, I like to stick to Python or C++. And in this case, we're going to be looking at, 14 00:01:03,140 --> 00:01:08,920 you know, some of the challenges that red teamers face. Because we need to compromise endpoints 15 00:01:08,920 --> 00:01:14,020 and networks. And then we need to, you know, exfiltrate data. But the thing about the red 16 00:01:14,020 --> 00:01:20,540 teaming is that everything is in scope. And nobody knows that we're coming. And so remaining 17 00:01:20,540 --> 00:01:25,900 undetected is a key part. Or at least maintaining our access. If we're detected, the gig is kind 18 00:01:25,900 --> 00:01:30,480 of up. Especially being, you know, not a legit bad guy. Because you really only get one chance. 19 00:01:30,720 --> 00:01:36,520 Once the blue teamers know about it, it's kind of game over. But anyway, so if we, you know, use 20 00:01:36,520 --> 00:01:42,060 like traditional frameworks to suffer a C2, that's great. We definitely want to do that. But 21 00:01:42,060 --> 00:01:46,760 what if those channels are compromised? And what are the key things that those things do? They 22 00:01:46,760 --> 00:01:52,640 reach out to your C2 server. Even if it's over an extended period of time. If that's ever picked 23 00:01:52,640 --> 00:01:55,880 up, then you kind of lose everything. So the focus on this is, you know, we're going to be 24 00:01:55,880 --> 00:02:03,680 looking at implementing, you know, multiple, you know, TTPs at different levels. And provide 25 00:02:03,680 --> 00:02:09,000 enough functionality to allow us to regain access to machines where we maybe have lost it. Or 26 00:02:09,000 --> 00:02:14,380 just to simply do something without having any sort of the indicators that would result from a 27 00:02:14,380 --> 00:02:23,860 process reaching out to the Internet or another server for tasking. Just some prerequisite 28 00:02:23,860 --> 00:02:25,860 high level overview. We do abuse some of the things that we've talked about in the past. We 29 00:02:25,860 --> 00:02:30,420 do abuse some of the things within Windows. And so I'm going to be covering at a high level 30 00:02:30,980 --> 00:02:36,200 Windows like sessions and their stations, tokens, things like that. But then also there's some 31 00:02:36,200 --> 00:02:40,420 other protocols that we're going to cover. It's pretty simple. The first thing we're going to 32 00:02:40,420 --> 00:02:46,940 look at is, you know, the different sessions. When a user logs into a Windows machine, they're 33 00:02:46,940 --> 00:02:50,780 going to have their own log on session. And so if there's, you know, terminal services or 34 00:02:50,780 --> 00:02:55,060 multiple users can log in over RDP as an example, then you'll have a different session for each 35 00:02:55,060 --> 00:02:55,680 one of those users. 36 00:02:55,860 --> 00:03:04,020 So what if we have a service like an implant that's running in session zero and we want to create a 37 00:03:04,020 --> 00:03:09,720 process inside of another user's session? Maybe a session is just logged in. Can we do that from 38 00:03:09,720 --> 00:03:15,620 session zero? Which is basically where all the services log in or where they're running. So 39 00:03:15,620 --> 00:03:19,520 that's going to be one of the main topics that we talk about today is how can we achieve this and 40 00:03:19,520 --> 00:03:25,080 what are the best ways to do it and what is the what are our abilities to detect it as well? 41 00:03:27,060 --> 00:03:33,940 Which brings me to a framework that I've been working on. As soon as I get back to my room, I'll release the code on my GitHub. 42 00:03:34,120 --> 00:03:40,860 So it will be available. It's written in C++. There's a command line agent but then also I've been 43 00:03:40,860 --> 00:03:46,920 implementing a graphical front end using I'm GUI. So that will be available. But just kind of a 44 00:03:46,920 --> 00:03:55,840 high-level overview of this is that, again, it's for long-term persistent access in case we need to recover it. But the main thing is it's 45 00:03:55,860 --> 00:04:01,620 is that it doesn't reach out to a C2 server. It sits there on the endpoint running and 46 00:04:01,620 --> 00:04:09,640 then it waits for tasking. So we abused some other different protocols within it to keep 47 00:04:09,640 --> 00:04:13,940 the network association away from the process. And we're going to go through that in more 48 00:04:13,940 --> 00:04:19,080 detail. But the way that we're doing it is that we're supporting or the main thing is 49 00:04:19,080 --> 00:04:25,520 that we wanted to support the ability to implement different types of transports. So what if 50 00:04:25,520 --> 00:04:32,780 a specific transport only allows ingress? We still want this functionality. So there's a 51 00:04:32,780 --> 00:04:38,200 custom messaging protocol that's implemented and the main takeaways is that an operator can 52 00:04:38,200 --> 00:04:42,560 issue a task and the task is going to be sent to the implant and it's going to do something. 53 00:04:43,980 --> 00:04:50,800 And the way that that is delivered is through a route. Notifications, those are the 54 00:04:50,800 --> 00:04:55,400 responses. And those are optional. So that's one of the key things is that you 55 00:04:55,400 --> 00:05:05,940 don't have to get a response from a task. So again, bidirectional transports think of stateful 56 00:05:05,940 --> 00:05:12,260 protocols such as TCP. You have your SYN, your SYNAC and your ACK. You have transmission back 57 00:05:12,260 --> 00:05:16,440 and forth between the two. But then in a unidirectional you would have stateless protocols 58 00:05:16,440 --> 00:05:24,060 such as UDP or in the main one that we're going to use now, there are mail slots. And so those 59 00:05:25,400 --> 00:05:30,980 are data being sent to the implant versus back and forth. So this actually gives us a lot of 60 00:05:30,980 --> 00:05:37,380 flexibility in that we can send a task off to a machine that's implanted and then not receive a 61 00:05:37,380 --> 00:05:42,100 response at all if we don't care about it. But if we do receive a response, we can have it sent 62 00:05:42,100 --> 00:05:46,760 back to a different machine over a different transport altogether. So we have a lot of 63 00:05:46,760 --> 00:05:52,960 flexibility and we're not tied to anything specific. Really anything that, you know, any sort 64 00:05:52,960 --> 00:05:55,180 of protocol that, you know, uses the network. 65 00:05:55,400 --> 00:06:03,440 We can implement as a transport layer. So tasks. This is like one of the key components. 66 00:06:03,640 --> 00:06:09,960 So again, these are inbound. So it's a message being received by the implant. The implant then 67 00:06:09,960 --> 00:06:15,040 does something based on whatever you're tasking it to do. Create a process in a user's logon 68 00:06:15,040 --> 00:06:20,960 session. Or it creates a user, which obviously isn't very stealthy. But again, it's an option. 69 00:06:22,300 --> 00:06:25,380 So one of the questions is since the messaging protocol, you know, it's not going to be able to 70 00:06:25,400 --> 00:06:29,200 do that. Is it coupled from the transport layer? How can we deliver a response, especially when 71 00:06:29,200 --> 00:06:36,700 considering a transport is unidirectional? This is where routes come into play. So within an 72 00:06:37,940 --> 00:06:43,500 obligato implant, you have routes which describe a destination. And this would include all the 73 00:06:43,500 --> 00:06:48,460 information that's required to actually, you know, send that information off to it. So for 74 00:06:48,460 --> 00:06:54,760 instance, a mail slot, we would include the NetBIOS name of the machine. And then the name of 75 00:06:54,760 --> 00:06:55,340 the mail slot. 76 00:06:56,480 --> 00:06:58,760 I'm not going to spend too much time on this, because we're going to get to it. We're going to have 77 00:06:58,760 --> 00:07:03,280 demos, which is probably going to clear a lot of this up. But the main thing is that each route entry 78 00:07:03,280 --> 00:07:12,300 is mapped to a unique identifier. And this is used in route lookups. And then the notifications is 79 00:07:12,300 --> 00:07:18,080 the last piece. So if you send off a task and you want to have, like, a response, you want to know 80 00:07:18,080 --> 00:07:23,560 if it was executed successfully or what happened, or just received data back, then you can say, hey, 81 00:07:23,620 --> 00:07:24,440 send me a notification. 82 00:07:24,440 --> 00:07:31,520 And if you send a notification over this transport to this destination. So I want to talk about mail 83 00:07:31,520 --> 00:07:38,660 slots a little bit. Why do we want to use mail slots? Well, here's a quote from Microsoft, remote 84 00:07:38,660 --> 00:07:42,920 mail slot protocol is a simple, unreliable, insecure and unidirectional interprocess communication 85 00:07:42,920 --> 00:07:48,100 protocol between client and the server. A mail slot is represented locally on the server as a 86 00:07:48,100 --> 00:07:53,460 file. So you read that, and you're like, well, maybe we shouldn't use it. But there's actually a 87 00:07:53,460 --> 00:07:54,420 lot of advantages to it. So you can use the application as a protocol. And you can use it as a 88 00:07:54,440 --> 00:08:01,320 to using mail slots. So one thing about a mail slot is that the traffic isn't associated 89 00:08:01,320 --> 00:08:06,680 with the process. So normally, and we're going to demo this later, but normally if you have 90 00:08:06,680 --> 00:08:11,220 network activity through one way or another, you're going to have that associated with 91 00:08:11,220 --> 00:08:16,160 the process. So in this case, it doesn't. Which is really good for us because, again, 92 00:08:16,160 --> 00:08:28,460 we're not creating the path of, I'm sorry, we're, the process isn't associated with network 93 00:08:28,460 --> 00:08:33,620 activity. So as offenders dig into this, we're trying to break those process chain of events and 94 00:08:33,620 --> 00:08:40,560 the network activity. So this isn't going to be associated. Also, it's a very legacy. So it 95 00:08:40,560 --> 00:08:45,460 supports Windows 2000 API. So we could potentially use this on a wide range of machines. 96 00:08:48,080 --> 00:08:56,060 One key thing if you go to implement this in development is that you have to use the net BIOS 97 00:08:56,060 --> 00:09:03,740 name. You can't use the IP address. Even if you look in Wireshark and you see that the packets are 98 00:09:03,740 --> 00:09:09,120 being sent and they're being delivered to the endpoint, they're not processed correctly. So the 99 00:09:09,120 --> 00:09:14,820 very big thing about mail slots is that you have to use the net BIOS name. Otherwise, it will 100 00:09:14,820 --> 00:09:16,140 fail, but you'll see the network track. 101 00:09:16,160 --> 00:09:23,920 But it won't be delivered to your process for processing. This is extremely a legacy 102 00:09:23,920 --> 00:09:29,560 protocol. So authentication isn't required nor is it supported. I guess that was left to people 103 00:09:29,560 --> 00:09:34,240 that implemented the protocol themselves. So that's going to bring me to my first demo. 104 00:09:47,700 --> 00:09:49,260 I hope. 105 00:09:51,140 --> 00:09:51,440 . 106 00:10:05,680 --> 00:10:07,340 Uh-oh. 107 00:10:08,400 --> 00:10:09,800 . 108 00:10:09,800 --> 00:10:11,020 . 109 00:10:15,280 --> 00:10:16,680 . 110 00:10:16,680 --> 00:10:19,020 . 111 00:10:27,640 --> 00:10:29,040 . 112 00:10:31,280 --> 00:10:32,680 . 113 00:10:32,680 --> 00:10:34,080 . 114 00:10:34,080 --> 00:10:34,100 . 115 00:10:34,100 --> 00:10:34,120 . 116 00:10:39,600 --> 00:10:41,000 . 117 00:10:41,020 --> 00:10:42,800 . . 118 00:10:42,800 --> 00:10:49,180 Okay. Well, it looks like the videos aren't seeing down, so we're going to have to skip the demos. 119 00:10:50,880 --> 00:10:51,440 . . 120 00:10:51,440 --> 00:11:06,960 . Well, Demo 1 was basically to show the usage of the tool and using mail slots to task a remote agent. 121 00:11:09,280 --> 00:11:10,400 . . 122 00:11:10,400 --> 00:11:15,380 The demos are available for download, so you can download those and check it if you want. 123 00:11:16,540 --> 00:11:20,600 But in the last demo, if we could have seen it, what we would have seen is one machine 124 00:11:20,600 --> 00:11:25,360 sending a task to another one that was implanted, and then it doing something. 125 00:11:27,660 --> 00:11:32,980 Whenever I was creating my DEF CON submission, I came across an article with this quote, 126 00:11:33,140 --> 00:11:36,720 and it was the first link after searching mail slots. 127 00:11:37,460 --> 00:11:38,880 And it gave me pause. 128 00:11:38,880 --> 00:11:46,700 I was thinking, hmm, so with the release of Windows 11 insider preview build, we have 129 00:11:46,700 --> 00:11:48,980 started disabling the remote mail slot protocol by default. 130 00:11:50,240 --> 00:11:54,340 This is a precursor to deprecation and eventual removal from Windows. 131 00:11:54,740 --> 00:11:59,080 You aren't using this extremely legacy protocol unless you're also using the deprecated and 132 00:11:59,080 --> 00:12:01,340 disabled by default SMBV1 protocol. 133 00:12:01,780 --> 00:12:05,520 So 99.97% of you have nothing to worry about. 134 00:12:05,780 --> 00:12:07,360 This was a principal program manager. 135 00:12:07,600 --> 00:12:08,180 Okay. 136 00:12:09,320 --> 00:12:14,260 So it gave me pause because I was thinking, kind of like Byte Leader said in his talk 137 00:12:14,260 --> 00:12:16,180 this morning, is, like, am I the idiot? 138 00:12:16,380 --> 00:12:17,380 Am I a dumb dumb? 139 00:12:17,980 --> 00:12:22,600 Did I somehow configure all these default Windows boxes with SMBV1 enabled? 140 00:12:23,340 --> 00:12:28,120 So I checked, and that would bring me to the demo two. 141 00:12:28,840 --> 00:12:29,320 . 142 00:12:30,600 --> 00:12:38,580 And let me just illustrate verbally, the best I can, in demo two, we were going to 143 00:12:38,580 --> 00:12:47,180 look at actually showing through PowerShell that on Windows 11, 10 and Windows Server 2016 144 00:12:48,420 --> 00:12:56,720 that SMB1 not only wasn't enabled but on the server even it wasn't installed. And then it 145 00:12:56,720 --> 00:13:08,180 worked. So, yeah. Sorry about the demos. I believe we also looked at in Wireshark that 146 00:13:08,180 --> 00:13:17,160 we were actually using the mail slot protocol. They're being delivered over NetBIOS and SMB. So, 147 00:13:17,280 --> 00:13:23,820 even though SMB1 was disabled, our packets were still sent to the endpoints and they were 148 00:13:23,820 --> 00:13:32,340 processed and the task was carried out. So, I'm not poking fun at whoever said this, but the 149 00:13:32,340 --> 00:13:37,900 thing is, is that as a defender, wanting to potentially block, you know, potentially block 150 00:13:38,180 --> 00:13:43,520 this activity or ensure that your environment isn't susceptible to communication over this 151 00:13:44,060 --> 00:13:49,740 medium, be careful when you come across this article and what the assumptions we draw from it 152 00:13:49,740 --> 00:13:55,700 because every single link was either this one or one pointing to it. 153 00:14:01,660 --> 00:14:01,980 Okay. 154 00:14:11,180 --> 00:14:11,940 . 155 00:14:14,100 --> 00:14:14,860 S391. 156 00:14:16,920 --> 00:14:18,440 In where? 157 00:14:19,920 --> 00:14:20,300 . 158 00:14:22,580 --> 00:14:23,340 No. 159 00:14:24,280 --> 00:14:25,040 . 160 00:14:27,720 --> 00:14:28,480 . 161 00:14:33,240 --> 00:14:35,920 It's all good. It's all good. 162 00:14:36,080 --> 00:14:37,460 . Yeah, VLC is open. 163 00:14:37,680 --> 00:14:38,160 . Yeah, VLC is open. 164 00:14:38,720 --> 00:14:40,880 Oh, it is, isn't it? 165 00:14:42,940 --> 00:14:43,380 . 166 00:14:44,040 --> 00:14:44,260 Hey. 167 00:14:45,500 --> 00:14:46,800 . There we go. 168 00:14:48,720 --> 00:14:49,800 . All right. 169 00:14:49,920 --> 00:14:52,000 . Thank you. 170 00:14:52,140 --> 00:14:56,140 . Well, let's just circle back then. 171 00:14:57,200 --> 00:14:58,740 . Hey, there we go. Awesome. 172 00:14:59,040 --> 00:15:02,060 . Thank you, whoever said that. Appreciate it. Thanks. 173 00:15:02,320 --> 00:15:07,680 . Okay. So, this is the tool. We're on a Windows 11 machine. We're 174 00:15:07,680 --> 00:15:11,640 configuring it to use a mail slot. This is the system that we're going to go ahead and target, 175 00:15:11,780 --> 00:15:17,060 Windows Server. We're just going to create a user. Not really worried about OPSEC at this point. We're 176 00:15:17,060 --> 00:15:25,080 just demoing the usage of it. So, we're going to create a user Defcon 31, appropriate, with a super 177 00:15:25,080 --> 00:15:32,100 secure password. We're going to execute it. Again, this was a mail slot. And then we're going to look 178 00:15:32,100 --> 00:15:33,920 and it was successful. 179 00:15:34,600 --> 00:15:35,000 . 180 00:15:38,500 --> 00:15:43,080 Defcon 31. Now, I want to pause really quick. I forgot to point out 181 00:15:44,300 --> 00:15:44,660 . 182 00:15:52,860 --> 00:15:58,820 So, you can see my mouse. So, you can see here, this is the target. So, over here, we created these 183 00:15:58,820 --> 00:16:03,920 different targets here. So, we have mail slot and UDP. These are the ones we're going to target. And so, 184 00:16:04,000 --> 00:16:04,980 this is what's being created. 185 00:16:05,000 --> 00:16:09,560 Selected. And so, in that case, it was a mail slot and it worked. 186 00:16:16,540 --> 00:16:20,600 Now, what we're going to do is that was the GUI. We're going to show off the command line usage 187 00:16:20,600 --> 00:16:26,940 to show that you have the same functionality. So, in this case, we created a mail slot listener. 188 00:16:27,260 --> 00:16:31,660 So, we have, like, the service running, you know, the implants running as a service on these 189 00:16:31,660 --> 00:16:34,460 different machines. But you can also use the command line agent 190 00:16:35,000 --> 00:16:40,140 to set up a listener if you want to receive a response or even set it up for tasking. So, 191 00:16:40,180 --> 00:16:43,080 in this case, we just want to receive a response. So, we set up a listener there. 192 00:16:44,060 --> 00:16:47,940 And then in this case, this is another key component that you don't really see within 193 00:16:47,940 --> 00:16:52,620 the GUI because it's done in the background. But the first thing that we have to do before 194 00:16:52,620 --> 00:16:58,020 we send a task when we run through response is that we have to send or we have to create a route. 195 00:16:58,340 --> 00:17:04,560 And so, in this case, we're targeting the Windows server. We're saying that this is, 196 00:17:05,000 --> 00:17:15,500 obligato is the mail slot. And we want to receive responses to this Windows 11 box with ob receive 197 00:17:15,500 --> 00:17:21,740 as the mail slot. So, basically, if we task the server and we ask for a response, 198 00:17:21,980 --> 00:17:26,360 here's where you can send it. And then we can reference this ID in subsequent tasking. 199 00:17:26,460 --> 00:17:31,060 And if that ID matches a route, then it's going to use that route for a response. 200 00:17:37,200 --> 00:17:42,220 So, in this case, we're going to add group membership. So, we're going to take that user 201 00:17:42,220 --> 00:17:47,300 that we created and we're going to add them to local administrators and we're asking to receive 202 00:17:47,300 --> 00:17:52,200 a response to our listener here. So, if all goes well, we're going to execute this. 203 00:17:52,840 --> 00:17:56,040 And then we'll see a response. And all of this is using mail slots. 204 00:18:02,420 --> 00:18:04,980 And remember, this is demo one. And demo two, we're going to 205 00:18:05,000 --> 00:18:23,920 be looking at whether or not SME is enabled. Okay. So it's successful. Okay. And that was 206 00:18:23,920 --> 00:18:34,980 that. Appreciate it. So I'm going to go ahead and cut at the end of the session. 207 00:18:35,000 --> 00:18:53,340 Because it's really just showing some other functionality. But for time's sake. And so what I want to do now is just show demo two. And this was after reading the message that Microsoft, you know, I think it's trying to download them each time. I'm just going to open up each one and let them queue. 208 00:19:18,580 --> 00:19:26,600 You know what's funny about this is I thought that the video route would be safer since I had to use multiple virtual machines and everything. But I think the live might have been better. 209 00:19:30,060 --> 00:19:33,680 All right. Let's try it again. Okay. So again, 210 00:19:35,000 --> 00:19:44,620 Going back to that message, SMBv1 has to be enabled in order to use mail slots. As we can see on this Windows 11 machine, SMBv1 protocol, stay disabled. 211 00:19:46,540 --> 00:19:52,240 Windows 10, SMBv1 protocol, stay disabled. 212 00:20:01,320 --> 00:20:02,200 Stay disabled. 213 00:20:08,780 --> 00:20:13,500 Now, just to kind of further demonstrate this, we're going to pull up Wireshark. 214 00:20:13,900 --> 00:20:17,800 I'm going to put in a little filter just so we kind of filter some stuff out. 215 00:20:17,920 --> 00:20:23,220 We're only going to see communication between the server and the endpoint where we're sending the tasks. 216 00:20:25,060 --> 00:20:26,560 We're going to pull up the GUI again. 217 00:20:33,100 --> 00:20:34,020 Create a local user. 218 00:20:44,080 --> 00:20:45,240 Really awesome password. 219 00:20:50,720 --> 00:20:52,140 Just want to make sure it's running. 220 00:20:53,840 --> 00:20:55,120 All right, now we see the traffic. 221 00:20:55,340 --> 00:21:01,580 So, we can see the NetBIOS traffic, and then we see the mail slot communication. 222 00:21:02,160 --> 00:21:04,140 And so, again, this was disabled. 223 00:21:04,140 --> 00:21:06,060 However, we do see the packets. 224 00:21:06,580 --> 00:21:08,140 We have the SMB headers here. 225 00:21:08,640 --> 00:21:09,840 SMBv1 is disabled. 226 00:21:10,200 --> 00:21:11,680 Yeah, we're still receiving these. 227 00:21:13,040 --> 00:21:18,700 And then, of course, there's, like we're saying, hey, create this local user along with this password. 228 00:21:19,620 --> 00:21:20,520 And it was successful. 229 00:21:21,600 --> 00:21:26,240 So, the main takeaway from this point is that, and I'm just going to queue this up. 230 00:21:26,340 --> 00:21:33,920 The main point for this is that we don't want to assume that SMB, or I'm sorry. 231 00:21:34,140 --> 00:21:40,600 Mail slots won't work within our environment just because we have SMBv2 disabled, or v1 disabled. 232 00:21:42,380 --> 00:21:43,980 So, that's the reason why I threw this in here. 233 00:21:48,040 --> 00:21:50,840 Next, we want to look at Windows logon session compromise. 234 00:21:51,000 --> 00:21:52,100 So, we have, like, a good transport. 235 00:21:52,460 --> 00:21:54,320 Again, you can use multiple transports. 236 00:21:54,320 --> 00:21:55,540 In this case, you know, mail slots. 237 00:21:55,740 --> 00:22:00,500 But the next thing we want to look at to provide functionality is we want to be able to compromise logon sessions. 238 00:22:00,920 --> 00:22:03,880 So, two key things within any engagement, really. 239 00:22:03,880 --> 00:22:07,580 Is that we're going to have, you know, objectives that we have to get to. 240 00:22:07,660 --> 00:22:12,540 Whether that's specific servers or information or, you know, users. 241 00:22:12,840 --> 00:22:16,020 There's going to be some sort of objective that, you know, we have to meet. 242 00:22:16,240 --> 00:22:20,900 And within that, a lot of the times what it's going to have is that we're going to have to elevate our permissions. 243 00:22:21,240 --> 00:22:23,180 And we're going to have to move laterally to other endpoints. 244 00:22:23,360 --> 00:22:25,700 And usually those two things play together. 245 00:22:26,140 --> 00:22:28,320 We're going to have, like, limited access. 246 00:22:28,560 --> 00:22:30,880 But then that's going to have admin access here. 247 00:22:31,240 --> 00:22:32,360 We're going to get to that one. 248 00:22:32,440 --> 00:22:33,380 There's going to be privileged users. 249 00:22:33,880 --> 00:22:39,740 You know, so that's kind of the game is that we elevate privileges by compromising other user sessions or credentials. 250 00:22:41,440 --> 00:22:46,860 So, the credential route is often through dumping credentials through LSAS. 251 00:22:47,100 --> 00:22:48,560 I'm sure everybody's familiar with that. 252 00:22:49,180 --> 00:22:52,160 Or LSA secrets, CAS credentials, et cetera. 253 00:22:53,240 --> 00:22:57,000 And then also logon sessions, which is another method. 254 00:22:57,580 --> 00:23:03,100 Which is basically us gaining code execution in the target user's window logon session. 255 00:23:03,100 --> 00:23:10,460 And just to kind of look back, remember that each logon session in Windows is now kind of isolated from each other. 256 00:23:11,580 --> 00:23:14,320 So, there's a few mainstream techniques for this. 257 00:23:16,380 --> 00:23:18,680 For gaining code execution in a logon session. 258 00:23:19,300 --> 00:23:25,240 One is execute code in a process already running in the logon session. 259 00:23:25,580 --> 00:23:28,860 Or we can open a handle to the process. 260 00:23:29,560 --> 00:23:30,420 Duplicate the token. 261 00:23:30,540 --> 00:23:31,840 And then we can use impersonation. 262 00:23:31,880 --> 00:23:32,500 Or we can just. 263 00:23:33,100 --> 00:23:33,880 You know, create a process. 264 00:23:35,600 --> 00:23:38,060 But here's the question that I want to ask. 265 00:23:38,120 --> 00:23:44,180 What if we want to create a process on demand inside a target user's logon session without 266 00:23:44,760 --> 00:23:46,680 executing code in it? 267 00:23:46,800 --> 00:23:49,660 Or opening a handle to another process? 268 00:23:50,160 --> 00:23:53,500 So, basically, we want to have all that, you know, functionality. 269 00:23:53,760 --> 00:23:59,520 But we don't want to touch other processes' tokens within an existing process of the session. 270 00:24:00,980 --> 00:24:02,500 So, one method is looking. 271 00:24:03,100 --> 00:24:04,280 We can use a task scheduler. 272 00:24:04,900 --> 00:24:07,020 This isn't the method we're using behind the scenes. 273 00:24:07,240 --> 00:24:08,280 This is just an example. 274 00:24:09,360 --> 00:24:13,000 And so, what we would do is we could create a scheduled task to run as a target user. 275 00:24:14,620 --> 00:24:17,180 We can set it to only run if the user's logged in. 276 00:24:17,300 --> 00:24:18,600 And then there's not a credential requirement. 277 00:24:19,120 --> 00:24:23,100 If we try to have it run whenever a user's logged in, then obviously you need credentials. 278 00:24:25,260 --> 00:24:31,220 The key thing on this is that when the process is created, it's going to be using the WinST0 279 00:24:31,220 --> 00:24:32,420 in default desktop. 280 00:24:33,100 --> 00:24:37,960 So, if your process has any sort of Windows associated with it, those will be displayed 281 00:24:37,960 --> 00:24:38,420 to the user. 282 00:24:38,640 --> 00:24:40,560 In some cases, this may be desired. 283 00:24:41,400 --> 00:24:44,460 For instance, if you're wanting to gather credentials, you could have a fake login 284 00:24:44,460 --> 00:24:46,780 prompt open, you know, whatever. 285 00:24:47,040 --> 00:24:51,540 But in a lot of cases, you may not want them to be privy to anything that's executing in 286 00:24:51,540 --> 00:24:51,820 the background. 287 00:24:52,480 --> 00:24:54,120 So, this wouldn't really be viable. 288 00:24:54,820 --> 00:24:57,920 At least I'm not sure how you could actually specify that. 289 00:24:58,260 --> 00:24:58,440 But... 290 00:24:59,900 --> 00:25:02,140 Also, the process chain makes it pretty obvious. 291 00:25:02,140 --> 00:25:03,880 What created the process. 292 00:25:04,240 --> 00:25:05,920 We're going to look at this in the next demo. 293 00:25:06,120 --> 00:25:11,120 But basically, Task Host W, which is associated with the Task Scheduler, it's going to have 294 00:25:11,120 --> 00:25:19,740 the same parent process of the same SVC host process as the process that is created. 295 00:25:20,080 --> 00:25:24,720 So from, like, an artifact perspective, it's pretty obvious to see the process chain of 296 00:25:24,720 --> 00:25:24,960 events. 297 00:25:26,420 --> 00:25:32,120 Also, Windows, you know, Task Scheduler creates a lot of events that can be observed and scrutinized. 298 00:25:32,140 --> 00:25:34,060 And this technique has been around for a really long time. 299 00:25:36,040 --> 00:25:38,820 So I'm just going to go ahead and demo that really quick. 300 00:25:40,560 --> 00:25:41,440 Showing that usage. 301 00:25:53,920 --> 00:25:54,320 Okay. 302 00:25:54,400 --> 00:25:56,480 So we have a domain admin logged into the machine. 303 00:25:57,400 --> 00:25:58,920 And that's who we're going to want to target. 304 00:25:59,460 --> 00:26:01,980 Right now, we have admin access. 305 00:26:02,040 --> 00:26:02,120 Okay. 306 00:26:02,140 --> 00:26:02,900 Almost to the same server. 307 00:26:03,040 --> 00:26:05,120 These two servers are the same, just different log in sessions. 308 00:26:05,480 --> 00:26:07,900 But we're, you know, a low privileged user. 309 00:26:08,200 --> 00:26:10,420 But we do have admin access to the server. 310 00:26:10,780 --> 00:26:15,280 So what we want to do is we want to have code execution within the log in session of 311 00:26:15,280 --> 00:26:16,520 the domain admin. 312 00:26:18,760 --> 00:26:23,100 So we're just going to use Process Explorer to show the association of, you know, Task 313 00:26:23,100 --> 00:26:26,960 Scheduler process along with the process that's executed. 314 00:26:27,360 --> 00:26:29,820 I already created this one just for time's sake. 315 00:26:29,960 --> 00:26:30,620 And so... 316 00:26:32,140 --> 00:26:36,840 I'm executing this scheduled task as the domain admin only when they're logged in. 317 00:26:38,420 --> 00:26:41,360 And the actions is we're going to make it open calc. 318 00:26:41,380 --> 00:26:45,280 So if this is successful, then it should open up CMD and calc. 319 00:26:45,300 --> 00:26:48,920 I'm using slash K just so the process doesn't exit so we can observe it. 320 00:26:54,300 --> 00:26:54,780 Okay. 321 00:26:54,780 --> 00:26:54,820 So... 322 00:26:57,840 --> 00:26:58,320 So... 323 00:27:01,180 --> 00:27:01,660 So... 324 00:27:01,660 --> 00:27:01,720 So... 325 00:27:02,140 --> 00:27:02,620 So . 326 00:27:04,160 --> 00:27:07,220 As you can see, it got a little short just for time's sake. 327 00:27:07,960 --> 00:27:15,400 As you can see the CMD was executed within the log on session of the domain admin. 328 00:27:15,600 --> 00:27:19,520 We do have code execution within that log on session, or that user's log on session 329 00:27:19,520 --> 00:27:20,160 which is great. 330 00:27:20,280 --> 00:27:27,380 But as you can see the parent process is associated with both our process and the task host. 331 00:27:28,300 --> 00:27:30,680 That right here is what we want to break up. 332 00:27:30,680 --> 00:27:35,500 up. We want to be able to specify who the parent is and we want it to be believable. 333 00:27:37,600 --> 00:27:53,840 So I'm going to close that for now. Cue up demo four. Yeah. So let's add on to our original 334 00:27:53,840 --> 00:27:59,760 question because there's some downsides to the task host. Good. There's some downsides 335 00:27:59,760 --> 00:28:05,020 to the task host, and that is that it creates a lot of activity on the end point that we may want 336 00:28:05,020 --> 00:28:12,620 to break. So adding to the original question, we want to do that and not generate the obvious event 337 00:28:12,620 --> 00:28:18,640 logs. We only want to display Windows to the end user if we want to, and we want to specify the 338 00:28:18,640 --> 00:28:26,100 parent creator process, and on some levels, we want to evade ETW or other, like, visibility. So 339 00:28:26,100 --> 00:28:27,980 that's going to be the goal. Demo four. 340 00:28:39,460 --> 00:28:45,340 So I'm going to open up process monitor. The key thing about process monitor is that it uses Windows 341 00:28:45,340 --> 00:28:50,560 drivers for the collection of everything, I believe, except for the network activity. The network 342 00:28:50,560 --> 00:28:57,560 activity is actually ETW. So the filter that you can see here is OBService.exe. That's our implant 343 00:28:57,560 --> 00:28:59,740 service or process. So that's our implant service. So that's our implant service or process. 344 00:29:00,180 --> 00:29:06,840 And then we have explore. That's going to be the process that we want to spoof. We want the parent to look 345 00:29:06,840 --> 00:29:12,140 like explore.exe. So if all goes well, we're not going to see anything around OBService, and 346 00:29:12,140 --> 00:29:17,120 everything is going to be associated with explore.exe. Explore.exe can be anything, but that's what 347 00:29:17,120 --> 00:29:21,220 we're using for the demo. So we're going to start that up. 348 00:29:33,660 --> 00:29:38,820 We're going to go ahead and spawn a process into a user session. In this case, we're just going to make 349 00:29:38,820 --> 00:29:48,980 CMD execute DERB, but it can be anything. And now we're targeting the user where we have process 350 00:29:48,980 --> 00:29:52,040 monitor running. Execute it. 351 00:29:59,320 --> 00:30:08,820 Okay. So as we can see, nothing around OBService. We remotely, over mail slots, we sent a task to our 352 00:30:10,120 --> 00:30:16,360 implant, and we had it execute a service or a process, and not only do we not see any sort of network 353 00:30:16,360 --> 00:30:21,500 activity recorded because we're using mail slots, but we are also successfully spoofing the parent 354 00:30:22,100 --> 00:30:29,720 process, and so it's not recorded here. Explore.exe had nothing to do with the execution of CMD, but the 355 00:30:29,760 --> 00:30:33,200 process monitor, it believes it does. 356 00:30:46,120 --> 00:30:50,720 And for time's sake, I'm going to go ahead and kind of fast-forward a little bit of this. What we're 357 00:30:50,720 --> 00:30:56,680 doing in this next session is we're going to do the exact same thing, except this time we're going to 358 00:30:56,680 --> 00:30:59,740 use UDP. And so when we execute it this time, we're going to do the exact same thing, except this time 359 00:30:59,760 --> 00:31:08,160 you can see that because we just used UDP as the transport, it was picked up. So, again, if we don't 360 00:31:08,160 --> 00:31:12,000 use something like mail slots or like I did a talk at DerbyCon a few years ago where we used 361 00:31:12,000 --> 00:31:16,820 Wendivert to do similar things, if we don't use a transport like that and kind of hide that 362 00:31:16,820 --> 00:31:28,580 activity, then it can be picked up on in ATW, but using mail slots is a way to bypass that. So I'm 363 00:31:28,580 --> 00:31:34,000 going to go ahead and show it in Process Explorer. And just for time's sake, again, we're basically 364 00:31:34,000 --> 00:31:39,300 just showing the same thing. And so we're going to get that set up. We're going to go ahead and get 365 00:31:39,300 --> 00:31:47,700 our tool ready to execute the task. Then we're going to send it off. And as we can see, unlike 366 00:31:47,700 --> 00:31:54,240 before, when we used Task Scheduler, it's not underneath a SBC host. It's not associated with our 367 00:31:54,240 --> 00:31:58,560 OB service here. It's shown to be executed or associated with Explorer.exe. And so we're going to 368 00:31:58,560 --> 00:32:09,300 see this as the parent. It's in the target user. And it's even recorded here. So now the next 369 00:32:09,300 --> 00:32:22,920 question is ‑‑ hold on. Let me just get this next one cued up. Okay, good. So how does this 370 00:32:22,920 --> 00:32:28,540 work? How are we achieving this? Two things. One is that we have our server server and we have a 371 00:32:28,540 --> 00:32:34,160 service running in session zero, and it's running a system. So we need two specific 372 00:32:34,160 --> 00:32:39,660 privileges to carry this out, SED bug privilege, and that is for spoofing the parent creator 373 00:32:39,660 --> 00:32:45,660 process, and then we need SETCB privilege, and that is required for creating a process 374 00:32:45,660 --> 00:32:50,960 in a different logon session from the caller. So this is like a really big requirement, 375 00:32:50,960 --> 00:32:58,720 the second part. We're going to so to spoof the parent versus just creating a process 376 00:32:58,720 --> 00:33:02,660 in the logon session, and we actually want to spoof it, in order to do that, we're going 377 00:33:02,660 --> 00:33:08,380 to open a handle to the desired parent process. Not the token. We're not stealing the token. 378 00:33:08,520 --> 00:33:14,460 We're just getting a handle to the process itself. With create process create process. 379 00:33:15,520 --> 00:33:20,500 We're going to then create a new thread attribute list to handle this. 380 00:33:21,160 --> 00:33:25,680 With this attribute, and that's kind of the secret sauce. And then we have to determine 381 00:33:25,680 --> 00:33:32,260 what Windows API we're going to use to carry this out. We're ending up, we're going to 382 00:33:32,260 --> 00:33:37,040 have to use create process as a user, and the reason why is because, and this is demonstrated 383 00:33:37,040 --> 00:33:43,940 in the documentation, but if we use create process with token, it's only going to be 384 00:33:43,940 --> 00:33:47,840 for the specific session that it sends. So basically the create process with token won't 385 00:33:47,840 --> 00:33:50,120 work if you're calling it from one session. 386 00:33:50,120 --> 00:33:55,140 And the token is a session from a different user. So remember, we're in session zero, 387 00:33:55,320 --> 00:33:59,600 and we want to gain execution in a different session. So that was not going to work. So 388 00:33:59,600 --> 00:34:01,560 we're going to have to use create process as user. 389 00:34:05,600 --> 00:34:09,660 But we don't want to, and this is actually what typically is done, but we don't want 390 00:34:09,660 --> 00:34:16,140 to access or steal a token from another process. So what do we do then? Windows has graciously 391 00:34:16,880 --> 00:34:19,040 given us a wonderful API. 392 00:34:19,480 --> 00:34:19,920 WTS. 393 00:34:20,120 --> 00:34:26,060 Query user token. WTS is the Windows terminal services API. You can imagine on a terminal 394 00:34:26,060 --> 00:34:31,020 server that you're going to want to have services being able to interact with logon 395 00:34:31,020 --> 00:34:37,600 sessions, right? And so this API is going to get a primary access token of the logged 396 00:34:37,600 --> 00:34:42,080 on user for a specified session. So we can be running in zero, and we can use this Windows 397 00:34:42,080 --> 00:34:48,220 API to then get a primary access token for any logon session that we want. 398 00:34:49,260 --> 00:34:54,180 In order to do this, we need to be running as NT Authority system, and we need to have 399 00:34:54,180 --> 00:35:00,300 the SCTCB privilege enabled, which is available by default if you're running it at that level. 400 00:35:01,240 --> 00:35:04,580 What I couldn't be fine to be documented and would actually create a lot of frustration 401 00:35:04,580 --> 00:35:09,700 for me developing this is that the caller must be running in session zero. So, for instance, 402 00:35:09,740 --> 00:35:13,480 if you're, you know, download this code and you're testing it out, and you're running 403 00:35:13,480 --> 00:35:18,200 the agent to do this, and you're not in session zero, but you're in a logon session, then 404 00:35:18,220 --> 00:35:23,600 it's going to fail, or at least it did for me on everything. So that's a key component 405 00:35:23,600 --> 00:35:31,480 is that you have to be running in session zero as system for the WTS query user token 406 00:35:31,480 --> 00:35:34,680 to actually obtain the token from another logon session. 407 00:35:36,540 --> 00:35:40,660 The next thing is, can this be detected? Because what we saw is that process monitor 408 00:35:41,240 --> 00:35:45,240 and process explorer, they didn't capture this at all. So, I mean, if we're testing 409 00:35:45,240 --> 00:35:48,040 out malware or whatever, we're using these tools, we're not going 410 00:35:48,220 --> 00:35:52,940 to see this actually fire. So, one, why, and then is the information available? 411 00:35:54,000 --> 00:36:01,220 The next bit of information is by Pavel Yusovitch. He has a really great write-up over this, 412 00:36:01,360 --> 00:36:03,560 and so I definitely want to give a shout out to him. 413 00:36:04,320 --> 00:36:10,680 So for kernel drivers that register the process creation notification with this PSET create 414 00:36:10,680 --> 00:36:16,680 process notification, again, this is in the kernel driver. This is basically a structure 415 00:36:16,680 --> 00:36:22,320 that you get, and I've got to speed up a little bit, but you have these different things. 416 00:36:22,420 --> 00:36:27,920 So we have the handle parent create process ID. That is what process monitor and process 417 00:36:27,920 --> 00:36:33,280 explorer are using, and this is the information that we're spoofing. So now it makes sense 418 00:36:33,280 --> 00:36:38,140 because they're using kernel drivers to gather this activity, and we're spoofing it. This 419 00:36:38,140 --> 00:36:44,200 is the bit of information they're getting it from, most likely. The next thing that 420 00:36:44,200 --> 00:36:46,320 Pavel points out is that 421 00:36:46,680 --> 00:36:53,460 the creating thread ID is also within the struct, and the real creator process ID and 422 00:36:53,460 --> 00:36:59,560 parent can be obtained. But the thing about it is that this information that would actually 423 00:36:59,560 --> 00:37:07,700 show our malware service, this information is lost at this point once, you know, this 424 00:37:07,700 --> 00:37:10,800 exits. So that information isn't stored in the process, apparently. 425 00:37:13,020 --> 00:37:16,660 So what about ETW? So we can bypass, and, you know, we're going to have to go back and 426 00:37:16,660 --> 00:37:23,380 and, you know, we can bypass this visibility within a kernel driver that isn't looking at the 427 00:37:23,380 --> 00:37:27,140 create thread process ID, but just the parent process ID. But what about ETW? 428 00:37:36,080 --> 00:37:41,800 So we're going to go ahead and get it ready. We're going to go ahead and open up process 429 00:37:41,800 --> 00:37:46,640 monitor exp2, which again Pavel created and is available on his GitHub. So, it's going to be a 430 00:37:46,660 --> 00:37:52,860 GitHub and it is using ETW versus like the kernel drivers that we were using within process 431 00:37:52,860 --> 00:37:53,900 monitor and process explorer. 432 00:38:11,800 --> 00:38:12,940 So we execute it. 433 00:38:14,040 --> 00:38:18,740 Now we're just going to go ahead and pause it and what we're going to see is that we 434 00:38:18,740 --> 00:38:19,420 do capture it. 435 00:38:19,540 --> 00:38:23,020 So from a Defender perspective, this can be captured using ETW. 436 00:38:23,020 --> 00:38:25,700 Because it does provide that information. 437 00:38:28,600 --> 00:38:30,620 So that's a good sign for Defenders, right? 438 00:38:30,780 --> 00:38:32,920 I was kind of hoping for the latter, but yeah. 439 00:38:33,820 --> 00:38:34,300 Okay. 440 00:38:34,340 --> 00:38:36,600 So we can see the command was executed as the user. 441 00:38:41,260 --> 00:38:49,100 I just want to like end on this last demo is that, you know, we do see this activity 442 00:38:49,100 --> 00:38:52,200 of spoofing the parent within ETW, but we do not see it. 443 00:38:52,520 --> 00:38:53,000 Okay. 444 00:38:53,020 --> 00:38:58,080 Unless the kernel driver that's being used by the endpoint product is specifically looking 445 00:38:58,080 --> 00:39:01,740 for and looking within that other parameter within the structure. 446 00:39:03,900 --> 00:39:06,640 I'm going to brace this very quickly because I just have a few minutes left. 447 00:39:07,060 --> 00:39:11,960 But the other thing is looking at, you know, anti debug and runtime awareness within your 448 00:39:11,960 --> 00:39:12,180 malware. 449 00:39:14,060 --> 00:39:19,160 We're going to look at TLS callbacks, thread hide from debugger being debugged and environment 450 00:39:19,160 --> 00:39:19,680 variables. 451 00:39:20,140 --> 00:39:23,000 Basically a bunch of different things that I've used very successfully over the years. 452 00:39:25,680 --> 00:39:30,340 The first thing are TLS callbacks, thread local storage. 453 00:39:30,760 --> 00:39:35,660 So these are executed before a thread is created. 454 00:39:35,980 --> 00:39:39,940 And so it's very useful because whenever a process executes, like you're going to have 455 00:39:39,940 --> 00:39:45,340 your main thread, well, if you implement, you know, TLS callbacks, then that is going 456 00:39:45,340 --> 00:39:46,640 to be executed before main. 457 00:39:46,840 --> 00:39:52,700 So you can actually, you know, implement whatever you want before the main function is ever called. 458 00:39:53,020 --> 00:39:54,080 I didn't come up with this. 459 00:39:54,180 --> 00:39:55,700 Obviously this has been around for a minute. 460 00:39:55,920 --> 00:40:01,020 But at least for me, like actually getting this to work and the code available for it 461 00:40:01,020 --> 00:40:03,200 was I really couldn't find it. 462 00:40:03,360 --> 00:40:09,500 But it's not necessarily malicious activity because it's using a lot of mainstream projects 463 00:40:10,200 --> 00:40:13,420 such as Chromium, which is where I reference here. 464 00:40:14,080 --> 00:40:19,020 But the key thing is it's almost like a constructor, ability to have a constructor and destructor 465 00:40:19,020 --> 00:40:19,940 for threads. 466 00:40:20,180 --> 00:40:22,240 So you can have execution before it's executed. 467 00:40:23,020 --> 00:40:23,520 And after. 468 00:40:23,800 --> 00:40:29,980 So obviously we have execution very early in the execution of the process even before 469 00:40:29,980 --> 00:40:30,500 main is called. 470 00:40:33,980 --> 00:40:35,820 So thread hide from debugger. 471 00:40:36,260 --> 00:40:38,960 This technique has been very successful for me. 472 00:40:43,440 --> 00:40:51,520 There's an attribute whenever you're creating a thread where you can set it to not being 473 00:40:51,520 --> 00:40:51,920 a like. 474 00:40:51,920 --> 00:40:54,320 You can set it to not allow being debugged. 475 00:40:54,580 --> 00:40:58,660 And so when you create the thread and you say, hey, hide from debugger, don't allow 476 00:40:58,660 --> 00:41:03,760 me to be debugged, if you debug that thread, the entire process crashes. 477 00:41:04,020 --> 00:41:08,540 So even if this is like a different thread other than main or whatever else, if you try 478 00:41:08,540 --> 00:41:13,120 to debug that process, the entire process or that thread, that entire process will crash. 479 00:41:13,840 --> 00:41:17,980 And this is just because for debugging purposes obviously you'd have to have a thread running 480 00:41:18,880 --> 00:41:20,280 that isn't being debugged itself. 481 00:41:23,840 --> 00:41:28,140 So the next thing is like, well, if we detect something that is happening that we don't 482 00:41:28,140 --> 00:41:30,700 want to happen, how can we leverage this? 483 00:41:31,100 --> 00:41:33,580 And so we want to know if we're being debugged. 484 00:41:33,620 --> 00:41:36,140 And if so, we want to take an action. 485 00:41:37,840 --> 00:41:42,020 Historically, a lot of, you know, cases you've used is debugger present. 486 00:41:42,200 --> 00:41:43,180 We don't want to do that. 487 00:41:44,380 --> 00:41:45,940 Because it's very obvious. 488 00:41:46,180 --> 00:41:46,940 But we don't have to. 489 00:41:47,000 --> 00:41:47,580 It's very simple. 490 00:41:47,740 --> 00:41:51,580 All we have to do is get the address of the process environment. 491 00:41:51,920 --> 00:41:58,680 And then we can access the values, the value at the offset of being debugged. 492 00:41:58,740 --> 00:41:59,580 So it's very simple. 493 00:41:59,680 --> 00:42:01,240 We basically get the address to PEB. 494 00:42:01,520 --> 00:42:02,520 And then we get the offset. 495 00:42:02,740 --> 00:42:04,940 And then we can identify if we're being debugged or not. 496 00:42:06,000 --> 00:42:09,460 You can, you know, use this in code entirely if this is fully working. 497 00:42:09,600 --> 00:42:13,740 But what we're showing here on the right is that we have our main function. 498 00:42:14,220 --> 00:42:16,800 It just simply types a number after getting some input. 499 00:42:17,000 --> 00:42:21,560 But above it, this is where we have our TLS callbacks function being created. 500 00:42:21,560 --> 00:42:22,640 So we're creating a thread. 501 00:42:22,880 --> 00:42:23,940 It's our anti-debug thread. 502 00:42:24,200 --> 00:42:27,760 So before main is called, we're going to execute this anti-debug thread. 503 00:42:28,100 --> 00:42:34,880 And then after that's set up, we're going to make it where it hides from the debugger. 504 00:42:35,300 --> 00:42:39,580 Within that, we're going to read the offset of being debugged within the PEB. 505 00:42:39,900 --> 00:42:44,180 And if we are being debugged, then we're going to add a breakpoint. 506 00:42:44,760 --> 00:42:49,860 So if we add a breakpoint within a thread that is configured to not being debugged, 507 00:42:49,860 --> 00:42:50,780 the process crashes. 508 00:42:50,980 --> 00:42:51,460 Perfect. 509 00:42:51,560 --> 00:42:51,720 Appreciate it. 510 00:42:53,800 --> 00:42:56,300 The next thing is basically just looking at environment variables. 511 00:42:56,480 --> 00:42:59,480 One key thing in a lot of sandboxes is that they're not domain joined. 512 00:42:59,820 --> 00:43:06,040 And so we can look at the user domain and computer name, compare them. 513 00:43:06,200 --> 00:43:11,420 If they are not or if they are the same, then the box is not domain joined. 514 00:43:11,600 --> 00:43:16,000 So simply checking for this can help you bypass a lot of, like, sandboxes. 515 00:43:16,500 --> 00:43:20,540 Because like in, you know, for what I'm doing, typically if we're executing something on 516 00:43:20,540 --> 00:43:21,020 a Windows endpoint. 517 00:43:21,560 --> 00:43:25,200 If it's not domain joined, then it's probably not something that we want to have our stuff 518 00:43:25,200 --> 00:43:25,660 execute on. 519 00:43:25,840 --> 00:43:32,160 So this can be used in conjunction with the TLS callbacks to have really early detection 520 00:43:32,160 --> 00:43:36,100 on, you know, the state of the machine. 521 00:43:36,260 --> 00:43:37,940 And if we actually want to run our implant or not. 522 00:43:38,600 --> 00:43:46,980 So in conclusion, the implant messaging protocol that we've implemented, it has response, I'm 523 00:43:46,980 --> 00:43:49,800 sorry, it will support unidirectional or bidirectional transports. 524 00:43:49,800 --> 00:43:53,560 And you can have optional responses. 525 00:43:55,260 --> 00:43:59,640 Mail slots are available even if SMBV1 is disabled. 526 00:44:01,040 --> 00:44:05,640 The network traffic from that activity is not, is disassociated from the server and 527 00:44:05,640 --> 00:44:06,220 client process. 528 00:44:07,100 --> 00:44:08,760 It's also supports broadcasting. 529 00:44:09,020 --> 00:44:12,700 One of the things in the demos that we didn't see because I was trying to hurry is that 530 00:44:12,700 --> 00:44:19,340 if you put a star instead of the NetBIOS name and you send that out, then any implant within 531 00:44:19,800 --> 00:44:22,120 the domain network is going to receive that and execute. 532 00:44:22,420 --> 00:44:26,080 So we can send out one task and it will propagate to everything in there. 533 00:44:26,200 --> 00:44:29,480 So if we want to target a specific user, we don't know where they are, we can send it 534 00:44:29,480 --> 00:44:34,420 out and then it will just, it will execute within that log on session if and where they're 535 00:44:34,420 --> 00:44:34,780 logged in. 536 00:44:36,300 --> 00:44:37,560 Again, authentication is required. 537 00:44:38,200 --> 00:44:44,500 We just went over, like, the process execution stuff and, you know, spoofing the parent process. 538 00:44:44,880 --> 00:44:47,840 Key takeaways is does your environment detect it? 539 00:44:47,980 --> 00:44:49,700 Does your stack detect this? 540 00:44:49,700 --> 00:44:50,880 Are they looking at the correct things? 541 00:44:50,980 --> 00:44:52,680 Are these an ETW or their own drivers? 542 00:44:53,120 --> 00:44:55,980 What is the state of your network and can they defend against this? 543 00:44:58,300 --> 00:45:00,320 And at this point, I'll go ahead and close. 544 00:45:00,760 --> 00:45:02,280 Again, thank you for being here. 545 00:45:02,520 --> 00:45:03,240 I know it's late in the day. 546 00:45:04,260 --> 00:45:05,440 Huge DefCon panel, obviously. 547 00:45:05,540 --> 00:45:07,040 So, yeah, I really appreciate being here.