BSidesIOWA 2015 Track2: Assessing Network Sandboxes by Jared McLaren

Okay, so we're going to be talking about assessing network sandboxing solutions. And a quick start about me, one of the obligatory slides. Uh I'm Jared McLaren. I've been working here in town for about 15 years or so. um worked with the state government for a bit, a couple financial institutions and uh now work for a health company downtown. Um kind of the alphabet soup as far as you know security certifications go yada yada. U personal side, I'm a competitive cyclist, big Belgian beer fan and a new father. So I'll thumbs up to the Belgian beer and the new father over there. All right. Um so coffee is hopefully going to work its wonders and you won't see me

asleep at the wheel today. So just throw something at me if I go down highle overview of what we're looking at today. So you'll see a few different designs and architectures of some of these systems. We'll discuss that. Maybe some product considerations. They all have their own feature sets. Specialize in certain things. Some are better in some areas than others. How are we going to then assess these products? Take a look at if they do what they say they're going to do. And then um we're going to attack them and end with a real world scenario that I believe is the first network-based sandbox breakout in one of these environments. So to kind of level set on this one

standard definition, this is how I'm going to define it for this presentation. It's network sandboxing. We're basically talking about this is an environment where we're going to run and detonate code. We're going to see what it does. We're going to see if it's malicious and we're going to look for signs of exploitation coming out of that. So, Fire Eye being the prime example in the market space of this one. We've all heard of them, know what they do. Um, so kind of think of them um, you know, throughout this presentation is that's kind of the general theme of these types of boxes we're talking about. And as far as design and architecture goes, it seems there are about three

general styles. um inline blocking may be one certain style that you see and sometimes that's like uh PaloAlto is a perfect example. They've got I believe it's their wildfire service uh so they can take a look at malware coming in and out and they're right there in line and they can block when they see certain things coming in. Uh so pretty reactive and they're, you know, dead in the network if you see anything bad coming through. From a network tap and analysis standpoint, a lot of people use Fire Eye this way. maybe uh you know stick your core uh feed right to the right to the fire eye. It'll take a look at the traffic, parse out files that it sees

going across over you know HTTP, POP 3, whatever uh whatever protocols it understands, grabs those files, sends them off to its uh own network stack to and sandbox to detonate in there. And then there are a few in the marketplace, excuse me, that do a centralized offloading architecture. And this is a really interesting one. you have to kind of get a little bit monolithic in your uh security endpoint protections and network protections for something like this to work because all the devices have to communicate seamlessly. Uh excuse me. A great example of this one is um Intel Security uh formerly McAfee their advanced threat defense product. Um that that one it works really nicely. Oh, excuse me.

works really nicely as far as integration goes with the network sensors. If they see something going across the wire, they can grab it right off, shove it to a centralized sandbox, so those network sensors aren't spending their time spinning on a sandbox or the end points. And that's a pretty interesting perspective because if you have a sensor on an endpoint, it can see things post SSL. So, it's a little bit better at seeing things where uh transport encryption may block what a network sensor can see. And as far as product considerations go, these will vary uh a little bit based on one of those three styles and design that you're going to be looking at.

First of all, Fireey, great example here. Um you'll see a lot of those licensed based on bandwidth. So how many of those do you need to deploy? Uh maybe you want one at your edge, probably the best point where you're going to be looking at that. Um the main product might not work with your email system. So you may need to purchase an email system uh dedicated to analyzing malware as well. And then uh stepping back to the uh MAC ATD uh deployment, maybe it's a uh centralized sandbox architecture. So it may be in one of those environments, you buy one solution and everything feeds to that. Um if you get into you know the fire eye for example

and bandwidth limitations you may end up buying one for your egress one for your partner networks one that watches uh certain things inside of your network. So you know it can really start affecting the budget pretty quickly depending on what architecture and design your product has. And from a sandboxed system images standpoint um I've heard a lot of things from the vendors on um on what they recommend for deploying. Some people say, "We'll throw on a Windows XP Service Pack 2 unpatched and uh you know, Office 97 on there. We'll just catch everything we can." I mean, show of hands, how many people out there run all that on their network? Nobody. So, when um when you see vendors like Fire

Eye saying that they never have false positives, it's I find that a little misleading. It's a false positive to me if it's not something that's going to actually exploit my network. So, always check if you can upload a gold image of what you have on your network to one of these boxes. And there may be some limitations to that as well because some of them have size limitations of the actual uh images that you can upload. So, make sure that you're compatible with that as well. It may um limit your deployment to not being able to install Office on it because that makes it too big. So, just a few considerations there. And let's say you buy this big

