Intelligence led Penetration Testing

Thanks. Uh so yeah, I'm Cam Cannon. I'm from BAE and I'm going to talk about uh intelligenceled pentesting, but in specific the use of reversed malware uh in live pentests. Uh so one of the challenges that spawned the CBS program and uh STAR was that we were being asked to make things seem more real to to look more like attackers and less like pentesters. uh pentesters have like you know their own idea of uh of what attacks are like and we use our own tools and our own techniques each time and really what we're doing is is attacking as ourselves not as another person. So here came the the threat intelligence requirement of uh of

CBST. So yeah is the core message is that you know we need to to replicate attackers not just uh just do our own attacks. Uh and it's a sort of the reverse of what we've been doing in the pentitine team for quite a long time. We we've had tools created for testing purposes getting reused by malicious attackers in the wild. But what we want to do is use the the tools that mal malicious attackers have made for themselves uh and repurpose them for testing. However, being the risk adverse types that we are, we had to consider potential pitfalls, etc., etc. Um what are the technical issues? Whether this is actually going to be useful uh and

whether this is uh legal issues, whether we could break breaking the law. Uh, I don't want a a malware developer knocking on my door saying, "Hey, you owe me money for using my kit without my permission." Uh, and what are the safety issues? Could we actually compromise our client security? So, I'm going to go all the way through the the issues with that. Um, ordinarily, I'd have Adrien Nish, the the famed threat intelligence master with me to do the threat intelligence side of things. Uh, and I'm a layman at best at threat intelligence, but unfortunately, he's somewhere exotic right now doing something far more interesting, as usual. Uh so uh it's going to be me. Uh before I get into uh talking

about the malware that we've got, one of the questions I had previously and I kind of want to frame the talk with this because it was uh pretty fair was uh most of this just sounds like buzzwords. Uh it's you know star testing or red teaming from from yesterday year and what we've done is repackaged it and reabel it and I I that is a fair question. Um, it was a bit of a brutal question from uh from Crescon and it it threw me uh a loop, but um it's it's legit. And what I'd like to say is that uh it's very similar to red teaming. We use very similar techniques, but we refine them. We're much more restrained

and we try to mimic attacker behavior rather than saying I'm a pentester. I know how to do red teams and so I do red team that way. Um I think that's the big difference. So just put that in mind. Cool. So threat intelligence side of things. Um, Adrian will tell you that over the past couple of decades, the cyber threat landscape has evolved quite considerably. Back in the 1990s when he was testing and I was not, uh, the sort of threats that concerned people were the kind of lone hacker breaking into systems, the Kevin Mitnik and people like that doing freaking earlier. Um, they were the hobbyists who occasionally made money through sort of, you know,

winning phone competitions and cars and things like that, but it wasn't really a big um, a big financial gain for them. Uh, and their attack vectors were what we describe now as the front door. Uh so defending against them was reasonably straightforward. Making passwords more complex, moving away from three character passwords, that kind of thing, putting firewalls in and improving standard stuff. And then uh over the the turn of the millennium, we entered what uh Adrian has referred to as the virus era. He is got some very grand terms. Uh computer viruses did exist before 2000, but two things changed around this time. There was a huge increase in connectivity thanks to the internet and

expansion of features in Windows PCs and servers to exploit. Uh so yeah, you know, we start having the big name viruses coming out. It started to become more of a market to make malicious code and release it into the wild uh not just for fun. Uh the virus era apparently ends around 2006. But this isn't the end of the story. What happened was the coders found themselves being recruited into the offensive security market um by criminal groups, but also by nation states and other people. And we we started seeing more and more well-developed malware. And this is when we start getting interested in saying, "Hey, okay, this isn't just uh I exploit a vulnerability, I get a shell, and then

I exfiltrate to another place." It starts being sophisticated. It starts being interesting, and we start going, "Okay, these are proper zero days. Let's start reversing them and turning them into exploit code for our kit." Uh, and then what we're in now, um, is more of the professional era, uh, nation state attacks. And obviously, they're not all highly sophisticated. We've seen the comment crew, and they they're very basic attacks and that kind of thing. And I I don't really want to use the term AP um but I think that's probably how most people feel about where we are now. Um but I think uh this audience understands the challenges in keeping out a determined adversary using a

bespoke toolkit over a long time period. So let's let's look at some of the stuff that we've found. So um we're going to use or I'm going to go through some real examples that we've seen recently and they're kind of aligned to the basic attack model of uh star assessment or red team. So, uh, infiltration, evasion after getting a foothold, and then establishing a commander control channel to move data backwards and forwards and send commands. So, let's look at the Oh, no. Okay. The first one we're going to talk about is a uh watering hole attack and it's most by far the most common technique that we've had now. Uh, it used to be email and web compromise, but

