From pocket to Pwn: How we hacked a multinational corp for $200

really interesting talk with loads of high level exploits. You're in the wrong you're in the wrong room. So, think about that. You can run away now if you want. >> I will start with the legal bit. We do talk about Bluetooth jamming in the in the in the talk. Um, a lot of a lot of the uh premise was around jamming Bluetooth and manipulating Bluetooth. Obviously, that's illegal, so we never did that. Um, but we will talk about the premise. We'll talk about how you can do it and and there's some good videos on YouTube using the same kit. It's readily available for well under $200. Um, but we just kind of prove it was a proof of

concept for us. We didn't we didn't go the extra mile and end up in prison. Um, yeah, and a lot of this talk is a combination of stuff we did as lab research and it was an amalgamation of two red teams we did for previous customers. Um, so yeah, there was no we we we do not encourage breaking the law in any way, shape, or form. Blah blah blah. So, a little bit about me. I'm Tim Ship. I'm the CTO and co-founder of Threat Lights. I've been running leading instant response teams and red teams globally for about 20 years. I'm still a serving major in the British Army Cyber Reserves. B I'm as I'm anme for red

teaming and blue teaming for British MOD. I'm looking around because one of my colleagues is in hidden in here somewhere but I can't see him. Um I say I've had past cyber security roles in Asentia, Cyber Reason, Semantic, Airbus, Talis and a few others and roughly led around 300 breaches and fortune 500 companies during those 20 years in in in my career. So this is a very Android heavy talk. uh my my history of with Android started in 2007 which is about a year before Android came out as a as an OS. I was working for Panasonic. We were doing mobile phones. So we were buying uh Windows mobile phones and Palm Pilots and hacking those trying to sort of get

get the ROMs off of HTC devices and put the ROMs onto onto those devices so we could see what Android was about so we could build our applications and get ahead of the game for when when it actually launched. Panasonic did re release a very pretty soft phone. Um their their sort of thousand flagship flagship uh IP phone. The Japanese team brought it over to the UK and within an hour I I had Doom on it. Um they weren't very happy about that. Touchscreen didn't work. So we tried Day of the Tentacle instead. So we could actually use the touchcreen for that. This this led to my first trip to Japan. I I was sent to Japan as naughty

boy to explain why I'd broken their brand new product and and how I'd broken it. And effectively that was that was my first entry into cyber security and everything basically went downhill from there. So anatomy of an attack. So the you know this this particular customer we've been working with them for several years. We'd done all of the usual spear fishing, smishing, you know, we we'd we we'd done dead drops, we'd done social engineering, we'd been in we'd been in with malicious USB keys and all all of that. And to be honest, they were really good and and we we you know, um we they weren't getting the return on the investment that they wanted and and

the guys weren't getting to do as much of the interesting stuff as they would like. So, we had a chat with them. We sort of we looked at the the whole the whole company and and how we could do something a bit different and you know how how we could get some good value for everybody and it became very apparent that um they they were doing the type of company they had they had they had their own um mobile app as part of their product. So they they had their own developers um and um so we thought well why why let's target the developers. Um, I wasn't allowed to kidnap, so that was out. So, so the next choice was, let's

see, let's see if we can compromise one of their devices.

So, yeah. So, the the techniques in scope were the sort of standard sym symmetrical red teaming, which you know, we we've done to death. Physical access, could we clone their cars? Could we tailgate in visioning? Again, we've done use compromise, passive compromise, etc. So, the the aim the the decision was made that we would do passive targeting of the developers and we would attempt to leverage those developers um because the assumption was they were developers. They were, you know, they were the guys actually writing the code. They probably already had rooted handsets. You know, they I I don't know if any of you are developers or work with developers. devel as an incident responder, developer is the bane of my life because

if anyone's going to do weird stuff on a machine, it's a developer. And when when you when you're threat hunting and trying to actually look for a threat, you end up chasing chasing them around. So say the possible challenges we had was, you know, these guys it was they had very good corporate security practices. They had good EDR, they had great sock. um you know whenever we tried exploitation you know and we we got we got we got access to a system they would they would they would get in very quickly their CNC and um you know it was it was they they made us work very hard for our money when when we got