box that can run, you know, 80 concurrent images and just fire everything that you can shove it in the sandbox and it just keeps churning. Well, as far as I know, Forinet is the only device out there that actually licenses those images that you're running in there. So, keep that in mind from a cost standpoint because if you buy this big box that can run 80 images, you need to buy 80 licenses of whatever software you're running in there. That's kind of a hidden cost that and tends to come up that a lot of people don't think through.

So some of the things um network monitoring uh that may be something that you see on some of these devices. Fire is really good at that one. Uh you'll see that they also monitor the network connections for this is a known CNC channel. These are uh this is bad traffic coming out of here. They'll they'll really take a look at a lot of those other things. Uh maybe some DNS detection as well. uh we saw you know a DNS request from this box to a known bad domain. So those are some great features that you might not get from that centralized architecture. Um that's something that monitors the network can do. The uh having the ability to integrate

with some threat intelligence uh I heard that was the buzzword from last year. Sorry I'm a year behind but uh if you can integrate with any kind of threat intelligence that helps a lot. Um, I keep going back to some examples of uh, Intel Security and McAfee. They have a GTI, their global global threat intelligence. If you can start tying um, tying some of that information into your sandbox and sandboxing environment, you might have some efficiencies. We see that an MD5 hash sum matches. So, we know it's bad. We don't have to throw it off to the sandbox. Therefore, we saved a lot of time and analysis and we can shut it off a lot quicker.

And as that ties right into resource efficiency, some of these boxes, every single time they see a file, they shove it straight to the sandbox. Don't check anti virus first. Don't check if it's a known whitelisted file. And that's extremely resource intensive. And if I'm an attacker and I'm going after someone that I know has this on their network, I'm gonna send off, you know, 200 non-malicious files just to chug their time down on their sandbox environment and then, you know, slap my executable off in the middle of that and it's going to be a while before they catch on to my attack and, you know, maybe slide through at that point. Some considerations in the corporate

environment, too, is local versus cloud analysis. Um, and I know this is a pretty big one when take one step back. A lot of these products look at PDFs for malicious content. And in your corporate environment, you may have an imaging system that takes, I don't know, claims, reports, financial information, whatever, images it to PDFs. So, every time one of those is seen on the wire, it may be shoved off to a um to the cloud environment for a given vendor for analysis. and think about the considerations of that one from a compliance standpoint. So something to definitely keep in mind their efficiencies sending it off to the cloud because you know elasticity it can

be done pretty quickly but if it doesn't work with compliance then that's not something you want to go down. Not at all. And then one of the one of the more interesting features that you may see on a couple devices is the ability to add internet access to the sandbox. And we'll touch more on that one in a little while, but that's one you want to be extremely careful and deliberate about doing uh for multiple reasons. Um think about what's running in that environment that you're granting internet access to. You know, a lot of these products cover about the same protocols. I'll show an example on the next slide of some file types and such. um you know, HTTP, SMTP,

any clear text protocol, they're pretty good at doing. Uh anything encrypted, you know, good luck unless you have an SSL offloader or uh kind of stepping back to McAfee, a centralized design where the endpoints can grab things and send them in. Um just about all of them cover Office files, uh up to a certain version. um you a compatibility guide will show you which version they go up to, but if you're on the latest and greatest, there's a chance that there's going to be some lag in the marketplace before they can actually scan those latest files. Uh PDFs, pretty much everyone does that. So, you know, when when you're assessing um one of these devices, just get to know the

environment. What what can they do? What can they handle? Um as you're assessing them, take a look at, you know, transport layer encryption. Can they do anything with TLS? Do they um getting back to some of the network monitoring things, can they take a look at, okay, this is signed by a known bad certificate or or anything along those lines? And then as you're assessing this device and walking through it, just slowly raise the bar. As I've uh walked through some of these uh product assessments before, I'll start off with a known Trojan, then make my own executable, and then, you know, keep stepping it up. So here's a here's a nice example once again from the MAC ATD side. These are

the types of files that you'll typically see supported by some of these, you know, Windows uh Windows PE files, basically the executables, DLS, Office files, image files. Um, you know, if you've seen any of the u Microsoft bulletins in the last few years about the GDI library vulnerabilities, you know, a lot of those are in images. So, we see a lot of exploits going over those. So, honestly, kind of an important one to pay attention to. And um I love some of this information from an assessment standpoint. Um straight out of a public FAQ um you know a lot of high-end corporate products u they'll password protect a lot of their support documents but um Intel didn't do