it's now more specifically a watering hole attack. Uh whilst email is still very popular with actors using addition services to trick users, we've witnessed a big rise in the watering hole style of attack over recent years. Uh and you can see I mean there's no dates on that because Adrian doesn't like to make firm statements. It's easier for me if you laugh when I make jokes. This makes it much easier. Uh so basically the tactic behind watering hole attacks and this is a much more technical crowd than uh than I've previously presented to. So I'm I'm just going to skimp on this bit. But it's basically you you compromise a site that you know a user is going to use.

you put some exploit code on there and it redirects you to somewhere uh that you can put some proper exploit code or you just exploit them on site. Um so an attacker interested in compromising a government agency would place their religious code on sites such as embassies, think tanks, researchers and technology websites. Uh think tanks specifically have been known for or been seen by us to be exploited regularly. Uh so yeah, they do this technically by creating an iframe link on the type uh the target website. this specific example that we've seen often a single line of code just to force the browser to load external content. Um often as well it does checking at this

point to make sure that the uh targets going to be vulnerable otherwise it just leaves you on the normal site. Uh yeah so then our attacker on the other hand uh has some malicious code that they've hosted. Uh the iframe redirects you to it and they hack it. Oh, it used to be animated. It's not animated anymore. I'm sorry. uh some attackers are now adding IP whitelists into their watering holes to ensure that a very narrow set of uh targets like the high value ones, the government agencies and so on so forth. So they get compromised. So us, the hobbyists, the people who like to go and hunt these things and kick them in the

teeth uh aren't actually going to go to the place where the payload is hosted. So we won't see it. Um, this is a bit more uh sophisticated uh targeted attack. And we we see these things and we go, okay, are we are we still looking at a a group of individuals who are just motivated by ideology or by mainly financial gain or possibly just uh a bit of fun? Are we actually looking at someone now who's saying right, you know, I'm going after this government and so on so forth. I'm going to avoid using specific country names because I have a uh a contract of my head that says I can't use real names. So it

doesn't require any zero days and it's just cleverly crafted social engineering to run something that they don't realize is actually malware. Oh, it is animated. Okay, fair enough. Uh so um yeah, I'm going to go through the the pros and cons of like doing a watering hole attack, but I think that's kind of basic. What I really want to talk about later is uh the pros and cons of using somebody else's watering hole attack. Uh let's move on. Cool. So DL sideloading. Um we saw uh attack uh and we were asked to come and respond to attack in in the energy sector in uh 2014. Um it was there was three files that were dropped and they

were sideloaded by uh antivirus which was pretty cool. Uh that zlh.exe is a legitimately signed binary. Uh the DLL was the only bit that was different and it loaded the uh there we go and it loaded the data from a dot file. So the as far as the uh system was concerned that's a legitimate file loading uh an illegitimate DLL but because there's no restrictions on DLS that are being run it ran absolutely fine and uh it ran our data or the malicious users data and uh it caused some big problems. There we go. Xander's little helper ZLH I think is uh what we've called it. I'm not entirely sure of the country of origin of this uh product but

there you are. There we go. It's a sign binary. uh it isn't uh malicious and data is encrypted. It took us ages to go through it and yeah it cannot be addressed directly in Windows without breaking expected functionality. Instead it requires developers to ensure they code secure library loads aka that's not my problem. Uh and finally uh the last thing we're going to talk about is command control uh and doing it through uh JPEGs. Now, uh, yeah, I'll talk about some anecdotes around this later because this is kind of a basic attack that I've seen quite a few times and I think most people can see it as being a standard method of doing things. Um, but we were

going after one specific group uh, and they were using legitimate content on compromised websites to hide what they were doing. Uh, but one of the obvious ones, one of the things we're doing a lot was JPEG files. There we go. Uh, so yeah, covert spin actors and uh, they could update this in real time. So we were seeing the website, watching it over time and seeing these pictures change. Nothing else changed. So we pulled down the the JPEGs uh and god this is Adrian slides. Uh so yeah basically it ran uh commands and would exfiltrate data through the JPEG and then get its new command from the next JPEG and pull it down. Uh the