into a job for them and the biggest limiting factor is we only had kind of two weeks to throw this together we you know there was no there wasn't we didn't have two months to write some fancy exploit code it was what we had on the shelves and what we had readily available to us literally in our pockets. So the possible infection vectors we had is is we we knew there was a lack of corporate ped policies. Um you know they it was it was bring your own device, do what you want with your own device. They were late stage startup. So you know they had you know they it was everyone was using their own mobile phones.

Everyone was using their their own Bluetooth devices. Uh we did note that the customer had a fleet of company electric cars. um they were all Teslas basically and and that that was that was an interesting vector for us. So we had the concept of what if we block what if we block the Bluetooth on on the Teslas masquerade as a Tesla and then when the user tries to connect to their connect to their car with their mobile phone we compromise their device and then we we use that as a as a as a way into the environment.

So, like I said, the the aim was deny the service, masquerade the device, and then exploit the device for further onward travel. So, as it happens, Tesla documents um all of their components online. It's very easy to find out exactly where where said um devices are. So on a Tesla Model 3, which is the what what these guys had as a company car, there there was a module under the under the Tesla badge on the bonnets and one under the Tesla badge on the rear of the vehicle. Don't know if you've ever seen a car computer $25 roughly. Well, maybe $30 now. It's basically a um a flipper zero that isn't $200. When I started doing

this talk, it was how can we do this? You know, we can compromise company for $200 because that was roughly what these are. I say these are these are 30 bucks and I I only need two of them. And the best magnets on so sticking on the Tesla was nice and easy. That's not very not not as magnetic as I thought it would be. More dramatic normally. So the plan was stick one of these on the front of the vehicle, stick one of these on the back of the vehicle and then use a flipper with uh a larger antenna to be, you know, to push the signal and have the user connect to me. So, the these devices don't have um all

the technology in them off the bat. So, they're 29 bucks for the device. And then with $15 worth of hardware that goes in there, those go in there. And you've got a Bluetooth jammer with roughly 2 m roughly 2 m uh effective range. And if you look on YouTube, there is a and if if you were to Google Google NRF24 on on YouTube, there is a Spanish gentleman demonstrating that exact hardware and and he's he's he's actually blocking Bluetooth in there. So the proposed attack vector was the two of these car computers, one on the front, one on the back, grand total of $95. And then we'd use the flipper zero to masquerade as the as the ve as the

vehicle user would connect and we would we would push the push the exploit code to him over Bluetooth. Problems we had Android 13 and 14 are pretty secure by design. Um you know they've come a long way in the in the past couple of years. If you look at any Android exploit stuff on on YouTube, it's all done in virtual machines or like very very old Android versions. And if you were to try it yourself, you wouldn't get very far. Um it's it's it is very well locked down in in their defense. So the getting an APK on it can be done, but that you know they they've gone to a lot of effort in in preventing malicious

APKs. you know, we we were able to create one, but it it that was that was the best part of those two two weeks was trying to create a malicious APK that we could get onto that envir get onto that device without without Android just blocking it out outright. Um, and also a lot of a lot of the exploits that you see for Android, it's just, oh, we'll just use ADB. You know, ADB typically requires you to actually be plugged in via USB, which kind of limits you, you know, unless you're sneaking behind somebody with a USB cable. It kind of limit limits limits the attack vectors. Yeah. Yeah. We we didn't try that. So, what's left?

Reinvention of the lowest of low tech solutions. USB rubber duckies have been around since 2010 and it was the old USB stick key logger where you know you you plug it into a device and it can effectively um it it masquerades as a keyboard or mouse. So it allows it allows keyboard strokes and mouse mouse inputs in very quick succession. So you know you can put in you know effectively put you know pump code into it very very quickly. But um we were using this over USB cuz it's built into the flippers by zero by by default and with a little bit of messing around we were able to get it working in the little car computers as well. So the