it on this case. So if you want to bypass uh look at that first box up there um it'll show you these are the characters that you can use so that the sandbox environment will not assess that executable. So, if you can slide one of those in, uh you should be able to slide right through and the sandbox cannot analyze you. Um in the middle on the right side, there's the default password to the administrator account, the uh CLI admin, basically the command line interface via SSH. Um there are many many other uh integration accounts that are listed in their public FAQ. Uh the lower right hand corner talks about the uh operating systems that are supported.

I don't see Windows 8 on the list. So something to keep in mind when you're looking at these products as far as what they can support if you're a Citrix environment. Very important consideration as well because you're probably running a server OS and you know may throw some uh kinks into that. And then uh lower left hand corner of the screen here we've got uh these are the ports and communication protocols that are taking place on the back end for this sandboxing environment. So, um, personally, when I'm attacking a device, I just love gleaming all the information I can off a public site, and you find some pretty helpful information out there. So, thanks, McAfee.

And as far as the tools I go, we'll start getting into a little bit of the meat of the assessment process. Um, these are some of the some of the standard tools, plus a couple other um interesting tools that have come out recently. uh PEC cloak for example, that's one uh just very recently came out, kind of a proof of concept tool. I'll briefly touch on that one in a minute. Um but then some of these are pretty standard ones as well. So first step that I do when I'm assessing one of these boxes, metas-ploit is pretty much the the easiest thing out there, de facto standard as far as you know, your tool suite goes. Um, it's so easy to create

executables that are malicious. Um, you know, make them uh memory resident rather than on the disk. You you can do all kinds of pretty pretty fun magic with that. So, a standard executable. Um, my second bullet point there on MSF Venom. Um, if you've used any of this in the past, it used to be MSF encode and MSF payload. You could use some of that to wrap up an executable. It's all wrapped up in MSF Venom now. And that command line will basically just make you a reverse HTTPS. So encrypted uh a reverse interpreter shell which is basically uh metas-ploits command and control um type of uh type of backdoor executable where you can launch further

attacks. So nice standard command there to just make something baseline, shove it across the wire, see if uh see if the box catches it, see if it knows what's going on. Um, right off the bat on that very first bullet point, I can tell you one of the major market players doesn't play too well with that one. Um, just because, uh, it's a stager based payload. So when you execute it, it may or may not look malicious and then all of the, uh, actual bad juju comes in over the network and in memory only. And some of these guys, if they don't touch the disc, the product isn't going to find it. And then if you want to up the bar just

slightly using metas-ploit before we get to other techniques, um you can basically use a Trojan executable. And this is so easy to do. One of my favorites to do. Uh the first command line when you make it, it uses the built-in metas-ploit template, which a lot of anti virus vendors will pick that one up. Um it's really simple to grab your own executable and Trojanize it with um with basically your metas-ploit payload. It's as simple as - k for keep the existing functionality of this uh executable and then -x for the template. And I always use putty exe as a as a nice template because when you double click it, it stays open which means your session stays resonant. So

real easy executable to use and you know you'd be surprised how often just as much as that will bypass some of this. Uh Hyperion uh anyone used Hyperion before? Awesome. Um, you know, great easy tool. Uh, this one, um, pretty simple to use if you're a Ki Linux user out there. It's already on the system. It's just a matter of unzipping it, um, compiling it with the Windows compiler on there and then just running it via Wine on your Cali instance. So, you can do everything completely self-contained in Cali and it's as simple as a few command lines. And you can take that previous executable that you made in Metas-ploit for example uh run Hyperion

on that executable and make an output from that and then you have a crypted output that is a little bit more difficult for anti virus to catch. So another thing that you can use to throw that against the sandbox, see if they catch it. Um if they're truly doing huristic type analysis, they should catch it. And if they don't, you know, go back to your vendor and ask why you can't catch something as simple as that. And then the veil framework. Any veale users? Awesome. A few more. Few more. So, um, once again going back to Cali, pretty easy to get this installed on there. Just a couple apt gets. Um, run veil evasion directly, Python script, and

it's a complete menudriven system. It's so easy to use at that point. So you can tell it you want this payload, you know, just just basically drive down menu and and uh you can pretty easily get out a uh a nice executable that you can throw against your sandbox. Uh just another set of steps to test and see if it's uh going to catch that style. And PE Cloak, this one was was a really interesting read. Um I've got a link to this one in the references at the end. So, uh, the author of this one is his name escapes me at the moment, but the the author had, uh, taken a couple of the offensive security classes and they

talk about, you know, one of their classes is cracking the perimeter, getting malware past and past the perimeter and in so that you can start, you know, launching a social engineering attack or get Trojans through. And he wanted to find an easy way to write an encoding and decoding routine um, just using simple add, subtract, and exor functions. and um a way to bypass simple heristics on executables. And then um he used this concept he calls code caves to hide code within the executable in points that uh that anti virus doesn't expect to look but still doesn't set off heristics. So there are a few example command lines below. Um, this one it's hard to get it up and