malware itself was just like a standard .exe. It wasn't that impressive. Um but this was just kind of an entertaining way like a diversionary way of of doing things that was a bit more distracting than what we'd usually see. There we go. Arrows. Cool. Um, so yeah, this is a redacted URL from the campaign we saw. Uh, I was going to take this out, but it's a US politician um, who is uh, runs his campaign from this website. Uh, we'll just call it Jim's website, but yeah, there was a contact button. It was really basic. It was small in the corner. I think it just said something like go. And inside that, they were providing the the encrypted data that

they'd excfiltrated. So there we are. Um, you look at it in in hex here. Uh, the highlighted by bites there denote the end of end of file delimiter for a JPEG. So, what's the rest of that afterwards? Uh, I don't hear you ask, but you would ask if we were having a onetoone. Uh, the renderer read down the bites until it hits these parabytes and then display the image and then after that it would it would just do nothing. So, this is where they were hiding their code. So, we perform basic bit flip. Uh, it turns it into ASKI and it looks like uh B64, but it's also a simple visioner visioner, however pronounce that cipher

on top of it. Uh this is a real example and it it it just returns an ID from the command but a standard Windows command. There we go. So that's the the code we had there to to reverse it. It's pretty basic. Um and there we are. So it sent the command and that's the the name of the machine there. Don't go googling that. You won't find anything. I'm I promise you. Cool. Um and yeah, there's another example uh that basically that's that's what it looks like once you reverse it in in Midway. Uh so when we run the malware executable, it now talks. So what we did was uh converted it so it would talk to

our server rather than their original one. Uh and since we knew the algorithm it was running, we just started sending commands to it to see what it was going through. Uh and um we worked out way of basically using it for ourselves. Uh running on our own servers and so on so forth. And these are all examples uh from the cases that our team, our threat intelligence team have uh done instant response for and also hunted down over time. And the actors behind them aren't always elite superhackers or whatever, but they've spent uh effort creating capability that will compromise and remain undetected on most enterprise networks. Uh we can certainly both tune penetration testing to map their

capabilities closer, but also gain inspiration from their techniques or even potentially repurpose the tools they created. Right, that's all the threat intelligence stuff done. That's the stuff I know nothing about, which is great. Cool. Um so yeah, practical considerations. um whether we can actually use these tools that we've found in the wild uh and whether we should just draw inspiration from them whether we can actually reverse them change the IP addresses to our own ones is is what I want to talk about and I think that's what the important thing is there so um let's talk about that watering hole attack uh the most primary one of the primary compromised methods we've seen uh delivering a watering hole attack

makes sense for a majority of uh for companies doing pentesting because it's a broadly applicable tool uh the issue lies however in delivery so I mean let's look at it from a practical consideration If we're doing a pentest on a specific organization, unless we comp one of their websites that they're using, maybe a web portal or an externally exposed homepage that users are likely to be using, it's it's not going to work, right? Because we can't just compromise arbitrary sites. That's out of scope. So, we now need to then contact them. Oh, saying, "Oh, hey, do you mind if we contact your third party?" And then we need to include them in the contract. And it becomes uh more

and more complicated. So, that's a bit of an issue uh of using watering hole attacks unless you want to come up with some fancy way of doing things. And so a solution to do this would be tying it with a fishing attack and a domain squatting typo squatting kind of attack. But then we're moving away from a pure watering hole attack which a an attacker would actually use. So we're we're having to to adapt the attack that uh that we want to replicate because we're incapable of doing it within contract limitations. So it it it doesn't really work. Um however, it does straddle both a user and attack and a browser security attack. So it's social engineering, but

you can also use it to attack a browser. So, we're doing multiple things here. Yeah, it's it's it's not ideal. Uh and and the biggest drawback of this is collateral damage because even though we can whitelist IP addresses, we don't know that those people that we're attacking are within scope. And generally speaking, we attempt as pentesters to avoid attacking users directly. Um it's difficult to to repudiate in those in those situations and you can often end up in what as I said collateral damage or attacking uh third parties or inscope employees when they're on their own systems at home. So it it's not a controllable thing. Um however uh we took one of the tools uh

to certain point where we could use it ourselves. Uh and that's the this is the the the command screen of it. Uh it's pretty cool. Um it was PHP so it was like trivial to reverse. Uh and it it redirected everything back to our code within a very short period of time. Um and you can run it from any web available web page. It comes with a broad range of functionality. Uh unfortunately you know as I said uh using this in anger using this in a pentest is quite difficult. Um and the biggest problem we have here as well is it looks exactly like a real uh attacker because it belongs to a real attacker.