plan was USB rubber ducky over Wi-Fi is probably a better way of saying that. Um, and we we use that to em emulate a US key a USB keyboard to to input the button strokes with the intention of getting the user to download and execute a payload. And we did a pretty diagram for it. So attack blocks Wi-Fi with with the computer car effectively is unable to communicate with the phone and the phone is unable to communicate with the car. So this scenario is user gets into their car after work wants to put wants to put Spotify on and they can't connect. So, you know, they it's it's blocked and then we we push we push our

Bluetooth connectivity to them and then but instead we compromise the device and we have a demo. Well, we have a recording of a demo >> cuz there is zero chance of this working in the real world in front of 100 people. Trust me, I've done it. And this was the reason we used the flipper is because it has this lovely user interface that you can see in the top left. >> Can you see?

>> Excellent. So that's just me setting up going going to the relevant um app pack and enabling bad USB. So the the jamming is effectively done. Now the user with the phone on the right tries to pair to their their pesler for legal purposes.

Now this is this is massively slowed down. You know we I could I could get this to happen in a couple of seconds with very little on the user screen, but it makes for a really bad demo. So, I' I've deliberately slowed it down and and when we did it, we actually had it with a black screen overlaid over the top so that none of this was actually um we actually had a Tesla Tesla badge. Um so, pretty transparent to the user. So, there's no no human interaction from my end. The uh the the payload's been sent and the metasloit payload has been sent to the device over Bluetooth.

And then yeah in in in this in in the demo the the um Android device is already rooted. In the particular in the in the job that we did it wasn't and we had to use use our own um privilege escalation techniques. Obviously not going to show you that here cuz I want to use it again.

these ones. >> Thank you. So, that was the easy bit. um get you know met exploits been around for donkeys years. It is not very well supported or developed on Android anymore. We had to we had to modify some of the code to get it to work. Um it's it's been years since it's been updated. Um we weren't en able to enable persistence um whilst we were in Metas-Lit. Um and Android doesn't like um external APKs having adband connectivity. So you get about 3 minutes and then Android actually shuts that um external connectivity down. So you get you get to do a bit of enumeration. Um but you know like using tools like Drosa there wasn't enough time on

keyboard before and Android locked it all down. So we needed additional access to get further on in the environment. So in an ideal world getting remote access via ADB Android debug bridge um was the dream. Um, it would give us a more reliable shell and really allow us to further exploit the environment um, without having to rely on metas-loits slightly sketchy code. The downside was ADB is only designed to work over USB or local area network. Um, you know, the local area network is a relatively new feature. It's typically done via USB via devs. Um, that's how I've always used it. Um but we need to see if there was a way to bridge that

gap. Fortunately, there was. Um and you know, providing providing you do have um root access to device, you can you can just set um SE Linux to uh permissive and then set enforce to zero. Um and that that's it. You you can then you can then effectively use ADB over TCP. So we were able to create a remote listener using termox. So um through through the um through ADB we deployed Termax. We set the listener up on port 55555 cuz why not? Um and then once we start the service we were a effectively able to create a complete outbound connection from Android debug bridge out to our command and control server out in Google. So there's that diagram. The

beauty of that is that works over the customers 3G, 5G, Wi-Fi, whatever, whatever network they're on. Um, but when they take that device into the office and they plug that onto the corporate Wi-Fi, we're on the corporate Wi-Fi with a permanent remote shell back to that environment. Um, which was the exact aim that we had. So, what we were able to do with that is we had full persistence all of the time. we had all of the things that we could do with ADB anyway. Um all of the additional we we could modify modify Android effectively. Um but what what we were doing primarily was we were using things like socks proxies um to to allow us to run NMAP. Um we you