running with some of the dependencies because they they're kind of documented out on this guy's link that I have at the end of the slides. Um, but it takes a while to get up and running. And then uh he has awesome examples right there on his website of this is how I bypassed uh Kaper Kas Kasperski, this is how I bypassed uh McAfee, this is how I bypassed security essentials. So there are working examples out there for every single one of these. So, another great thing to take, throw it at your sandbox. Um, it should bypass anti virus, but if it's a good sandbox, it should still catch that it's doing malicious things. If you're a scriptor, there are plenty

of programs out there to take your your Python, your Pearl, your VBS, whatever, and turn it into an executable. Um, this is, you know, one of the tricks that I use a lot of time. uh anti virus is never going to catch it because you're writing something custom and then turning it into an executable. So, it's a really easy way to to bypass some of the basic checks and get into a sandbox and see if it actually finds something malicious. Uh the the first link up there is to uh turn Pearl into an executable. And at the bottom there's a simple command line if you have the right module uh the PI installer module. um just a simple

oneline command line to turn a Python script into an executable. Um and another nice way, you know, if you're um pentesting, red teaming, uh just basically taking a Python script and running it in an environment that doesn't have Python, switch it to an executable using that command line, and now you've got a portable file. And this is one of my favorite tricks to do uh red teaming pen testing or uh when I do assessments like this VBS, it'll run on any Windows machine. It's easy to program, real simple. Um you can make something custom that you know is going to bypass anti virus or uh quite honestly a lot of these sandbox environments don't even test VBS. Um but

we can also then convert it to an executable that we can get to launch in a sandbox. Now, this is one of the techniques that I'll show a little bit later on that um I actually used against the McAfee ATD sandbox to to do some nice attacking. So, there's a built-in command on Windows that's been around for a while. It's called I express and it's basically uh think of it as an install shield program. So, uh one of the easiest ways to do this is you make your make your script that does VBS, you know, run a system command, net add user, whatever. um you launch I express you add your evil.vbs file to the

package that it's going to zip up and then on the next page you can say run this arbitrary command when you uh when you expand this package and you can just tell it run ccript evil.vbs. So basically it's packaging up your VBS and executing it once it's open. So, real easy way to turn a VBS file into an executable. And once again, it'll be your own custom script, which means it's going to bypass antiirus. There's no signature for it.

So, as you as you go through some of these different methods, you know, how did the product do? How did it how did it detect them? If it was an inline blocker, did it actually block it? What was the lag time between when it detected and when the block was in place? Um, how large was the sandbox backlog? Can it chug through this stuff pretty quickly? Um, or you know, McAfee picked on Fire Eye a while back saying that they could backlog their device so much that they could just start sending malware through the company and it wouldn't catch it because the backlog was so huge. So, keep special interest around that one. Um, can we and

basically on that same note, can we overload it with safe files, shove through a bunch of executables, a bunch of PDFs? If you can overload it, it's pretty easy to bypass at that point. And any sandbox network leakage, um, I had uh one one major vendor that I assessed, I uh at one point using some of these techniques on the last page, I got their device to talk out to my host on the internet. uh basically showing me that you're running this device on your network and their engineers called me up on the phone and said this is not possible. Our device is not meant to do that. Like well sorry here are the steps

to reproduce and they would not change their device until I gave them a packet capture which I didn't have. So there's a uh you know some of these vendors are vulnerable to this type of stuff. So, um, be sure to test them and if you do get a packet capture. Um, and then one of the more interesting things too, um, some of the stuff when I test it, I serve it up from a public IP address and maybe you send an email with a link to an executable and that's how you download it and test it. So, there's only one email address that you've ever sent that link to. Within five minutes, you'll start seeing that file be

requested from multiple servers around the world. And this ties back to some of those uh threat intelligence feeds. Um, a lot of these vendors feed this stuff right up to uh public cloud services that go out and verify from multiple geographic locations around the world to see if that file is available. And they use that to see if uh you're a malicious host, um if you're targeting a company directly or a region directly. So, uh, if you're testing this stuff from home on a product that you're assessing, don't get yourself blacklisted. You know, maybe maybe think about where you're serving some of this stuff up from or, uh, you know, Will's presentation earlier today talked a lot

