00:00:00.100-->00:00:05.839 >>Thanks guys and girls. Uh, thank you for coming to this talk. Um, and let's begin. My 00:00:05.839-->00:00:10.844 name is Dimitry Snezhkov, um I am with IBM X-Force Red. Um, I do security testing, code 00:00:13.280-->00:00:18.285 hacking, um, and tool hacking. So this talk is really about uh safer communication across 00:00:21.154-->00:00:28.028 content proxies with the use of WebHook technologies. We're gonna walk through the um escape 00:00:28.028-->00:00:33.000 from hostile monitored and censored networks through a proxy. Proxy is going to be our 00:00:33.000-->00:00:38.005 target. The content proxy is gonna be our target. And we're going to get out to the external 00:00:38.005-->00:00:44.745 host under your control. That may be your C and C. The purpose is for command execution um on 00:00:44.745-->00:00:51.084 external and internal hosts, content exfiltration and infiltration. So the audience 00:00:51.084-->00:00:56.723 is, uh, is red teamers and pen testers. That's going to be from offensive standpoint but 00:00:56.723-->00:01:01.662 obviously defense is welcome as well as, um, privacy advocates and there will be cases for, um, 00:01:04.498-->00:01:09.836 for that. So anyone that is interested in, um, covert communication out of network's 00:01:09.836-->00:01:16.209 welcome. So, before we get into the technical details we have to, uh, set some stage for the 00:01:16.209-->00:01:22.849 goals of our talk and answer the question why we're doing this. So, we need to meet the defense 00:01:22.849-->00:01:28.588 at their map of the world as a red teamer. Uh, we need to seek alternative means of effective 00:01:28.588-->00:01:34.227 outbound communication and we're gonna try to, uh, minimize our discoverability. We're gonna go 00:01:34.227-->00:01:39.032 into why we need to do this a little later. But also we also we want to live off the land 00:01:39.032-->00:01:44.037 and, uh, use opportunities presented to us by organizations. The technical 00:01:46.506-->00:01:52.946 goals, uh, would be to achieve communication between hostile networks and external hosts and 00:01:52.946-->00:01:59.286 avoid detection, avoid censorship, um, of the intermediate content proxy. And 00:01:59.286-->00:02:03.557 then the technical, uh, technical mechanisms of what we're gonna do is we are gonna 00:02:03.557-->00:02:09.329 discover HTTP WekHooks. Technology we are going to use these WebHooks to achieve such 00:02:09.329-->00:02:15.702 goals and uh, at the end we're, we're gonna showcase a tool that is going to automate things like 00:02:15.702-->00:02:20.707 this. So to set the stage for the players, y'know, to our to our discussion is that we're 00:02:23.143-->00:02:28.148 gonna have uh offense, defense, obviously the content proxy, command and control, concept of 00:02:31.184-->00:02:36.189 C2 broker, and internal and external party. So, the problem of communication from restricted 00:02:38.825-->00:02:45.532 networks. It's not so much cat and mouse game but it's really more like, um, like a parable 00:02:45.532-->00:02:50.537 about six blind blue men in this case and the red elephant. So, the parable goes as follows, 00:02:54.174-->00:02:59.112 right? If you- if you know somebody spotted an animal in the village. They do not know 00:02:59.112-->00:03:03.950 what that animal is and the blind men said well let's discover this animal by touch. 00:03:03.950-->00:03:10.757 Somebody touched, um, a tail and said it's a rope. Y'know uh a leg is a pillar. A chunk of the 00:03:10.757-->00:03:17.330 body is wall, fan, and so on and so forth. So we are on the red team. We on the inside, and 00:03:17.330-->00:03:21.802 we're being discovered by probes. So from the blue perspective, blue team 00:03:21.802-->00:03:27.107 perspective, the sensory perception of what we're doing is, um, i-is really to 00:03:27.107-->00:03:32.112 understand how blind we are. What is this unknown entity and can we detect their capabilities 00:03:34.981-->00:03:40.320 without revealing our detection mechanisms. So really we are waiting from the blue team- blue 00:03:40.320-->00:03:45.125 team perspective whether they unknown moves and how that works, right? Its passive. It 00:03:45.125-->00:03:50.130 works for us. And we're gonna sit tight and look for it. But the red team perspective is 00:03:50.130-->00:03:57.104 different. The elephant, the red team elephant [chuckle] has to know what that environment 00:03:57.104-->00:04:02.542 really is. What is this unknown environment? What can they do to me. Y'know. How many defenses? 00:04:02.542-->00:04:08.849 Where? How? Um, so the wish for the red elephant is to stay put and to understand what's going 00:04:08.849-->00:04:13.854 on but unfortunately the reality is that the red team has to move first. And when what happens, 00:04:16.289-->00:04:22.429 it's a game of, uh, first move. But unfortunately first move may kill. Right? If you're in quiet 00:04:22.429-->00:04:26.766 environments or supervised environments. Moving through proxy, moving content through 00:04:26.766-->00:04:31.771 proxy, is-is going to be uh very challenging sometimes. So, the outcomes for the elephant are 00:04:33.907-->00:04:40.313 three-fold. The first is the unsafe negative outcome. The second is safe negative outcome 00:04:40.313-->00:04:45.952 and the third is safe positive outcome. Let's go through that. The unsafe negative outcome 00:04:45.952-->00:04:52.125 is-is pretty, um, pretty bad. You're being caught, you're done and you're out. The safe 00:04:52.125-->00:04:57.130 negative outcome really is, um, is about discovering the censors. The blind man censors. 00:05:00.267-->00:05:05.272 What they are prior to your first move or very shortly while maintaining stealth. Um, so in 00:05:07.607-->00:05:11.444 our talk we're gonna concentrate, um on the environment where you do not 00:05:11.444-->00:05:18.118 have any kind of capability for exfiltration, uh, over uh covert channels like ICMP/DNS um y'know 00:05:18.118-->00:05:23.123 any kind of connectivity outside except for the, uh, approved content proxy. So unfortunately 00:05:26.059-->00:05:30.697 if you're constrained to this environment where you have just the content proxy that uh allows 00:05:30.697-->00:05:36.369 you to move out, um, you're not achieving your goals but you're still alive. Which is great. You 00:05:36.369-->00:05:41.308 buy time to come up with things that you need to, uh, to do in this environment. So the safe 00:05:41.308-->00:05:46.313 positive outcome from your, uh, your move is, well, um, you literally try to, uh, uh, try to 00:05:49.816-->00:05:55.055 play towards what is being discovered. Um, what are the rules? Can you be an approved 00:05:55.055-->00:05:59.326 tool? Can you be, uh, can you communicate over safe protocol? Is there an apor-,uh, is there 00:05:59.326-->00:06:04.264 an approved port that you can use to, to do your, uh, to do your job? Are you in the safe 00:06:06.266-->00:06:11.271 traffic? So, um, the blue team says my mechanisms really are okay because I do have draconian 00:06:13.807-->00:06:18.812 content proxy. And I do have a whitelist. So, I'm just checking for known bad. It's pretty 00:06:20.814-->00:06:25.819 good-nice right? But, so, the last two outcomes, the safe uh positive and safe negative, um, 00:06:28.221-->00:06:34.194 are good. But we're still not achieving our goal. Um, the one thing that both blue and red 00:06:34.194-->00:06:39.566 team need to understand that the map that they've built by using their sensory perception is not 00:06:39.566-->00:06:44.571 their territo-territory, right? So we've know-used our known methods of classification of the 00:06:47.274-->00:06:53.480 um-of-uh either parties but we also may be overly paranoid of their capabilities or dismissive 00:06:53.480-->00:06:58.918 enough of their capabilities to not being able to achieve our goals. So both build static map 00:06:58.918-->00:07:05.225 of the world. But the map is not completely true all the time. So, fo- this talk is from a red 00:07:05.225-->00:07:11.564 perspective. So what red needs to do is to consistently break the static map of the defense 00:07:11.564-->00:07:16.836 and their own. And we need to meet the bl-meet the bl-blue team at their map of the world. 00:07:16.836-->00:07:23.043 The concept of pacing and leading them. How it's achieved in the wild? Its mimicry. You're 00:07:23.043-->00:07:29.816 um trying to uh achieve external resemblance with something that is known. Right, that's a very 00:07:29.816-->00:07:36.723 powerful concept and, um, we're gonna try to do this by maybe picking undevelopment, uh, or 00:07:36.723-->00:07:42.128 development tools. So, the levels of mimicry that is achieved for red is that we need 00:07:42.128-->00:07:47.133 to be under known and approved, uh, business need role or process. We need to blend into 00:07:49.202-->00:07:54.974 traffic and protocol that is approved by blue. And so we need to work through the good tools 00:07:54.974-->00:08:00.647 and valid rules. We're gonna right and affect the trust detection mechanisms are steady 00:08:00.647-->00:08:05.652 and their map of the world is sort of built. So pacing and leading is communication pattern 00:08:07.987-->00:08:13.493 overall is just a very viable statement, several of 'em followed by a possible 00:08:13.493-->00:08:20.033 suggestion, a lead. We're gonna mimic and follow the developer process and we're gonna code our 00:08:20.033-->00:08:25.372 red tools in the process of a developer. Achieving stealth. We're gonna make the blue team 00:08:25.372-->00:08:30.777 believe that we are the developer and because you trust the developer you should trust 00:08:30.777-->00:08:37.250 us. So it's all good and well. This is all general but how do we really achieve this. Uh, 00:08:37.250-->00:08:42.856 tight content proxy is all you have to work with. Well let's step back a little bit and talk 00:08:42.856-->00:08:48.762 about the technology that we're gonna use to achieve our goal. Uh, WebHooks. WebHooks is a new 00:08:48.762-->00:08:54.934 technology for asynchronous web responses. It is normally built, its historically built for 00:08:54.934-->00:09:01.107 notification services. It's easy to implement. It is low maintenance. It-it works over 00:09:01.107-->00:09:07.046 HTTP and therefore we can use it for our content proxy. The classic server request response 00:09:07.046-->00:09:13.019 polling loop, um, for the web server is that we normally submit a request for processing 00:09:13.019-->00:09:18.425 to a web server. The server begins executing our request and then we keep polling the-the 00:09:18.425-->00:09:24.064 server asking "well are we there yet?" Five times, ten times, however many times we need to 00:09:24.064-->00:09:29.269 get the response from that server. So the server naturally gets annoyed meaning that there 00:09:29.269-->00:09:34.674 are content switches. There are resource consumption, um depending on-on the case there 00:09:34.674-->00:09:41.347 may be even a throttle and mechanism that says you guys cannot do that. So, um, when the 00:09:41.347-->00:09:45.885 server has the result for us we just grab it and we, y'know, disengage from that 00:09:45.885-->00:09:52.525 communication. Unfortunately the web-for the web server or fortunately for the web server. 00:09:52.525-->00:09:57.530 Web server came up with this, uh, new idea idea that, uh, don't ask me when I'm gonna be 00:09:57.530-->00:10:03.903 done. Why don't you post a hook where I'm gonna submit your, uh, response to once I'm done and we 00:10:03.903-->00:10:09.642 can both go our merry way right out the outset of the request. So the client submits a request 00:10:09.642-->00:10:15.014 for process into the server. The server begins executing. We're disengaging at this point and 00:10:15.014-->00:10:21.321 then we're listening for the response the server gives to us. We communicate asynchronously. 00:10:21.321-->00:10:27.026 How that's done from the uh technical standpoint. Your client or you who are asking for 00:10:27.026-->00:10:32.031 responses. Just give the server the URL with the action and a method to post to when the uh 00:10:34.300-->00:10:39.305 the server is done, right so when this link is um is ready its been posted to. So who uses 00:10:41.341-->00:10:48.248 WebHooks? Pretty much everybody right now who does coding uses WebHooks. Continuous integration 00:10:48.248-->00:10:54.821 tools are prime, um, examples of that. Uh, repositories that try to notify people of the check 00:10:54.821-->00:11:01.194 ins check outs. Uh, communication in the learned mechanisms uh that's um 00:11:01.194-->00:11:06.866 companies use to notify them of certain events use them as well. Again, so safe negative outcome, 00:11:06.866-->00:11:11.871 right? We're sitting tight we don't have any way to get out except for to, uh, content 00:11:13.873-->00:11:18.878 proxy. How do we solve this? Well what if you can find a site- a way to turn a site into 00:11:23.883-->00:11:30.423 a, uh, content broker. Right? That uses WebHooks to work through our content back and 00:11:30.423-->00:11:36.663 forth. Uni-directional. Single directional. Maybe even real time. Right? So then we're gonna 00:11:36.663-->00:11:42.602 drive data and communication to the C2. And we're actually sticking to our um main goal is 00:11:42.602-->00:11:47.340 meeting defense and their statis map of the world. They've said they've created rules. We're 00:11:47.340-->00:11:54.247 working through the rules. So the C2 broker site operation is as follows. Um, its a request 00:11:54.247-->00:12:00.787 across some site that is going to invoke a hook onto a third party. The third party is going 00:12:00.787-->00:12:05.792 to execute the request and come back with a response through the C2, um, C2 broker and then the 00:12:08.561-->00:12:14.734 client is going to pull that response off of the C2 broker site. Now the C2 brokers, um, 00:12:14.734-->00:12:20.473 are not created equal. What we need for our needs is that it needs to obviously be public. It 00:12:20.473-->00:12:26.212 needs to be flexible so that WebHooks can actually work through it. You can find a, uh, 00:12:26.212-->00:12:31.217 a website that is on the VIP list with proxies. Pretty much available um and very very 00:12:33.620-->00:12:38.925 useful. Right and it also needs to blend into the business function of this specific 00:12:38.925-->00:12:44.664 organization. So again who uses WebHooks? Let's follow the developer. Continuous 00:12:44.664-->00:12:49.669 integration. Code management. Communication servers is alerting. Github. Github dot 00:12:52.972-->00:12:58.344 com. It's used and popular so that checks out. Its developer friendly. It has awesome WebHook 00:12:58.344-->00:13:03.282 API. It has OpSec features because it uses-it is pretty much trying to um figure out the 00:13:07.654-->00:13:11.591 safe way for the clients to communicate right and so we're gonna write on this. It's TLS, 00:13:11.591-->00:13:17.397 the tokens, HMAC. All over HTTP. And obviously last but not least is the developers themselves 00:13:17.397-->00:13:22.402 drive the adoption inside of their, um, companies for Github. Both of- All of these is 00:13:24.771-->00:13:29.776 advantage for us. We're gonna use Github to open up issues and comments and use Github to 00:13:31.911-->00:13:36.916 achieve this transparency So Octohook is a toolkit that is going to automate this. We're 00:13:39.385-->00:13:46.125 gonna use through the uh we're gonna use Github as our C2 broker to communicate to our C2, 00:13:46.125-->00:13:53.132 uh, machine on the outside. How that's done? Well, you create a, um, repository on Github. You 00:13:53.132-->00:13:58.137 register payload URL which is our WebHook. We are, y'know, we can do our secret as well. As 00:14:01.274-->00:14:07.647 using the, uh, the tokens. And we activate the hook. Once that's done we are watching for 00:14:07.647-->00:14:12.218 issues and comments. The two events that are being broadcasted every time something 00:14:12.218-->00:14:18.591 happens that, um, that we're interested in on Github and obviously that gets posted out 00:14:18.591-->00:14:23.596 to our C2 server. Agent or the internal agent or the external agent. And then the OpSec, 00:14:26.999-->00:14:29.001 right? Uh, we -we're riding on Github's ability to create safe communication for us. We're 00:14:29.001-->00:14:31.003 using certificates to our advantage. So OctoHook a-, OctoHook agent and server its 00:14:31.003-->00:14:33.005 its the same thing right? You come up on both sides the same way. It uses Git issues to 00:14:33.005-->00:14:38.010 communicate requests. It uses comments to, um, to shuttle responses back. It's a straight 00:14:53.693-->00:15:00.600 YAML and JSON response. Also feeding into, uh, the model of keeping with the blue team and 00:15:00.600-->00:15:06.005 um, understanding what they're looking for and what they're not looking for. And um, essentially 00:15:06.005-->00:15:11.711 the way it looks like we're gonna see a demo of it but statically, it's a repo that has 00:15:11.711-->00:15:17.950 a bunch of commit-uh a bunch of issues and comments on it. Nothing more nothing less. So, 00:15:17.950-->00:15:22.955 responses and requests are being moved very transparently. Every agent on the inside or outside 00:15:25.091-->00:15:30.096 can post to Github under its own space. Its-uh, every agent that comes up to communicate into 00:15:32.398-->00:15:37.403 this uh, um, swarm, right?Uh, It-it has an ID. You can statically set it. And then 00:15:39.438-->00:15:44.443 everything that's you shuttled back and forth gets stored under that ID. So this is all good and 00:15:46.546-->00:15:53.386 well but we have to keep polling the issues and comments from the client's side, right? So we have 00:15:53.386-->00:15:59.926 to go to the C2 broker and said well if we executed a command is our response um good, I mean did 00:15:59.926-->00:16:05.464 we receive a response or not? That's not a big deal we can get-uh get around Github 00:16:05.464-->00:16:09.802 throttling mechanisms because we can't check every second right? They're not. We're doing it 00:16:09.802-->00:16:16.209 manually that's not a big deal. But can we really improve? Well it turns out the WebHooks can 00:16:16.209-->00:16:21.547 work both ways. And at Github, you can do twenty of those WebHooks. So why not establish 00:16:21.547-->00:16:26.552 two way communication from our client directly to the C2 over Github. Over C2 broker. So now 00:16:28.788-->00:16:34.160 what we have, uh we have two WebHooks. One goes to the client's side the other goes to 00:16:34.160-->00:16:39.165 our C2. Right? So we achieve real time communication that way. And now we can play with 00:16:41.634-->00:16:46.873 roles. We can say okay well on the inside, the server is going to- the agent is going to be the 00:16:46.873-->00:16:51.878 client. The server is going to be on the outside where we can flip the roles, right? Now, uh, 00:16:54.146-->00:16:59.018 as I mentioned before the configuration for both client and the server, the agent roles 00:16:59.018-->00:17:05.825 on side-on both sides are pretty much the same except for the-the um the actual notion of a role. 00:17:05.825-->00:17:11.564 Am I listening? Or am I executing? Or am I, um subscribing for requests and 00:17:11.564-->00:17:18.004 I'm, um, I'm asking the-the Github or C2 broker to do it for me. So, when we go through the 00:17:18.004-->00:17:23.276 demo and we're going to look at asynchronous unidirectional command execution. The first 00:17:23.276-->00:17:28.281 case, right? When we can get to C-to our C2 but we still need to manually poll our issue or 00:17:30.383-->00:17:37.290 comment for, um, for the state. Is it closed? Do you have any data output or not. The second 00:17:37.290-->00:17:42.061 is going to be, uh, asynchronous bidirectional communication where we have both of the 00:17:42.061-->00:17:47.233 WebHooks one goes to the inside, the other goes to the outside. And then we're gonna see the 00:17:47.233-->00:17:53.139 asynchronous content deliveries. So the two, two phases in this is a shell execution of commands 00:17:53.139-->00:17:58.344 on one side or the other and the other is the content delivery for example for the red team if 00:17:58.344-->00:18:04.083 you forgot your tool kit you can go to your C2 through Github and bring it back on the inside. And 00:18:04.083-->00:18:10.389 then some features, uh, that's kind of, y'know, fit into this model of Octohook configuration 00:18:10.389-->00:18:15.394 and logs. So first is going to be, uh shell and execution. Um, we're gonna take it from the 00:18:18.364-->00:18:23.369 perspective of a client. We're on the inside. This is a prompt for Octohook and it's loaded, uh 00:18:28.441-->00:18:34.647 the configuration is loaded off of the client that YML. That lists all the Github tokens, uh, 00:18:34.647-->00:18:39.752 all the configuration that needs to connect to the C2 under the account. What's happening right 00:18:39.752-->00:18:44.757 now um the client is executing LS command on a C2 over Github. Notice that there are no, uh, 00:18:49.595-->00:18:54.100 there is no response from that because this is the first method when we're going to Github And 00:18:54.100-->00:18:59.105 polling for uh results. So we're checking on a specific issue that we know is open for our 00:19:04.076-->00:19:09.081 request. Uh, and see that it's an enclosed state. It's in OS execution and now we're going to 00:19:11.651-->00:19:17.890 poll for it. We're gonna view the issue. We're gonna view the comments. Right and so we have 00:19:17.890-->00:19:22.895 response from LS command that is coming from our C2. The bidirectional hooks, uh, were 00:19:27.400-->00:19:33.172 spawning on a, they're spawning of, uh , a real time management thread that's gonna listen in 00:19:33.172-->00:19:38.811 the processor of Octohook. There's a - there's a web server that can come up to listen to 00:19:38.811-->00:19:43.649 the WebHook coming in and because it's a broadcast to any of the WebHooks that are 00:19:43.649-->00:19:49.889 registered on Github, the response goes to everyone. So once we do RTM we're gonna 00:19:49.889-->00:19:54.894 execute LS again and we should get a response. Right. Real time. So essentially the 00:19:57.329-->00:20:02.334 broadcast goes to both sides. The client on the inside and um the C2. [clapping] Just a little 00:20:12.044-->00:20:17.049 note on uh the, some of the uh, >>[inaudible off mic] >>Sorry? >>[inaudible] >>Okay so really 00:20:19.218-->00:20:24.223 quick. Um, this, um, this Octohook uh is hosted on Github, right. And uh, so you guys can 00:20:28.727-->00:20:33.732 pull it, uh play with it and uh, the um, the slides are gonna be uh, posted um soon. So, one 00:20:42.808-->00:20:46.579 little thing that I wanted to mention is that uh what we're doing right now we're creating a 00:20:46.579-->00:20:53.219 file um um on the on the C2 and we're gonna try to bring that file back to the client by 00:20:53.219-->00:20:59.024 executing output of this um of this file to the Github and then um we're gonna see how that's 00:20:59.024-->00:21:03.963 done. So really quick this is how. Anyways so last but not least what can you do about 00:21:07.833-->00:21:12.938 that? You really need to understand uh what Github is used for your purposes on the 00:21:12.938-->00:21:17.943 inside and restrict access to um repositories that you are not, um, you're not working with on 00:21:21.514-->00:21:27.086 the inside. If you guys have any questions, uh, I'll be outside please ask. This is the 00:21:27.086-->00:21:32.091 Octo-Octohood-Octohook uh Github repository. Please fork or work with it. Thank you so much.