 good afternoon thank you all for being in here you are in track 3 and this is hooked browser mesh networks with web RTC and beef and without further ado the eccentric Christian for show. Hey everybody how's everyone's DEF CON going? Yeah I can't believe you guys are still hanging out here at 6 although I know like a big you know 100% of the Australians here have just woken up so awesome if someone is going to find me a beer later on that would be really really fantastic. So my name is Christian free show I'm happy to be here talking to you guys about some pretty fun stuff. I'm one of the co-authors of the browser hackers handbook and I'm also one of the developers of the beef project or the browser exploitation framework and in case you couldn't pick from the accent I'm also an Australian well ex Australian well Australian ex Australian I've just relocated with the family up to California. So what that basically means is I have no idea how hot it is and every time I get in the car it's telling me distances that I have no idea what it means it's like take the turn right in 500 feet and I'm like what the fuck does that mean? Anyway so what are we going to be talking about this afternoon? There's probably a few main themes that I'm going to be brushing across firstly obviously is this JavaScript so I apologize in advance there's going to be quite a bit of JavaScript in this talk obviously client side security and kind of social engineering testing and then onto the browser exploitation framework or beef. Hands up here people who have heard of beef before awesome keep your hand up if you've used beef before yeah okay keep your hand up if you were authorized to use beef as part of a security engagement. Okay awesome. Another one of the themes I'm going to be talking about is obviously problems with browser communication channels so after you initiate a hook into a browser how you kind of maintain those comms obviously how webRTC can help and then finally integrating webRTC into beef and then I'm going to have a demo of some variety. So let's kick this off. So when Wade another Aussie created beef he basically came up with he just wanted to not pop alert dialogues anymore for cross-site scripting and people still do this all the time like how many like honestly how often do you guys do engagements and you find a cross-site scripting floor and the first thing you do is like alert parentheses one, parentheses colon. You know it's the first thing it's like the knee-jerk reaction to what you want to do if you find a cross-site scripting floor and Wade was sitting there going this means absolutely dick to everyone like it doesn't mean anything it's useless for developers it's kind of the business owners don't understand what it is and there's so much more that you can do when you have this foothold inside of the browser context. And I guess as the framework kind of grew and as security testing as a process sort of grew and changed we started to see people I guess targeting end users more and more and more and the browser is obviously a really interesting channel to be able to do that. And obviously as the internet grows so did the use of browser technology and this is a really interesting concept because if you think about it right now you guys will definitely have well probably have a smartphone of some variety in your pocket which may have one or more web browsers those browsers probably have multiple tabs if you guys have your laptops here you'll probably have two or three browsers all with multiple tabs and you might have more than one computer because you'll have a work laptop and a personal laptop and if you start to break that down the attack surface for kind of web based traffic is enormous. There's a lot of things that can go wrong. And you know browser developers have done this really fantastic thing where you open up Chrome and it's got three buttons or like four buttons or whatever like Chrome's got the burger and the backwards and the forwards and the refresh or whatever and it looks super simple like my mom can and does use it but Chrome is seriously complicated. Modern JavaScript is just really, really complicated and basically this attack surface is you know it's ginormous. Wade posits this really interesting kind of risk discussion. I like to use this example because I think if you kind of think about it this way it's kind of a bit petrifying but if you're working as like the security guy inside of your company and someone came up and said hey we need to get your approval to install this application on everyone's computer and you're like okay cool and they're like oh yeah and the primary purpose of this application is to go out onto the internet and just access arbitrary things on the internet and we can't vet whether or not they're secure or not and you're like okay well that sounds pretty risky and then they also tell you that the other like secondary use case of this piece of software is to access all the sensitive internet material that you have. At the same time multiple tabs with things happening in the background. Like if you knew that we weren't talking about web browsers a lot of people would say there's no way we should be using this technology. Like it's very very risky. I guess another one of the things that we're sort of seeing happen and why we're seeing more people kind of shift to these javascript style attacks is thick browser style technology is disappearing. You know so who here hasn't uninstalled Flash yet? Alright you've all uninstalled Flash. This is Flash Gordon. Have you guys met Flash Gordon before? It's like awesome 80's idol. Whatever. And so like most of the kind of thick web technology that we did have like Flash and Silverlight and all that sort of stuff is kind of being replaced almost feature by feature by modern HTML5 which as far as I know doesn't actually mean anything except for more crazy javascript. Like lots and lots and lots of javascript. So what the fridge is browser hacking? So when I guess we talk about browser hacking we basically talk about putting payloads in the context of a document object model and then using javascript either maliciously or just because that's the way it's meant to work to try and exfiltrate information or find other systems or trick the user into divulging information you know using social engineering techniques or whatever. The browser hackers handbook and here are the two other co-authors. Michele doesn't like pants apparently. And he's up there. I'm so happy that you saw that slide and Wade actually really likes pants. It's basically focus on various attacks and attack patterns that can occur once someone has injected I guess a controlling piece of javascript inside of the document object model inside of a browser. Or not necessarily even just within the DOM but also in the multiple contexts that do exist within a browser such as within plug-ins and so on. And in the book we define this methodology of attacking which I kind of I really like is I think it kind of stages through exactly what we're trying to achieve and what the framework inside of beef is actually trying to do to make people who do these sorts of assessments their lives a bit easier. Obviously there's the initiation of control so this is by exploiting things like cross-site scripting or stored cross-site scripting or other ways that you might be able to point a website and put a payload on there. Could be man in the middle style attacks or phishing attacks or whatever. But obviously executing a piece of javascript by itself is kind of useless unless you can maintain those communications back to your controlling interface. So the next phase is obviously retaining that control and then at that point if you have established both of those things in a very, very kind of rigorous and stable manner you can then move on to your attack scenarios and then the book obviously goes onto a bunch of other stuff. Most of this talk is just about the retaining of control. So I'm not going to be dropping universal cross-site scripting flaws that I found in anything. This talk does not contain any zero days. I apologize. It's just kind of looking at interesting channels for the maintenance of comms. So let's introduce beef. That's a picture that doesn't really show or help you showing what beef is at all. But I guess the idea is at the core of beef is that there's a hook.js file and it's called hook.js by default. You can obviously change that to be called whatever. And once you basically get that JavaScript executing within a document it will start pulling back to the server. So you can basically hook a bunch of resources. They will start talking to your controlling server and then you can use that controlling server to kind of queue up command modules to execute within the document object model. And obviously you have like a pretty user interface. This is the serious part of the talk by the way because I'm a Virgin Defcon talker. All right. Okay. So obviously right now the way that beef currently maintains its comms is through kind of two, two and a half primary data channels. The first one is obviously XMLHTTP request objects within the DOM. And these are pretty much just like dynamic get requests. Like it's all pretty simple. And I guess the importance comes down to like you know why would you need to be able to retain your communication channels for a long period of time? It kind of comes down to you want to retain that comm for as long as you can because certain attacks scenarios need time to complete. And a really good example that I like to talk about is McKellie did some research that he presented at Rux a couple of years ago on like distributed blind time based SQL injection using multiple browsers. Really, really interesting technique. Hello. Okay. Now stop talking. All right. All right. So I just want to say thank you to everybody that's here this late. You know coming in to see a new speaker. That's just fantastic. Give yourselves a round of applause. Yeah. How's he doing? Is he doing well? He sucks. That do sucks. Can you understand anything he's saying? I don't know. Dude, thank you. Awesome. He said he's going to make a boiler maker. All right. Well, anyway, I think you guys all know the drill to new speakers, to Defcon, to all the new attendees. Thank you for coming. Cheers. As you were. So obviously if you're kind of doing these sorts of attacks, the longer you can kind of maintain that communication channel, the more likely it is that you're going to be able to see your results. And sometimes you will need the time because certain attacks are slow. The second channel is obviously WebSockets, which is kind of like an asynchronous client-to-server channel that I guess is like a new Web 2.0 thing that they've introduced kind of recently. Also another piece of awesome software engineering from McKellie. And also DNS, which is a kind of relatively new communication channel. Here's some JavaScript. I'm not too sure. You guys probably can't read this. But basically what this is showing is some of the beef client-side JavaScript library, which basically comes down when you initialize a browser into beef. And what we actually do is we just wrap around jQuery. And you can see here this is just like a jQuery Ajax call. And what happens is on a polling period of I think by default one second right now, the browser will basically send a get request to beef. And if there's a new command queued up, it will pull it back and execute that module and send back the results. It's not too complicated. That's how Gmail works pretty much. We basically wrote Gmail. WebSockets are another really interesting way to do this. One of the really cool benefits of WebSockets is that because they are asynchronous. So there's no more polling. And what you see here right in the middle there is basically an event handler for this dot socket dot on message. So what that means is if you kind of submit a command through the UI interface, it will basically kind of just send through real fast. And there are a lot of different use cases where you'll need the rapid response for that sort of communication channel. WebSockets are pretty cool. Also kind of hit and miss depending on what if you're targeting a corporate, whether or not it'll get out through firewalls and stuff, but quite often it does. And it's pretty interesting technology in general. And finally DNS. So this is a relatively new way to be able to communicate from a browser back to beef. But this idea is basically there's a couple of encoding functions. So if you have to send data back to the beef server, you kind of encode it up and break it down into some payloads. And then you dynamically build images which are put into the DOM. And those images are on domains which are dynamically generated, which I guess are sub-domains to the beef server itself. So when you start at beef it actually listens as a DNS server. Like right now you start beef, you've got a DNS server running as well. So you can see there the send query function, var image equals new image, image source, blah, blah, blah. Now there's a problem with each of these communication channels and if you look at this picture it's kind of obvious. Regardless of if you're using get requests, DNS, WebSockets whatever, all your traffic goes to your server. So from a defender's point of view that's awesome. You see one browser that's talking to a beef server and then you very quickly find all the other browsers which are talking to your beef server if you're not terrible at what you do. All cows lead to Rome. Now there's a couple of ways that you can kind of get around this. You could set up multiple beef servers. So that could help you obfuscate I guess where communications are going to. You could achieve this by having multiple interfaces on a single server or is this thing catching my accent at all? Apparently that's a computer. Like that's not a human there. And that's what I said. And American people paraphernalia. Maybe you knew what I was going to say before I was going to say it. Or you could set up proxy servers. So that's another interesting channel I've seen people use and talk about. Set up some proxy servers and kind of distribute them around the place and have a central beef server. There's obviously a bunch of different ways that you can try and help obfuscate the data but it kind of doesn't help with hiding that concept of a single beef server. You could start by reducing your polling periods. So I said by default a second. You could reduce that to a minute. Now beef will still kind of work. But it's not going to be as useful as it possibly could be. We also have evasion and obfuscation extensions within the platform as well which is really cool. So that basically every time you kind of rendering and building the JavaScript on the beef server before it's sent over to the client, it'll be obfuscated. But that doesn't help obfuscate the server. And you can use HTTPS. Which is not going to help. Or you could do something crazy like that. Like let's make the browsers stop talking to the beef server. Because they don't like beef. Like what? So the first time I started looking into WebRTC how it's like bullshit this stuff works. So this is the blurb. It's a free open project that enables web browsers with real time communication capabilities via simple JavaScript APIs. They made it so that you could web chat to each other. And I don't know maybe that was something that chat roulette were really into or something. It's actually really, really cool. And then the technology kind of matured and they were doing things like oh we can actually make it such that your browser can talk to your VoIP phone as well. Because it uses a lot of similar technology. Hands up, has anyone played with WebRTC before? A few hands. So this is not going to surprise you. I'm just yanking stuff. So obviously for the WebRTC stuff to work there's three primary JavaScript APIs. The media stream which is kind of why it was used like built in the first place. I don't really touch on that. The RTC peer connection which is where it starts to get interesting. And then finally the data channel which I use a lot. So the media stream on this little snippet of JavaScript allows you to kind of sense some constraints in what's happening inside of the browser. And then basically kind of use the get user media call against those constraints with like a success and an error call back. And when that happens because it's trying to access the video Chrome for example will pop up that dialogue that says hey this site is trying to access your camera. And then if you click yes your camera will start and there will be a blob stream of data inside the DOM now which is basically feeding from your camera. Now by default it's not going to do anything. It's just going to sit there. Your light will be on. But obviously they've got access to your media. Now the peer connection interface is where we start setting up connectivity from peer to peer. And here like furthering on this example we're obviously establishing a peer connection. We're setting some more event handlers and one of them is if we get like a remote stream for example we then attach that stream to a local div or whatever. So you can actually see the video from somewhere else. I'll go into a lot more detail for how this works in a bit. And then the data channel stuff is kind of what it sounds like if you've established a peer connection between two browsers the data channel basically gives you an asynchronous method within JavaScript to send data payloads from browser to browser. This is like a chat example. There's actually heaps and heaps of really interesting users like example WebRTC websites out on the internet. So if you go on some of the websites some guys have set up like peer to peer file transfer over WebRTC. So first person goes to a website and it has like a you know it'll generate like a unique URL. And you give that URL to your friend and they'll visit the website. Your browsers will establish connection to each other and you can drag and drop files to each other and they don't go through the server. Like it's actually the fact that it works is kind of I find quite surprising. I mean this is all JavaScript right it's freaking crazy. Yeah. And so it really really it really boggled me the fact that you could have two browsers that were just talking directly to each other. I was like that doesn't make sense. Browsers are a client like they will send out a request to a port. They're not going to be listening on a port. This doesn't make any sense. Go home JavaScript you're drunk. Now obviously there's a lot more moving parts for how this works. One of them is the use of things like the session description protocol. So if you've done work in SIP or VoIP you'll recognize this sort of stuff because this is how phones figure out how to work on a VoIP network. SDP is needed within the WebRTC peer connection because the two browsers need to know how to talk to each other. Because they do talk to each other. Now WebRTC itself doesn't actually specify how you share this signaling information. They just say that you do in fact have to share it. So in many instances they kind of say there will be a web application that when you first connect to this thing you'll share signaling data through there but then after you've established connectivity you can just talk directly to each other. We actually have used this capability within B for a couple of years. So when this first came out in Chrome many versions ago the get internal IP WebRTC module was created because for WebRTC peer connections and session description protocol to work the DOM has to be able to determine the local IP addresses of your computer. So that's your IPv4 and your IPv6 plus also your internet IP addresses as well. So Firefox and Chrome have WebRTC enabled by default so in case you didn't know like if you're using those browsers like and I think New York Times actually were just pinged on it recently they were using this technology to find internal IP addresses of LANs and stuff and organizations. It's on by default so go the internet. This is more JavaScript that's just an extract of what it is but basically what's happening here is down the bottom the JavaScript is creating a session description protocol offer and then that will cause the browser to basically kick off a bunch of requests within the browser to figure out its local STP information on those events we can extract IP addresses out of it. So this peer to peer stuff is really really great but obviously browsers are separated by firewalls right like a browser can't talk to a browser there's a firewall. This is an infosec reactions that says in firewall we trust. That's a tiger no it's a lion it's a female lion and some baby that's like completely oblivious. That's a duck I can't see from up here. So in an ideal world this is kind of how peer the web RTC peer connection would work. You'd have your signaling through the internet through a web application in our instance beef and then once connectivity is established media or data would start flowing between them but this is never the case like this is generally what we see. Now web RTC has methods to get around this. The first of which is stun servers or session traversal utilities for NAT. And basically it's a set of methods and technology that I'll provide for the ability for a browser for example to be able to get information about its IP address. Google run stun servers that you can use for free and I did in my demo. So you don't need to create these these exist. They're out there. Now if the NAT between these two devices is not symmetrical then peer to peer traffic won't work. And so at that point you're still kind of stuck. The browsers can figure out their IP addresses but they don't have data channels between each other and this is where the second component comes in and this is where the traversal using relays around NAT technology comes in. Turn servers are not necessarily free. There are some on the internet. Some of them you may be able to get onto without paying money. Some of them you maybe have to pay money. Depends on how cunning you are. Maybe. There's also open source software so you can actually spend these up yourself if you want. I didn't touch this in my demos because it wasn't in the context I guess I was working in. And basically the idea is that these things can take the handshake of an ITC peer connection and then you can just tunnel the data through that. So the browsers think that they're next to each other but they're in fact not. More Australians and people that are kind of Australian. Now this is all pretty complicated so to wrap this all together WebRTC uses this technology called interactive connectivity establishment protocol or ICE. And basically ICE is used to kind of encapsulate these protocols and basically helps you determine the best way to communicate from peer to peer. It's kind of like the Chrome way. Let's make it as simple as we possibly can. So let's set the scene. You're targeting an organization and you've shifted your focus to the internal resources and you're going to try and exploit their internal web apps and do some fingerprinting and try and do some social engineering stuff against internal guys. And you know you're allowed to use a tool like beef. So step one, obviously hook the browsers. So maybe you found a forum that a bunch of their engineers are on and you're able to kind of exploit a stored cross-site scripting vulnerability and you put a JavaScript payload up there or whatever. And then just like normal you have these two browsers which are talking about the server. At this point with the webRTC extension enabled you will also be able to kind of start to command them. So at this point you basically tell one to be the caller, one to be the receiver. The caller establishes its session description protocol information and sends the signaling information back up to the beef server as the signaling server which then gets kind of sent back down to the receiver who then goes okay cool now I've got this offer. I'm going to build my own session description protocol to get my own IP information and listening UDP ports and so on. Send that back up to beef. That goes back to the caller. At that point both browsers have enough IP information about each other that they can start actually trying to talk to each other directly. And if all things go well they do. And then they can also do things like they've established a data channel. So that's kind of after a peer, once a peer connection is established you have another event handled to up your data channels. But the browsers are still hooked. They're still talking to your beef server. It's really really cool that they're talking to each other but we still haven't gotten around that problem. They're still giving away your beef server. There's still obviously a problem. So this is where obviously because JavaScript is JavaScript, you can use commands that I've put into the web RTC extension inside a beef to tell one browser to command another to go to health mode as in stop talking to the beef server. You can only talk to me now. And then you can obviously use that channel to send commands through it as well. So enough talking. Let's look at this thing. This is going to be fun. I can't see it. What? You wish man. I've seen you do that. That did not end well. So we've started beef. I've got two Chrome browsers side by side here. So the one on the left will be browser one. And the one on the right will be browser two. And I've also got the console open. So I've turned on the both messages so you'll start to see stuff happen. So this is just one of the default hooks that exist within beef. And then once again, you jump back over to beef and you'll see you've now got two online browsers. And if you scroll down, you'll see that we've also determined that web RTC is enabled. So if that doesn't say yes, this won't work. And it won't say yes in Internet Explorer. And I think Safari works, I'm not too sure. I also, to make this fun, I hooked in a bunch of other browsers. So I've got a different Chrome on a different computer. I've got a Chrome on an Android as well. Oh, and I did it in Firefox. Now the first time I did this research, I couldn't ever get this to work. I have now since gotten that, I've gotten past that problem. So Firefox now works fine. So we've got five browsers hooked. That's lovely. And we've got some new UI options. So you can right click a browser and go set as the web RTC caller. And then select a different one and go set as the receiver and go. And then you can click on a browser and there's a new tab called web RTC. And in there you can see the list of your peers and the status of their connectivity. Now in the browsers, there's been a lot of commands and stuff that have come up. And once that kind of connectivity has occurred, you'll see their connected status has gone into connected. So they now have a connection between each other. And I'll kind of walk through what's happening with the peer connection because the verbose messaging is relatively useful. So this browser on the left is the caller. And the first thing they do is they create the peer connection object with a bunch of settings that we set. And then it basically starts to do that, it has to build the session description offer. So this is the signal they get sent over to the receiver. So it builds this offer and then it builds a bunch of ICE candidates. So these are IP addresses and UDP ports and TCP ports that I should be able to accept the data channel on once everything is going. So it sends those signals up to beef and then it'll wait for the guy to send the answer back. So obviously the receiver starts receiving those messages and it's waiting for that message to be received. So it kind of goes like I've got this ICE candidate and I can't use that. And then finally it receives the offer message and it goes awesome. I'm now ready to kind of kick off my own peer connection object. It builds its own session description. It sends back an answer and also a bunch of TCP and UDP ports and IP addresses. This is how you can talk to me. That signal against head back. I'm surprised this stuff works actually. So at this point now they each have enough information about each other. They can start trying to communicate directly with each other. And once the ICE state goes into a connected or complete state, they're actually connected. So those two browsers they now have an asynchronous data channel between each other. Yay. And what we're going to do is we're going to do like a star. So I'm going to make them all connect to browser number one. And you'll see slowly grow. Bless you. It goes on tight. Getting Firefox to work was an actual real pain in the ass because they changed their web RTC implementation maybe five months ago. And then I got really drunk and I couldn't fix it and then I tried it when I was sober and I got it to work. Whether or not that's scientific proof of you get more stuff done without alcohol I don't know. I'm only a computer person. So at this point now we basically got each of the browsers connected to browser number one and that connection status gets polled and updated all the time so you can't see that column but there's like a date. And if we check the web RTC tab on the rest of the browsers you'll see that they're connected just to number one. Now what we can do from here is which also we couldn't do previously is we can pull up a module. So for example detect one of the browsers and go execute this module. And this will basically build the beef module kind of change some of the beef.net.send commands base 64 up, send it over the data channel, execute it on the peer and send the response back. So browser one send the command to browser two, detect last pass it couldn't determine that last pass was there. You can do it the opposite way. So browser two is running that command against browser one and send last pass because the DOM has been influenced by last pass. And that browser has last pass. So that's basically a command module dynamically kind of going across the data channel which is kind of cool. And the last pass module is pretty interesting as well. But obviously as you can see on the left all these browsers are still, they're still online. They're still talking to the beef server. So the option clicking now is stealth. So what we'll start to see now is each of these browsers will stop talking to the beef server and eventually they'll drop off the online folder. The admin UI has like a timing period of maybe 30 seconds or so. They take a little bit before they disappear off that column on the left so you'll see me refresh the browser. And once the browser is stealthed it starts sending a heartbeat message back over that data channel so it's still there. So you'll see eventually they'll fall out of the online folder and into the offline folder except for number one. So here's the only browser that we're still actively talking to. But they're still stealthed and we can still communicate with them. And this gets really interesting if you obviously jump into the browsers and you pull up the network tab because you'll see in the stealth browsers they're not making any web requests, they're not making any web requests. So you'll see I clear the network tab. Browser one is obviously actively talking to beef and browser two will no longer send any HTTP get requests. But you can still control it. JavaScript is pretty cool, huh? And just to demonstrate that there's like a bi-directional data channel available I use the silly prompt command. I'll send that over to one of the developers. It's not subtle but it's an easy example. It's one step up from doing an alert dialogue. At the moment running the command modules in the admin UI is still pretty gritty like you've got to put in numbers and do JSON and shit because the way that we build the actual command module tab inside of XJS is horrible. It's like a horrible nightmare. I want to get away from XJS. I'm pretty sure McKellie does as well. This is a great example. And you'll see the dialogue pop up and it's like, hey, how you doing? And I'm like, what? Sweet, thanks Defcon. And I'll send it back. The response will come back into the WebRTC command results tab. So we've got that data back and you'll notice that the browser did not send any data at all to the beef server. So if you're sitting there monitoring your network egress points, that browser is not talking to the beef server. Like always I like to kind of show one of my favorite beef modules towards the end of my demos. I'm searching for the term Rick. That's my favorite. What? That sucks. So there's a few things happening under the hood. 10 minutes. A few things happening under the hood for beef to kind of behave in this way. I'm going to run fairly quickly over some snippets of terrible Ruby that I've done and some JavaScript. The first thing is that we have to establish some new database models inside of beef to be able to handle signaling messages and command module execution and other payloads and other things to communicate the specific RTC stuff to the browser. This is another one of the data models. Then we have done like an API hook. Actually for those who haven't developed in beef, one of the things I really like about it is it's super extendable. So I was able to basically interact with the hook.js dynamic construction through an extension. So it's one of those things where it's like if you want to play around with some of this stuff or if you're doing research in like malicious JavaScript or things inside the DOM, definitely check out beef. So this add RTC signal and basically it runs every time the hook is generated and it will add signaling messages if they're queued up inside of the database. The handlers define some new beef server URL endpoints. So these are the endpoints that when the browsers are sending RTC specific messages back into beef they hit these endpoints. We have some restful API. So most of the admin UI you can actually do from the, in fact all from the restful API. When I first demonstrated this I was doing it all on the interactive console but that shit is severely broken right now because of Ruby 2.2 and threads and jobs and stuff. Then obviously you kind of wrap it around beef's extension API. So you mount these handlers and you kind of set everything else up to work. Now the last piece of the pie is the core client side beef WebRTC JavaScript magic. And I am like I'm a terrible developer. I kind of like to think that I know what I'm doing but if I'm doing software development like this is mainly me I'm like on a computer with my elbows and I'll brute force it with my elbows until things work. It's 600 lines of JavaScript. Seriously freaking kill me. But it actually works. So kudos to JavaScript for letting me suck at it. And in the heart of it is the kind of obviously brushing over 600 lines of code right in the middle is kind of these event handling logic. So if I receive a data channel that is like exclamation go stealth I'm going to go into my stealth mode and kick off a bunch of timers and do a bunch of other stuff. If I receive an end stealth I'm going to come out of that state, execute arbitrary JavaScript, execute base 64 JavaScript or whatever. Now there are a bunch of issues with this. This one was an old issue. I got over that hurdle. Radical. Right at the beginning during the establishment of the peer connection there's a reliability option that you use. Now when I was first doing this they were recommending it set to reliability false. And this will by default try and use UDP between the browsers. Now I never had problems with it. So even though I turned off reliability which is a terrible name for it. I had peers connected for hours and even though I turned off reliability apparently Chrome now you can turn this to true and try and use TCP. Now I don't play around with that but could be better. I'm not entirely sure. Obviously Internet Explorer sucks. Edge does not help. Microsoft Microsoft they talk so much about like modern web tech we're embracing it. You can do all your modern web stuff in Edge and whatever. They're implementing this bizarre subset of some of the WebRTC functionality just so they can bring Skype to browsers and that's it. And Chrome and Firefox have had this for maybe two or three years. I'm honestly surprised. It's kind of, it's shocking. Now obviously one other thing is the signaling component requires communicating back to the beef server. If a browser is stealthed it doesn't deliver. So if the browser starts to move around and IP addresses start to change the code currently does not handle that gracefully at all. It's terrible. And obviously you have to touch the beef server at least once or twice. So you know I'd like to think that you can get away with not having any interactivity with beef but you got to let it lick you on the face at least once. Well maybe twice. That dog is so not happy. And also if you're into incident response this stuff is pretty tricky. So this is another one of the infosec reactions that I yanked and it says incident response team after a late night weekend incident. Carol. If you're monitoring your egress you'll spot a browser potentially talking to beef. You might not spot the rest of them. Obviously in my example it was a star configuration but you can do logic to kind of pass around. I'm going to talk to beef. I'm going to talk to beef. I'm going to run a command module. Share the results with all my peers. If I lose a peer it doesn't matter because all the results are everywhere else. So this stuff can certainly be a lot more advanced than it is right now. Not that it matters because the virus total doesn't pick up on the default beef hook anyway. From time to time this might hit a one or a two and then we change the date because there were some guys that they did a chrome extension to detect beef because there were certain signature patterns in the cookies that were done. McKellie within four hours or something he's like push the change and it's gone. They make a change and then two hours later he makes another change and they have just like this is ridiculous. We're not doing this anymore. Because really we're just doing what JavaScript is meant to do. Now obviously because of those issues there's a bunch of things that I would like to do better. There's open source turn implementations it would be interesting to actually integrate that into beef so if you're behind firewalls you kind of would be able to do it. Handle those peer termination events better. Like there's stuff that you can do there which I'm not doing. Obviously round robbing the peers and I've actually run this in a bunch of corporates and I'm always surprised the traffic quite often does make its proxy style environments. That could be interesting. And that kind of comes to the end of my talk. I need to call some shout outs. Wade who's not here who's a freaking lovely dude. McKellie who is here. He's lovely as well. Obviously everyone that helps with beef and there's probably people in the room or at the event that have contributed stuff to beef come and say hi I will buy you a beer. I fucking love all you guys. As well there was the three of us that kind of managed it. There was tens of other people that also helped contribute. Shout outs to my old dudes in Australia. Everyone I talked shit on Twitter with and my wife and baby thank you very much. I think I've got two minutes for questions. So if anyone has a question I'll probably answer half of the question. I'll repel and hear you. Okay so the question was Christian you're really handsome. How do you maintain those stunning good looks and work on open source software and work and have a family and shit and it's basically just beer and eatin' terrible. Any other questions? Yeah over there. Okay so the question was what tool do I use to debug JavaScript? That's a really interesting question. So Rapid7 did an open source security matters last night or the night before and I did a little beef talk and I basically said most of the JavaScript inside of beef is kind of 1990s JavaScript. ECMAScript 6 and all the modern stuff that's coming out in JavaScript we're not really using too much of that. We're also like not doing a lot of dynamic loading using a lot of the technology that people use like browserifying that sort of stuff. We don't test like we don't but I think some of the guys might use tools and stuff to help them debug JavaScript I debug it by basically like console.logging and opening up a console log which is terrible. I'm getting thumbs up. It's the terrible hack way to do it. I think that's what he's trying to say. We know I think it's just one of those things because mostly people are trying to squeeze stuff out in a really short period of time. A lot of the testing framework is not as mature as it probably should be. And the use of XJS for example to me is a really big indicator that there's not been love as much for the project over the last couple of years as it probably should be. Michele's been doing some crazy cool shit with the auto rules engine stuff. I'm not too sure if you guys would have seen that. If you want to talk to him about it definitely hit it up. Feature wise that's probably the biggest thing that we've seen over the last couple of years but no I'm terrible I don't have a script. I don't have any good way to debug it. Ruby side I'm also the same. I just put puts everywhere. So I'm shit at that as well. And these guys are all like use Ruby mind. Like do debugging properly you plebian and I'm like I computer really good. Fuck it. Any other questions? No I'm out. Guys thank you so much.