So when we see uh something from metas-ploit or something like that aperture shell running on a system and they reported to the CISO and they go oh yeah that's fine it's likely to be the pentesters. when they see something that looks this dodgy uh if they do and uh report it back it's actually you know are they're going to take that step to go oh maybe I should call a pentesting company or immediately go that's probably not them that doesn't look like an established tool let's call the police it's not something to write off entirely uh but it's difficult to implement correctly or effectively in a test um though as a source of inspiration to design better implants uh

and explore alternative methods of exploiting a malicious file upload fluid vulnerability for example uh it's perfect um and dropping the shell but perhaps doing some sort of you know PHP functionality and and messing around with it might be a bit better than dropping this kind of thing. Uh so the DL sideloading um replicating this style of attack uh yourself given that the the as far as I'm aware the actual uh code for this style of attack isn't in a commercial product at the moment. I'm reasonably sure that's the case. It's definitely not in uh cobalt strike or your standard uh metas-ploit. Uh we would want to use the code that we've taken and reversed instead of trying to build it ourselves

which takes a long period of time or attempting to find some alternative some corporate alternative that would do it. Uh it works pretty well though and evades antivirus uh so um excuse me uh it evades host defense evasion antivirus and applike listing. So it's it's very good and it will go through where interpreter won't. Uh however, can we trust it? Uh and on the negative side, if we want to reuse the three file technique, we need to reverse the DL. We need to reverse the .exe to work out how that's calling across. And then we also need to decrypt the DAT to make sure it all matches. And the chances of us getting it wrong first

time, second time, third time increase. You know, it's not uh it's not a straightforward activity. uh and if we are to get round a well-implemented application whitelisting uh on a target system then we need to understand which applications are available on that system prior to doing the test and if at that point if we already know that then why are we doing this attack in the first place uh I mean this this technique is well known in the pentesting uh community DL side loading has been around for ages last time we did this talk somebody came up to us afterwards and said oh yeah I saw that in the 90s are we still talking about that and I was like yeah we

definitely are gives us something to do uh so the uh the JPEG uh Stego, the back and forwards, uh a friend of mine from the community, who shall remain unnamed, uh was pleaded for themselves a few weeks ago for putting together an impressive PNG Stego C2 channel. Uh and it was it was pretty cool. Uh unfortunately, when I told him that we reversed one about 6 months ago, uh that it was uh and ours worked much much better, he was a bit upset about it and he didn't shed tears, but you know, but the great thing about it is that the code is really really straightforward. you know, implementing hiding data in PGs is something we've been doing for

ages and making it look like memes in the case of this one or uh you know, standard uh upload buttons, contact buttons, really basic forward stuff. It's it's it's trivial. uh and using it uh using your own uh methods of doing things to do C C2 channels during a pentest uh shows to your um your client that you can come up with inventive ways of doing things but it also evades uh it also moves away from the the standard attacker right so if we're using the one that we've got it's assigned or not assigned binary but it's it's a recognized binary by antivirus everybody you know understands and sees that has seen that attack when we go and build

our own one in Python or go and build our own one bash or uh PowerShell suddenly we've gone around that and maybe we're predicting what's going to happen in the future but we're certainly not replicating the attacks that there are around now which is the whole point um so yeah I mean as I said before building something like this is pretty straightforward why would you use a dodgy sourced one instead of your own um and if we're aiming at uh sock and mitigation focused um uh pentests then you know we need to uh we need to make sure that we're replicating the attack in itself not just replicating something that we know is going to go through

antivirus because no one's ever seen it before. Um yeah. Uh so yeah, we we picked this um because it was something we'd seen recently. Uh and it was uh from one of the infamous AP groups which was attributed publicly to a government in the Far East last year. Uh and there's a lot of case history available that can be used to gain buyin from customers which is what we're looking for because we want to make sure it's real and other attack vectors other network defense teams face. you know, we we want to replicate all of those and it has the benefit of being HTTP based, which means it's really straightforward and often people or socks aren't tracking uh in

detail HTTP based traffic. Uh it's hard for IDS IPS to identify because it just looks like normal images. And if you don't do what our intern did, which was just make an image which had the hex of putty.exe in it and tried to just put that straight through and didn't understand why just putting uh headers and footers of uh PNG file and I didn't get it through uh AV. Yeah. Uh but on the con side of things, even though the binary hashes may change, it could still get picked up by EV if we use this uh this real one. And there's further risk here that the malware is associated with a known high-profile threat group,

though it could attract additional attention if uploaded to a online malware analysis site by the network defense team, which is standard practice. Uh and you know, we don't want uh four-letter agencies suddenly jumping on us and saying or suddenly jumping on the case and saying, "Okay, this is attributed to uh a government in in the east." uh and uh why is this suddenly up on the on this network? We need to go and investigate this. And it could be uh a very career-litting conversation to explain to somebody why uh we're using their tools uh and why it's turned up here. Uh cool. So um yeah, whilst falling whilst falling out of favor with the security research