about having host and changing IP addresses. So, maybe something to think about if you're doing a lot of this work. And then, you know, are there any telltale signs you're in a sand or signs that you're in a sandbox? You know, VMware checks, things like that. So talking a little bit more on internet access, this gets uh this gets pretty tricky. Uh going back to that example of using a uh a stager where the payload gets downloaded and it's all memory only. If if the sandbox that I did that on where it bypassed it, if they had internet access, they'd see that loader come in and they would see that it was malicious and they'd have the ability to

to flag on it. Um, but if they allowed internet access for that to happen, do you really want malware getting out to the internet from your company, maybe scanning others, attacking others? So, there's a there's a pretty fine balance you want to walk um if these products have the ability to add internet access. And one of the one of the biggest things you want to look for is okay, you have internet access, what port is it going out of? Um, can you imagine like first of all, where would you put the management interface on this device? Anyone shout it out? Where would you where would you put that on your network? A very safe, protected.

Exactly. Exactly. You want it somewhere where no one else can get to it. It's your device. You want to manage it there. So if the internet access comes out of that management interface, where do you think we're dumping this malware that we're knowingly running? So something to keep a very big eye on. Um this this does happen on these products. This does happen. And another thing to consider, you know, how long is the internet access open? Maybe we do a five minute window or um is it going to run as long as the malware keeps doing new stuff? So coming back to pick on McAfee again here just a little bit. Dead center in the middle of this quote talking about

internet access. Let's see what do we have. Threat advanced threat defense provides real internet connection through the management port by default. Something you want to pay attention to. This may be one of the biggest security companies on the planet, but that doesn't mean that everything right out of the box is the way you want it. And by the way, this was a one paragraph on page 234 of the guide. So, good luck. So, this is where the fun stuff starts for me. I I love getting vendor products in, attacking them. Um, okay, so we tested a little bit. What kind of malware can they pick up? That's great and all, but I love attacking the box

itself. What can what can we do with this device? You know, over the years, I found that security temp company does not not mean that it's a secure product. A lot of times, you know, people are real good at pointing fingers at other people who are doing things wrong, but don't look in at their own house. So, I love taking a look at those. So just about all these have web interfaces anymore and companies that specialize in security don't necessarily specialize in web development. So uh it's always good to perform a complete authorization and authentication audit of all the available pages out there because you'll be surprised what you can find. And on the sandbox guest, if there's any

way that you can access the guest, what type of services are listening on that box itself? Uh what type of network access does that box have? And then maybe on the uh network sandboxing appliance itself, what kind of ports are open on that? Just kind of get that footprint out and figure out what the attack surface is. And I have found the uh public help files to be extremely helpful. like we looked at a minute ago, some of the, you know, the administrator account, the command line administrator account. Um, if it integrates with a suite of products, there's usually a service account by default that's enabled and running with a default password uh on the box. So, something to keep in mind

there. And also um when you set up a guest VM and you deploy it on here, a lot of these want a uh a standard password. So so that the sandboxing environment can get in, make its changes, watch watch what the changes are. So if you know what the default password is to one of these guest VMs, maybe that's something that you can toss into your malware and have a little bit of fun with as you're assessing this device. And console access to the device. You would be surprised what you will find on some of these systems if you log in with their given console account that they give you and you start looking at bash

history. Um you may or may not find um debugging um debugging information, hidden shells, back doors that the vendor has put in for their own maintenance. um things that uh you can't find on Google but are right there and available. Um just about every demo device I've run across the prior customer did not wipe the system. Think about once again stepping back to all those PDFs that that may be flowing across the wire that these boxes take a look at. A lot of these also capture network logs. So there are pcaps out there. um you'll find some serious stuff on these boxes if you just simply log into their command line interface and start taking

a look around. And then um one little hint on a on a vendor on bottom if you can uh see what services are running on there and um you know a lot of things run on local host so you can't get to them over the network but SSH port forwarding can launch you into a local host listening service. So, hint hint. There's some good ones out there. So, getting into my real world example here a little bit. Now, this was fun. I nerd out on this stuff. I'm I just love breaking into It's fun. So, um there was a uh disclosure that came out uh just recently uh by Intel Security um basically back in uh December found a

way to break into one of their systems. And I'll kind of walk through the the attack here just a little bit. Um, you know, stepping back to ATD, this one's the centralized design. Got all the sensors, got all the endpoints. They dump files to a central location. Um, it does have the capability to have internet access out of their device. So, um, that kind of does and doesn't play into this scenario. So, when we have these products in and I take a look at them, total red team approach. um you know a little different between a penetration testing approach and a red team approach. Pentest approach um you have to find your way in. Red team approach you have access.