know we were able to do all of our enumeration all of our onward movement into the environment onto their domain controllers into their ES6i hypervisors all through that phone all all from the comfort of my own home own home at that point. Um and yeah it was we we were also able to get access to the devices uh user interface as well. So there was a tool called SCRC CPY probably needs a better name but once you you can actually you can actually have a remote remote session with that device and actually control that device you know almost remote desktop like so we have remote desktop to the device um to press any buttons if we wanted to you know inter interact

with any of the apps on the on that device but obviously we have complete remote shell also So further things that we need obviously this demo is very very loose in the sense it's it's it's the bare minimum to get get in and and and get what we needed done. Ideally we you know moving forward we'd want a more robust persistence mechanism. We'd want something that would survive a reboot. You know this is great. We've got a very you know we've got a we've got a pretty decent reverse shell but if that that device gets rebooted that's gone. So, you know, next steps is we need we need to move move away so that that's going to survive a

reboot. Obviously, you could see that the APKs were on the on that user's desktop as well. Um, you know, they're going to see those between with with their other apps. You need to hi hide those APK hide those APKs, hide those um icons. Um, we had a key logger. So, you know, we can key log key log harvest credentials. Um, you know, any any usernames, passwords, whatever else. Um, you know, WhatsApp chats, whatever they deal with that, what whatever they're doing with that phone, we would have we'd have access to log one all of those. But as I said, the big one for us is we were able to create reverse SSH uh tunnels and sock proxies so that you

know we could effectively connect our proper Carney box up through this device and and do all the things we could have done had we got you know had you got a real implant into into the environment all through this user's mobile phone and they didn't like that. So, lessons learned. It doesn't need to be clever, novel, pretty expensive, um, to actually, you know, be a pretty pretty pretty good attack vector. You know, we we we've we've we've spent a lot more money to get a lot less in in in a red teaming engagement. You know, this this was, you know, we said 200 bucks. Realistically, it was 90 bucks. Um, and we could probably get that down

cheaper. So, you know, budget is not a blocker where ingenuity exists and and leveraging non-standard approaches. ET reverse SSH, you know, can can get you a lot further than, you know, having to rely on spear fishing and getting a user to click a link and and so on and so forth. Anyone have any questions? >> Yes. So when you were trying to run the >> So the export itself took only took a couple of seconds to run and and the wor the worst case was there'd be someone driving around this particular state with two of these stuck to it. So we did think about putting a bit of string on it. So like put put it away.

But, you know, to to actually run the exploit it was it was it was literally 30 seconds and then once it was done um yeah, it was just like getting these off the car again was the uh the issue.

>> It didn't it wasn't even anything like anything like that. It was it I haven't experimented with what what you could do because you could you could technically inject the code on the fly. We we were just we were just browsing to a website downloading the APK and running the APK. could have done a lot fancier things with it.

>> Good question. >> Yeah. >> BYOD. >> Yeah. Have some have some BYOD policy. Have some something to monitor devices on on on those devices. Have some standardization. Um, yeah. Latest version, EDR, all that good stuff. at the back.

>> Sorry, you'll have to speak up. >> What did you accomplish by the end goal? >> So, the the end goal was to get into the customer environment and compromise the customer environment. So the all all of this was was just to get was just to get a footprint on on that customer's network and then and then exfiltrate data you know escalate privileges all that all the stuff you do in a typical red team engagement but with because they had they had a pretty decent EDR they had a very good sock and and you know they and they knew we were coming um they they they would find us pretty pretty regularly but this was this was

an attack vector where they weren't looking like they they didn't have EDR on the on that endpoint and we we were able to bypass a lot of their controls just by going in a completely different attack vector. >> Yes. >> So you specifically went for Android phones, but how did you know that the person you were targeting during your actual engagement had an Android phone? >> Um we we just we knew a few of them had Android, a few of them had had iPhone. We we deliberately deliberately picked the Android uh because the iPhone was too difficult if I'm if I'm perfectly honest. But like what did you like ask uh for a list of people that could have an