community for misleading people into thinking they've seen a threat actor a style attacking an organization is pretty bad, it's probably not as bad as causing a national security incident. Uh and we could do this uh as some code is attributed back to a foreign intelligence services and uh we it shows up on the networks organizations in the UK. Uh and you know if this is a CNI company is where we're working with a lot uh it could get escalated quickly. Um, but I think just as important is that do we fully understand the the malware that we're trying to use in these tests? Have we fully reversed it? Um, and if we go and use it in a live

attack, I mean, we're obviously liable for the kit that we use. Um, and whilst we have a world-class reverse engineers who can pick apart malicious code like you know before they have their breakfast, there's always the possibility that some low-level functionality exists which may produce unexpected behavior and we could actually backdoor a customer's environment. Uh if you think about how we were getting malware through bouncer on uh the Google Play Store and that kind of stuff and you just leave it for a certain period of time and Bouncer wouldn't pick it up because it only watched it for a short period of time. It's it's the same kind of thing. We can only watch malicious code for so long

before it becomes a waste of time. You know, if we're using the the code from 6 months ago, yeah, okay, that's pretty reasonable. But if it's a year, two years. And I mean, is it it is reasonably farfetched to think that a malware has a command and control channel built into it that will only kick off after 2 years. But honestly, I don't know. I I I can't say in earnest that there is no functionality on here that I have not detected. And therefore, you know, I'm I'm worried about using it. Um, and another issue worth considering is if we use malicious tools uh for pentests, the the malware that we've um that we've reversed and we've put into

our own toolkits, um, we probably won't want to release that out to the community. Uh, we'd want to keep it to ourselves to give ourselves an edge in doing pentests. Uh, and I think one of the best things about this, the infosc community is the openness and people talking to each other and the organizations that put out the white papers and say, "Here's the code. Here's how you exploit it. this is the way you mitigate it and and use that to improve things. Uh I think this could reduce uh collaboration by uh us attempting to use those binaries and then go to the companies when we're bidding on uh CBST engagements and things like and saying

we have three zero days that no one's seen. Uh they replicate your attacker and uh we're not going to release them until we've used them on your system. That's actually that's quite bad. Uh yeah, and finally out there I hinted about this earlier. Uh it'd be interesting to to see if we do start doing this whether a hacker could claim intellectual property rights over a piece of code they've created and used maliciously. Uh I mean they're already in prison. They could pretty much make any uh case they want to at that point. And it's selfinccriminating to admit it, but you know if they're working for the government at that point or legally covered to build and deploy the malware,

then we could get into a new uncharted territory for international law and uh BAE's lawyers would go nuts. Uh yeah. Uh yeah. So in summary, we discussed the premise behind intelligence uh pentesting uh looking at mal using malware uh in pentests. Um we talked about what is being targeted, how it's being targeted and why. Uh and the the latter isn't important for the traditional IT or network defense team, but it is important for the business to understand why people are attacking them and whether they should change their behavior while rather than change their uh their security. uh there is a lot to be learned from threat intelligence and uh I'm really happy about the the CBS

scheme coming forward uh and that advancements in those fields uh generic techniques attackers are using but potentially also looking at deeper some of the specific cases and tools recovered and reverse engineered uh Adrian's team uh track over like a 100 threat actors using capabilities similar to what they said or what I said earlier uh so you know there's a lot to be learned from those people and closer work with them could be better uh and yeah I've spoken about the practical and ethical considerations of using malicious code in pentesting. Uh ultimately we're not going to say whether you should or you shouldn't but I think it's something that we need to have more discussion of uh because you

know we are pulling code out of malicious uh malicious binaries we are replicating them and honestly can you look at the security tools that you use and say that you put in anywhere near the amount of due diligence into those than people do into malware. Like my reverse engineers will spend ages and ages and ages going over a piece of malware. Whilst we do review the kit that we use, I think that the the weight is definitely in favor of the reverse engineers for how much time they spend on one specific binary. And I understand those way better than I understand some of the kit that we use. Uh so yeah, there are practical advantages, but

there's significant risk beyond. And uh my presentation today was more about getting discussion going rather than advocating particular approaches. So don't shoot me. Uh yeah, and some significant ethical and legal issues exist. Cool. That's the end of the talk. I'm happy to take any questions. I got some really brutal questions last time, so if you can beat that, uh, I'll be really happy.