It's kind of shortcutting getting right to the point and going right at it. So the approach was basically give me the IP address of the of the box and that's it. Um let me take care of the rest from there. Um and we'll just start assessing it. So I had no um no knowledge of credentials on the box or anything. Just an IP address and then you know some simple standard tools. Windows, a browser, burp suite, end mapap, kind of start that route. So, one of the first things I like to do when I get one of these embedded devices is just browse to it in your web browser. What kind of at at the very

basic slash, you know, right right at the IP address slash, nothing else. What kind of JavaScript files does it start throwing out to you? What kind of includes are there? Um, you'll find a lot of the times you start getting all these include files that contain information about pages that you can get to once you're authenticated, but you're currently in an unauthenticated state. So, it's really easy to just start spidering it out. And a lot of times thing tools like the Burp Suite, they they can't quite break it down and find all those links and spider it out correctly. So, some manual sifting can can do a lot of good work for you. just sift through, search for PHP or

something like that and start finding those links and and checking them manually. Um, in in ATD in particular, they had tons of uh, you know, basically Ajax calls between the client and the server. And the more Ajax web 2.0 centric type application you have, the more of that logic that needs to live on the browser, which means there's a lot more fun stuff for us to look at and a lot bigger attack surface. So, JavaScript first of all gave me the blueprint to their API that they were using to make the JSON calls to the server. And it was it was a very simple header with a base 64 encoded username and password, just kind of like basic

authentication, pretty close to that. But the problem was they they did a pretty poor job of enforcing their own API across their application, which led to a good handful of things I'll discuss in a second. And then, you know, good old end map, toss it out there, see what ports are open, do some version scanning, figure out what kind of services you're looking at out there. So, uh, kind of stepping back to that that API header, um, I could toss in just about anything as long as it appeared to be a a valid string. Not even a valid value, just a value, a valid string, and sometimes it would just start returning me stuff. So, um,

found all kinds of discrepancies in how they integrated their own authentication scheme on their own product. And a couple of the more interesting ones, by the way, there were dozens that I that I sent to them and they had no questions back and said, "All right, we we've confirmed them all. You know, we'll we'll get these fixed." But a couple of the more interesting ones, um, there was a proxy and server configuration JSON call that you could do from an unauthenticated standpoint. And um I'll show an example of that one on the next page. And um also this was one of the few products that I had seen where they gave you access to their sandbox

environment so you could watch the malware running and and see what it was doing. And they used a VNC server to do that. And guess what? You could spawn and launch and log into from an unauthenticated user some of their VNC sessions. So to go over a couple of these more interesting calls in particular, uh the UN unauthenticated uh proxy check, that was the first one I mentioned on the last page. This one was great because when you logged in and made this unauthenticated request to the server, the server was actually the host that initiated the request. So from my browser, I could say, "Server, check this arbitrary host over here to see if it's an HTTP proxy." So you could tell

the server to connect out and the username, the password. It could just be arbitrary data. It it doesn't really matter what you put in there, but the server would attach that to a request that it would send over the internet even uh to an arbitrary port and IP of your choice. So kind of keep this one in mind as we walk a little bit further down the attack. And a bonus, nice denial of service. If I had a netcat listener that I told it to connect to, as long as I left that session open, the system froze. So uh there's no need to create a backlog in the sandbox environment. Just don't close a connection, launch your

malware and the entire system is pretty much frozen up. So they fixed that denialless service as well in this vulnerability in this advisory. Uh second one, the uh opening up a VNC session. Um it it tracks all of its malware through task ID. So if you keep hitting this open VNC uh.php PHP page and just iterate through a whole bunch of integers, you're eventually going to find a valid uh piece of malware that executed in the sandbox and it will fire up a sandbox and launch a VNC server so that you can log in. Um it's pretty obvious through an iterator when you get a hit and once you get that hit um you use a command

line uh VNC to just pop right into that um to that VNC server that opened up and um Oh yeah, that's anonymous. just enter no password. So you can pop right into that. So here's the command line to use to jump right into one of those sandbox that you unauthenticated uh that you initiated via an unauthenticated connection. Uh you can just jump right in there. No no password. Uh when once you start poking around the sandbox, um it runs on virtual box. You'll see Virtual Box artifacts out there. Uh so you start you quickly know you're running in a virtualized environment. Pretty obvious. Um, McAfee acquired Valid Edge a little while back to do some of their malware

analysis and there are signs of that all over the system. So, another easy sign that you're in a sandbox if you're malware. And Telnet, yes, they're running Telnet on these systems. There are a couple standard services that they require you to run if you're going to run this VM image in their sandbox, and Telnet is one of them. So, I think that'd be a pretty obvious sign if you're attacking a system and you saw a TNET that uh yeah, there's something going on. And they're very predictable IP addresses. Um I think everything was a slash 29 or a SL30. So, they're very predictable and incremental in the 1921 16850 range. And a very interesting aspect, so if you