Android or were you just doing initial reconnaissance beforehand or >> I was just just stood in the car park looking very very very inre and yeah just seeing just seeing who you know seeing who had them at you know who had them at lunch who had them who had them walking to their vehicles because everyone walks around with them like this anyway. So, uh, you know, you don't have to spend too long there to understand who who who's going to be your target, but it was done it was done with that with then with them knowing as well. So, you know, it was kind of we say, "Right, we're going to use you and then we'll we'll use a a standardized

phone rather than take control of his phone because God knows what he's got on it and I I don't need that in my life. >> I don't need to see his photos." >> Yes. >> So, uh, the person Well, the car that you stuck them on They knew that you were doing that or were you doing like secretly like putting it on the card and then you had to take it off when they pass by? >> The plan was to do it secretly but it just it just felt a bit weird. So uh so we kind of so we kind of explained what we're doing and then you know we we would we we'd do it to somebody who

would we were working with one of their team effectively. Would have loved to have actually done it just yeah just crawling around the car park and them not knowing about it. But I think that's you know that's how you end up in jail. >> Yes. Yes. >> So after you um got initial access to the development and watch them through their environment, did you stay undetected in their environment? So like when you were doing enumeration by map um against their assets did they detect you at all the processor? >> Not until we got into the Windows environment. We we were able so we moved over to Linux, we moved over to the ESXi environment and um had had we not gone

into had we not gone into AD then then then we would have pretty much been undetected but that that wasn't our intent. You know we it was as much to test them as to test us. So we we could have stayed undetected for as long as we'd wanted to if had we had we not gone into EDR land. Oh god. Yes. >> Okay. Um, when it comes to the Bluetooth of the actual Tesla, >> did you guys just clone the name or did you actually clone the MAC address? I'm asking cuz there's some paranoid folk that have been like, "Oh, I want to click on Spotify. It's not working. Check it." You know, >> didn't need to clone the didn't need to

clone the MAC address. It just just enough to, you know, we could see what the we could see what the the car's name was and we just just cling that seemed to be enough. So if a par if a user was paranoid enough to say we just peruse then you could have been exposed because >> Abs. Absolutely. But so when when you sat in your car and you want to go home you just want Spotify to work don't you? It's >> I would be honest I'm a little tired myself. So I tend to tinker a lot and look at stuff like that. So unless you get someone that doesn't do that. >> Yeah. And and we if I was to do this

again, it'd be a lot more refined and and you know, I'd have a have a have a splash screen to to to hide the really hacky stuff that was going going on in the background. But hey, it worked. >> Yes. >> When you were getting remote access devices over the LAN, did the device have to have remote debugging enabled or did you get in some other way? >> Sorry, >> remote debugging. Did the device have to have remote debugging enabled priorly to get in or did you get in some other way? >> So we were just um just enabled just able to enable ADB and that was enough. >> Okay. >> And that that was that was it and then

anything we anything we need to enable we just did through ADB. >> Gotcha. >> to do the job. >> Yes. >> Um were these like work phones or were this just like people personal devices? Like did they have like profiles installed on it or >> the they were they were pretty much personal devices. So that they were kind of late late stage startup. They didn't have corporate devices. So even even the developers for the applications they did. No, that's so the the majority of them had personal devices, but the people who were doing the applications had they kind of had Pixels or they had they had kind of some generic phones. So that was what we were doing our testing

with a generic phone that was one of their ones that they' picked to be supported by the application because they had their own Android app that was part of their platform. >> Anybody else? >> What uh what was the kind of ultimate learnings for the customer? Did they add in B policy or they or was it more like because you laterally moved to VMware things like that they took the time to understand that more than the phone aspect. >> So they one of the recommendations was to have some form of monitoring on on your end devices on on your on your on your on your phones. Um and that that was that was the main

>> to look at like move to the Linux machine or like how to protect Linux machine access as well after >> well yeah I mean it just so happens that that's what my company does. So um >> so so we so we so we specialize in in protecting Linux devices. So they so that they so they use our our Linux Linux detections now our Mac detections because that that's that's what we do well. Yes. >> So uh after you got your uh initial foothold in the environment u getting off the phone when you were enumerating the network were you just kind of like blasting things to see like what was live or were you like more discreet with

