 Thanks guys and girls. Thank you for coming into this talk and let's begin. My name is Dmitry Snashkov. I am with IBM X-Force RED. I do security testing, code hacking and tool hacking. So this talk is really about safer communication across content proxies with the use of webhook technologies. We're going to walk through the escape from hostile, monitored and censored networks through a proxy. Proxy is going to be our target. The content proxy is going to be our target. And we're going to get out to the external host under your control. That may be your CNC. The purpose is for command execution on external and internal hosts, content exfiltration and infiltration. So the audience is red teamers and pentesters. That's going to be from offensive standpoint. But obviously defense is welcome as well as privacy advocates and there will be cases for that. So anyone who is interested in covert communication out of networks are welcome. So before we get into the technical details we have to set some stage for the goals of our talk and answer the question why we're doing this. So we need to meet the defense at their map of the world as a red teamer. We need to seek alternative means of effective outbound communication and we're going to try to minimize our discoverability. We're going to go into why we need to do this a little later. But also we also want to live off the land and use opportunities presented to us by organizations. The technical goals would be to achieve communication between hostile networks and external hosts and avoid detection, avoid censorship of the intermediate content proxy. And then the technical mechanisms of what we're going to do is we are going to discover HTTP web hooks. Technology, we are going to use the web hooks to achieve such goals. And at the end we're going to showcase a tool that is going to automate things like this. To set the stage for players, you know, to our discussion is that we're going to have offense, defense, obviously the content proxy, command and control, concept of C2 broker and internal and external party. So the problem of communication from restricted networks, it's not so much a cat and mouse game, but it's really more like a parable about six blind blue man in this case and the red elephant. So the parable goes as follows, right? If you know somebody spotted an animal in the village, they do not know what that animal is. And the blind man said, well, let's discover this animal by touch, somebody touched a tail and said it's a rope, you know, a leg is a pillar, a trunk of the body is a wall, fan and so on and so forth. So we are on the red team, we are on the inside and we're being discovered by probes. So from the blue team perspective, the sensory perception of what we're doing is really to understand how blind we are, what is this unknown entity and can we detect their capabilities without revealing our detection mechanisms. So really we are waiting from the blue team perspective whether they are unknown moves and how that works, right? It's passive, it works for us and we're going to sit tight and look for it. But the red team perspective is different. The elephant, the red team elephant has to know what that environment really is. What is this unknown environment? What can they do to me? You know, how many defenses where how? So the wish for the red elephant is to stay put and to understand what's going on. But unfortunately, the reality is that the red team has to move first. And when what happens, it's a game of first move. But unfortunately, first move may kill, right? If you're in quite environments or supervised environments, moving through proxy, moving content through proxy is going to be very challenging sometimes. So the outcomes for the elephant are threefold. The first is the unsafe negative outcome. The second is safe negative outcome. And the third is safe positive outcome. Let's go through that. The unsafe negative outcome is pretty bad. You're being caught, you're done, and you're out. The safe negative outcome really is about discovering the sensors, the blind man sensors, what they are prior to your first move or very shortly, while maintaining stealth. So in our talk, we're going to concentrate on the environment where you do not have any kind of capability for exfiltration over covert channels like ICMP DNS, you know, any kind of connectivity outside except for the approved content proxy. So unfortunately, if you're constrained to this environment where you have just the content proxy that allows you to move out, you're not achieving your goals, but you're still alive, which is great. You buy time to come up with things that you need to do in this environment. So the safe positive outcome from your move is, well, you literally try to play towards what is being discovered, what are the rules? Can you be an approved tool? Can you communicate over safe protocol? Is there an approved port that you can use to do your job? Are you in a safe traffic? So the blue team says my mechanisms really are okay because I do have draconian content proxy and I do have a white list. So I'm just checking for no one bet. It's pretty good, nice, right? But so the last two outcomes, the safe positive and safe negative are good, but we're still not achieving our goal. The one thing that both blue and red team need to understand that the map that they've built by using their sensory perception is not the territory, right? So we've all now used our known methods of classification of either parties, but we also may be overly paranoid of their capabilities or dismissive enough of their capabilities to not being able to achieve our goals. So both build static map of the world, but the map is not completely true all the time. So this talk is from a red team perspective. So what red needs to do is to consistently break the static map of the defense and their own. And we need to meet the blue team at their map of the world, the concept of pacing and leading them. How it's achieved in the wild, it's mimicry. You're trying to achieve external resemblance with something that is known, right? It's a very powerful concept and we're going to try to do this by maybe picking on development or development tools. So the levels of mimicry that is achieved for red is that we need to be under known and approved business need role or process. We need to blend into traffic and protocol that is approved by blue. And so we need to work through the good tools and valid rules. We're going to write on the fact that trust detection mechanisms are static and their map of the world is sort of built. So pacing and leading as communication pattern overall is just a verifiable statement, several of them followed by a positive suggestion, elite. We're going to mimic and follow the developer process and we're going to code our red tools in the presence of a developer achieving stealth. We're going to make the blue team believe that we are the developer and because you trust the developer, you should trust us. So it's all good and well. This is all general, but how do we really achieve this? Tight content proxy is all you have to work with. Well, let's step back a little bit and talk about the technology that we're going to use to achieve our goal, webhooks. Webhooks is a new technology for asynchronous web responses. It is normally built, it's historically built for notification services. It's easy to implement. It is low maintenance and it works over HTTP and therefore we can use it for our content proxy. The classic server request response polling loop for the web server is that we normally submit requests for processing to a web server. The server begins executing our request and then we keep polling the server asking, well, are we there yet? Five times, ten times, however many times we need to get the response from that server. So the server naturally gets annoyed meaning that there are content switches, the resource consumption. Depending on the case, there may be even a throttling mechanism that says you guys cannot do that. So when the server has the result for us, we just grab it and we, you know, disengage from that communication. Unfortunately for the web server or fortunately for the web server, web server came up with this new idea that don't ask me when I'm going to be done. Why don't you post a hook where I'm going to submit your response to once I'm done and we can both go our merry way right at the outside of the request. So the client submits a request for processing to the server. The server begins executing. We're disengaging at this point and then we're listening for the response the server gives to us. We communicate asynchronously. How that's done from the technical standpoint, your client or you who are asking for responses, just give the server the URL with the action and the method to post to when the server is done. So when this link is ready, it's being posted to. So who uses web hooks? Pretty much everybody right now who does coding uses web hooks. Continuous integration tools are prime examples of that, repositories that try to notify people of the check-ins, check-outs. Communication and alerted mechanisms that companies use to notify them of certain events use them as well. Again, so safe negative outcome, right? We are sitting tight. We don't have any way to get out except through content proxy. How do we solve this? Well, what if we can find a site, a way to turn a site into a content broker, right, that uses web hooks to work through our content back and forth, unidirectional, single directional, maybe even real time, right? So then we're going to drive data communication to the C2. And we're actually sticking to our main goal is meeting defense at their static map of the world. They've said they've created rules. We're working through the rules. So the C2 broker site operation is as follows. It's a request across some site that is going to invoke a hook onto a third party. The third party is going to execute the request and come back with a response through the C2 broker. And then the client is going to pull that response off of the C2 broker site. Now, the C2 brokers are not created equal. What we need for our needs is that it needs to be obviously public. It needs to be flexible so that web hooks can actually work through it. You can find a website that is on the VIP list with proxies, pretty much available and very, very useful, right? And it also needs to blend into the business function of this specific organization. So again, who uses web hooks? Let's follow the developer. Continuous integration, code management, communication services, alerting, github, github.com. It's using popular so that checks out. It's developer friendly. It has awesome web hook API. It has Opset features because it uses, it is pretty much trying to figure out the safe way for the clients to communicate, right? And so we're going to write on this. It's TLS, the tokens, HMAC, all over HTTP. And obviously last but not least is the developers themselves drive the adoption inside of their companies for github. Both of, all of these is advantage for us. We're going to use github to open up issues and comments and use github to achieve this transparency. So Octahook is a toolkit that is going to automate this. We're going to use through the, we're going to use github as our C2 broker to communicate to our C2 machine on the outside. How that's done? Well, you create a repository on github, you register payload URL which is our web hook. We are, you know, we can do our secret as well as using the tokens and we activate the hook. Once this done, we are watching for issues and comments. The two events that are being broadcasted every time something happens that, that we're interested in on github. And obviously that gets posted out to our C2 server agent or the internal agent or the external agent. And then the OPSEC, right, we're writing on github's ability to create safe communication for us. We're using certificates to our advantage. So Octahook agent and server is the same thing, right? You come up on both sides the same way it uses git issues to communicate requests. It uses comments to shuttle responses back. It's a straight YAML and JSON response also feeding into the model of keeping with the blue team and understanding what they're looking for and what they're not looking for. And essentially the way it looks like, we're going to see a demo of it, but statically it's a repo that has a bunch of issues and comments on it. Nothing more, nothing less. So responses and requests are being moved very transparently. Every agent on the inside or outside can post to github under its own space. It's every agent that comes up to communicate into this swarm, right? It has an ID. You can statically set it. And then everything that you shuttle back and forth gets stored under that ID. So this is all good and well, but we have to keep polling the issues and comments from the client side, right? So we have to go to the C2O broker and said, well, we've executed a command. Is our response good? I mean, did we receive a response or not? That's not a big deal. We can get around github throttling mechanism because we can check every second, right? We're doing it manually. That's not a big deal. But can we really improve? Well, it turns out that web hooks can work both ways. And at github you can do 20 of those web hooks. So why not establish two-way communication from our client directly to the C2 over github, over C2 broker? So now what we have, we have two web hooks. One goes to the client side. The other goes to our C2, right? So we achieve real-time communication that way. And now we can play with roles. We can say, okay, well, on the inside, the server is going to, the agent is going to be the client. The server is going to be on the outside, or we can flip the roles, right? Now, as I mentioned before, the configuration for both client and the server, the agent roles on both sides are pretty much the same except for the actual notion of a role. Am I listening? Or am I executing? Or am I subscribing for request? And I'm asking the github or C2 broker to do it for me. So when we go through the demo, and we're going to look at asynchronous unidirectional command execution, the first case, right? When we need to, we can get to our C2, but we still need to manually pull our issue or comment for the state. Is it closed? Do you have any data output or not? The second is going to be asynchronous bidirectional communication. When we have both of the web hooks, one goes to the inside, the other goes to the outside. And then we're going to see the asynchronous content delivery. So the two phases in this is a shell execution of commands on one side or the other. And the other is the content delivery. For example, for the red team, if you forgot your toolkit, you can go to your C2 through github and bring it back on the inside. And then some features that kind of, you know, fit into this model of octahook configuration unlocks. So first is going to be a shell and execution. We're going to take it from the perspective of a client we're on the inside. This is a prompt for octahook. And it's loaded, the configuration is loaded off of the client that YML that lists all the GitHub tokens, all the configuration that needs to connect to the C2 under the account. What's happening right now, the client is executing LS command on the C2 over GitHub. Notice that there are no, there is no response from that because this is the first method when we're going to GitHub and polling for results. So we're checking on a specific issue that we know is open for our request and see that it's in a close state. It's an OS execution. And now we're going to call for it. We're going to view the issue. We're going to view the comments, right? And so we have response from LS command that is coming from our C2. The bidirectional hooks, we're spawning on a, spawning off a real-time management thread that is going to listen. In the processor of octahook, there's a, there's a web server that can come up to listen to the web hook coming in. And because it's a broadcast to any of the web hooks that are registered on GitHub, the response goes to everyone. So once we do RTM, we're going to execute LS again and we should get a response, right? Real-time. So essentially the broadcast goes to both sides, the client on the inside and the C2. Just a little note on some of the, sorry? Okay. So really quick. This octahook is hosted on GitHub, right? And so you guys can pull it, play with it. And the slides are going to be posted soon. So one little thing that I wanted to mention is that what we're doing right now, we're creating a file on the C2. And we're going to try to bring that file back to the client by executing a put of this file to the GitHub. And then we're going to see how that's done. So really quick, this is her. Anyway, so last, by that list, what can you do about that? You really need to understand what GitHub is used for your purposes on the inside and restrict access to repositories that you are not, you're not working with on the inside. If you guys have any questions, I'll be outside. Please ask. This is the octahook GitHub repository. Please work or work with it. Thank you so much.