don't enable internet access in their uh in their sandboxes, um it won't give you a gateway. But this gateway address is static and it's always available even if they say you don't have internet access. You may not be able to get out to the internet with it. But I'll show you a trick in a second that makes this one pretty important. And there's always an FTP server running on the gateway and you log into that with the credentials that they give you on their FAQ. So you can uh give a shot test all these default credentials right from some of the malware that you wrap up and send into the box. So, quick time travel here.

11 years ago, I reported what I thought was a bug to the Linux kernel and what I still think is a bug. Um, if you have a multi-homed system on a Linux box, BSD is different. BSD derivatives don't do this, but Linux derivatives, um, if you have two different IP addresses on two different interfaces, if you can reach this one over layer 2, you can address it at its uh, MAC address with this IP address, and it will send it through the box right over to this other interface over here. I thought this was a bug. I sent it to the Linux kernel uh described it to them and their quote back hosts normally will expect or will accept

packets for any local address regardless of which interface it was received on. That's not a bug. That's how almost everything works. So, um they saw no issue with routing between two different physical networks um through the same box. So, um you know, I did this attack the hard way when I found it and then you look at it. Oh, it's as simple as a route ad command. So, put that in your bag of tricks for a pen testing or red team engagement. A simple route ad command to this IP or excuse me to this MAC address will get you to this IP address even if they're on two physically separate networks. So, to take one step back in here, um

building up the attack, we started with how to make our own custom malware to get it to execute in the sandbox. So, we'll make one of those, shove it in. Um, we know that the gateway is predictable 1921 to take 50.1. Uh, we can use that bugzilla 2399 out of the Linux kernel. I can add um a route if you know the IP address of the uh management interface. you can simply add a route over 50.1 to that management interface and communicate right back to the to the main sandbox system without internet access being enabled whatsoever and start exploiting those exact unauthenticated bugs that we just walked through. So you can basically entirely own the system without internet access

enabled or anything. And if you don't know the IP address, I mean just about everyone out there uses an RFC 1918 address on their inside. So it's time consuming, but you can add a route to all the RFC1 1918 blocks and just start scanning and hopefully get a hit. And once you get that hit, you know that's going to be the management interface of the sandbox environment that you're in in this uh MAC ATD environment. So yeah, go back, exploit some of those unauthenticated web vones. I had three pages of them that I sent them. There's plenty of stuff. It's a ripe environment. Um, and stepping back to that uh proxy JSON call. So if that username and password can be

any arbitrary value and you can make the server connect out to the internet, you can use the ATD host itself as a proxy to excfiltrate data out of the network if the sandbox does not enable internet access. So this was a fun proof of concept. You can basically just plug anything in there and say, "Oh, send this to this IP address on this port." And you know, it'll just shove it right out for you. No internet access needed from the sandbox. Whoop. So, and if internet access is enabled, uh we saw back there on the McAfee uh um ATD on that page, um it's out of their management interface by default. So, you can start scanning right at the heart of

a network, that sweet gooey center that that Tom knows where all these fun devices live. So, um, you know, it's it's pretty much game over if if you do allow internet access out and you do have that on your internal interface. So, you know, this is that one attack scenario is by no means the only thing you can do with this. Um, target all those default accounts. There are tons of them out there. Um, hopefully anyone that installs this on their network changes every single password of every single default account or disables them, but you never know. uh target the web vulnerabilities. There were a ton of them. They fixed all of them that I

reported, but that doesn't mean those are the only ones. There may be plenty more out there. Uh they have FTP servers, SFTP servers running out there. Their FAQ shows all the services that are running on that host OS. So, start attacking sooner or later. Um one of those is going to have a public vulnerability against it. I mean, they use open source like everyone else. So, um you know, you have a good ripe target that you can jump across. denial of service. If you never close that netcat shell that you connect to from the check proxy command, you know, you may be able to shut down the box, freeze it up. And then uh xfiltration, that was nice and

easy to do over that helpful unauthenticated uh proxy check command we had. And if they have internet access enabled, get creative. You can do just about anything. Uh scan internal networks, scan external networks. Um, you could use you could uh wrap up malware that you send into a company. It gets detonated in an ATD and all of a sudden you start scanning uh one of their competitors and guess where it looks like it came from? Their network. I mean, just get creative. You can have some fun with this one. You wrap anything up, send it off. And the great thing about this entire thing, no one has to open up your malware. All it has