like trying to isolate specific IPs to not alert anything? So initially initially we were being very discreet. So we we were doing very low level low-level sort of scanning we was kind of we were tunneling um uh blood hound and whatnot for it as well for for a point. Um but then as the as the investigation as it as it dragged on we we we did a lot more noisy things. It it was more more of a purple team than a red team if I'm honest. So you know we we kind of split it. So as as the as the week went on, we did we we sort of up the ante and made it louder and louder

and louder. >> Yes. >> So curiosity can tell what you did. >> No, we didn't do anything to Tesla, you know. No Teslas were hurt in the in the in the making. It just so happened that that was what it had. And you know, it's any any Bluetooth module you place that within 2 meters of it just gets jammed. So, it's not it's not, you know, the the Tesla wasn't at fault. It was it just happened to be the uh electric vehicle of opportunity. >> Any other takers? >> Yes. So would an NDM, you mentioned endpoint monitoring, would an MDM company solution have prevented you from being able to move off your project environment or would it not have made a

difference? >> Uh I I think something on on the on the mobile device would have would have been able to stop it. I mean there was there it was we were very obviously doing things we shouldn't have been doing on that phone and you know the you know the ADB making an outbound connection to the internet is uh I don't think you know don't think that's seen very often. >> So you know that that would be a very easy indicator for some some something pretty sketchy going on >> or just Android devices connected to Linux devices in general over over IP would have been would have been a weird one. So yeah, there there's plenty of

opportunities to see us, but nobody nobody's looking. >> Exactly. >> Yes. >> You had mentioned that Android the Android application would close your connection when you first did the attempt. How did you get the reverse shell to stay open long enough to be able to do the enumeration through the application on the phone when you're proxying? >> So that was that was why we needed the the ADB. So, so, so, so when when we were able to get the APK in and get and get the metas workshell, we had three minutes and then, you know, we had three three minutes to get the everything in place to then open open ADB and then and then get that next shell. Um, because

Android would just close it down and that that was that was a couple of tests that are are they on to us? I keep losing my shell. No, it was actually just Android doing doing a good job. Yes. >> Are you able to say what the recommended solution to that problem would have been? >> Which part? >> Uh how to not vulnerable to attack? >> It's a difficult one because it because it there was there was so many components to it and and I think like Android had done a very good a lot of good work with um preventing you installing malicious APKs. Like that was the that was the hardest part of the whole the whole thing was

getting an APK that would actually run. And um you can see in the demo it still winges that you're you're running a sketchy APK and you have to you know I I agree I I agree to run this malicious APK. Um so but I think in later I think in the very latest sort of in 15 I think they've improved that even further. >> Any more for anymore? We got one in the back.

Yeah. So just just through Android.

>> Not to my knowledge. We we we just we just enabled it and and and that was that.

>> Yes. Is that a common blind spot that you see where you won't trip off any alarms if you're staying in the Linux and virtualization environment versus hitting Windows? >> So much so I built a company around it. So yes, like what what we see with many with many ransomware attacks and whatnot now is they're they're coming into they're coming in through webshell or a VPN exploit. They're going straight to Linux, straight to ES6i, and they're just ransomware ransomware down from the hypervisor. They they don't touch Windows because EDR is hard. um and and if you can avoid it. Um and and that's that's what we're seeing on a on a weekly monthly basis now. So so we focus

on Linux detections now because that's that's our main battle space. >> Thanks. >> Any more? >> Yes. Is there any recommendations on the network side things production network?

>> Yeah, I mean not having not having a so not having corporate Wi-Fi is a a difficult one to say. Um but but yeah v decent vlanning would have would have been enough. Yeah some segregation. So mo mobile phones and and and company laptops were completely vanned off and then you could have some some upstream something upstream to prevent them from being able to get further up the network.

I think that's it. Thank you for listening.

>> I'm going to take a photo if you don't mind cuz that's a terrifying number of people sat in one room.