to do is cross the wire in that company because one of the network sensors out there is going to say, "Oh, I see this new file potentially malicious. Don't know what it is. Send it to the sandbox." So, you completely bypass social engineering with this type of attack. So, get a little creative when you start playing with some of these boxes out there and when you do some assessments. So, on the Rob Ford scale of problem seriousness, I don't know. This one might be up there. might be up there a little bit. I don't know. It was a fun one to work with. Had a good time. So, some of the lessons learned, know your pros, cons uh

on the major design. You know, put it on the network. Do you have a centralized design? Um know the imaging and uh image sizes, licensing, all those things that go into some of these devices. Uh test the product capabilities. Don't trust the vendor at their word. Uh throw some malware at it. Test a few things. um attack the box itself. You you would be surprised at what you find. Um be very deliberate on whether or not you allow internet access. There are pros, there are cons. If you do, don't make it the management interface. Isolate it off. Um you know, be smart about doing that. Um and assessing the product itself. You know, take a look at what VM or

virtualization technology it's using. A lot of them use Virtual Box. Uh, one of the major vendors out there uses a Linux kernelbased um, virtualization as well. So, um, do a little bit of research and you'll find some interesting attack surface and definitely wipe the system completely. Send them back a brick if you're testing out one of these things because you will find other customers data on there that did not. And with that, you know, few resources here at the end. Um Tom, do we know are we publishing these uh slides out on uh yeah your video we're recording it so available on YouTube. Great. Great. So uh slides are available or excuse me resources available there on the slides. Um and

then you know thank you um had fun doing this project kind of fun talking through it. So um any questions we have that we can talk through? Yes sir. So, uh, let's say, well, I I just asked the question, uh, if you have a sandbox set up, do you expect it to really offer anything against a targeted attacker who knows it's there? Absolutely. Uh, it'll still, um, it's still another hurdle. Um, they may slip up. Um, you know, there there are still a few things though incremental. Um, I think it does still help does still help. um if even if they know the exact product version things you have um maybe a patch will mix

things up. I don't know. Um but it's one of those things I would do regardless. Um but yeah, if it's if I'm targeting a company and I know they have McAfee ATD, um things will be a little bit different, but it'll still make me watch my steps. And then of course a counter to that is you have to balance that of course against the liabilities because you just demonstrated plenty of liabilities. true in the uh in the proper context they can they can be pretty dangerous and that to me ties back a lot to uh what kind of VM technology are they using like this one in particular um from the VM that they had I was able to

jump through um jump through a loop using the router to to get back to the host OS a lot of them um that's not it's not possible but some of them it is um and then uh absolutely a liability from the internet access standpoint point. Um, be very very careful about that one. Absolutely. Anyone else questions, comments? All right, cool. Thanks everybody. Oh, sorry. One in the back. One in the back.

Gotcha. From a from a signature base app.

Gotcha. Good point. Uh so the question was uh are you seeing anything anything cool nice features and any any cool things out there? Um the McAfee ATD system does a couple cool things. Uh Fire Eye for example um it might try and detonate something. Uh but if there's uh some script in there or something in the code that knows it's in a VM environment and won't fire off, it may not catch everything. uh McAfee ATD does it's it's a little bit of a misnomer but they call it static analysis. It will see what parts of the code did not detonate in that environment and also reports on those. So that was one of the really

cool features that that I've seen. Absolutely. Kind of hybrid and static. Yep. Yep. Yes sir. Huh. Is there any none of them?

Sure. So the question was, do the any of these vendors try and hide that they're running a VM? And you don't see too many that do. Um, you know, at the end of the day, there's only so much you can do. certain instructions will give away, certain assembly instructions will give away that you're in. Um, a lot of them don't even try and cover up from the software that's installed. Um, like ATD for example, it had the uh valid edge software installed on it. That's a malware analysis product. It had virtual box artifacts on it. That's clearly, you know, a virtual environment. So, some don't go through the steps of cleaning some of that stuff up. Um, I'd say uh

from what I could see from some of the Fire Eye stuff, it did a little bit better job. Um, but for the most part, you'll still find those remnants out there. Of all them that you tested, which one do you think? Um, I hate to give you the answer, but it depends. If you're a monolithic environment where you have a lot of uh products from the same vendor, you can take advantage of a centralized architecture and it can be a really good fit also from the standpoint that you don't need SSL decryption because the endpoints can grab the executables or files and send them off. So, that's a really great one if you're um a small

shop and you just have the budget for one device. U you know, something like a Fire Eye is pretty solid. Just grab that one device, pop it out on the wire and and it can take a look. So, um it it really really depends on a good fit. Anyone else? Great. Thanks, everybody. [Applause]