0:03Hello. So I'm Dan. I'm an engineer on Cloudflare's Red Team. And I'm here with Albert, who will introduce himself in a moment. And here, we're going to talk to you about the importance of fixing low severity bugs. Also, please fix your high severity bugs as well. But the low severity ones are the ones that sometimes get a little bit less attention. But we should talk about them too.

0:28I'm Albert. I work in the red team with Dan. Today we're going to talk a bit about red teaming, why it's important, how we do red teaming here at Cloudflare, and why we use low-severity bugs in our red teaming. Then Dan is going to take you through an exercise we did, and then I'm also going to talk about some of the tools we use for red teaming, like command and control, and then in the end we'll talk about what we did about the things we found in our exercise. Yeah, so red teaming, what is it and why does it matter? so Basically, red teaming is not a penetration test and it's also not vulnerability scanning Whereas a penetration test will usually focus on finding as many high -severity boxes possible covering a large surface Red teaming is really about defining an objective and then getting there the purpose is to emulate attackers, for instance, say, I want to get code execution, and then you act like an attacker until you get to that goal or you get caught.

1:34And often we do that through chaining bugs. We don't really care about the severity of a bug. If it helps us get closer to the goal we define, then we are very happy and the attackers think the same way. So, you might ask why bother with redseaming. me is quite important because it's the only realistic test you'll have of your actual detection and response capabilities because if you don't do it then someone less polite will do it for you and the point of red team is you try to find flaws that get you closer to your objective and it's useful because real breaches are usually not just one specific issue they are usually a chain of different issues that together cause impact and that's how real breaches happen as well so that's why we we look for that as well in red teaming.

2:24Red teaming kind of helps you show exactly where your assumptions fail you might think that some systems are a cure or that your your methods are good or your detections work correctly but but red teaming tries to find those issues before someone else does it for you and it also provides a valuable learning opportunity for your blue team to then go back and say hey actually we we found these issues and then we can improve our detections based on that and next Dan will go through how we do red teaming at Laufler. So at Laufler we red team in maybe a slightly different way to a lot of other places. We're an internal team we know the environment sometimes we have access to internal systems which we can look at to learn which just speeds us up when we're doing things. When you're red teaming if you know what the environment is if you know what the else might look like you can save a lot of time you can get way more value for your money for your tokens for everything by finding the ways through to work out what's going on when we do a red team each exercise generally has an objective and a scenario you work out where you're starting you go am i um authenticated do i have an account do i not have an account am i an employee am i on the internet do i already have shell access to some system um and then you you know that's essentially your objective no that's your scenario sorry and the new objective where you want to go? Do I want to get into the core data centers?

3:44Do I want to get into the edge data centers? Is my aim to try and look at customer data? Is my aim to stay low and slow for as long as possible before we get detected with just having malware down in certain places across the network just to see what happens and do we detect that? When we're doing red teaming at Cloudflare, we can pretty much touch any system we want. There are very few things that are out of scope for my internal red team. The only main... to this is we're only allowed to touch corporate devices. We can't go after people's personal stuff. That's not really fair. We only go after corporate laptops, corporate servers, and that sort of thing. And generally, if a device cannot prove it is in scope, the implant will do absolutely nothing at all.

4:29And everything we do, we coordinate with other people in security, we coordinate with our SRE teams to make sure that we're not breaking anything. Because the worst-case scenario of a red team exercise is causing an outage, causing a security... incident having something going wrong. We want to get all this stuff done in a way that no one notices and then we can uninstall leaving no trace at all. But in this talk we're mostly talking about low severity bugs. So these are all public cases. These are all chains of low severity bugs that people forgot about. People deferred. You've got WAF misconfigurations. You've got basic SSF RF vulnerabilities. You've got accounts with too many permissions. This is all stuff. that you've probably all heard. This is all stuff that is in someone's ticket queue, and they write a justification about why it's not important, and then they move on.

5:16But this has caused real breaches of real companies. And this is stuff that we wanna make sure we're drawing attention to. Because when you get breached, that's your worst day. And if it's something that you could have fixed in 10 minutes, that's probably not where you wanna be. But yeah, all of these are real examples. This is stuff that happened in the wild. We've had a finance company, an SSO. provider, an enterprise email provider. These are all basic things that probably should have never happened, that were preventable. A fix has no real visible cost. There's no benefit to fixing a luciferity bug. But if you don't, the worst is really, really bad. So what we're going to do, we're going to talk through a fictional broken ticketing system. It's a teaching example, just so we can quickly go and cover some really, really low-severity bugs.

6:06So this is a ticketing app that's built roughly for one team. A team may use things to track things. It could be used for IT support. The details don't really matter. If you can log in, you're a user. That's kind of the end of story. The app does support guest accounts. They were tested. They were never really removed. But you can't sign up with them anymore. There is no admin. But the way to do admin is you SSH in, use your same credentials, you do it from a local host. And tickets are automatically triaged. an LLM bot that looks at this stuff and works out if it's an action the bot itself should take. And these are the bugs that are on it. There's a test guest account that wasn't removed. There's a legacy endpoint that is blocked at the firewall that can generate tokens for guest accounts. It was used for testing at one point. And also, guests can open tickets as normal users, but again, we have no guest account, so it doesn't really matter.

6:54And there's another test endpoint that makes a requirement. requests look like they're local. As you can possibly see, all these things added together ended a pretty bad scenario. But every single one on their own is a low severity bug. You know, your test endpoint makes a request look local. This means that your guest account can suddenly make tickets as users. If you do it from localhost as well, that means the bot's running in admin mode. It's able to run command, it's able to do things. This is not real, but it could be. People build stuff like this all the time. You have bugs that are reported, you have justifications about why they're not important, and then you move on. We see this exercise, see this pattern in real exercise, and it's happening in real, real breaches.

7:43But as I said at the start, also make sure you fix your high severity bugs. They're also quite important too, but they don't really get forgotten about. You have a big response. They're all over the internet. You read them on front-of-face news. We put a blog out, you know? All this stuff is things that you've got to balance and make sure that you're getting right.

8:06And then, yeah, this is essentially what would happen if you were to do that chain in the previous slide. A new ticket, someone registers, you know, admin mode on, the bot executes, and it's done. Just don't consider things like low-costal security boundary, even though they sometimes do get written as one. But now I'm going to hand back to over to Albert and he's going to talk about some tooling that we use when we're doing red teaming. So as Dan showed, we now just pwned a bunch of machines. So we pwned one machine. Well, it doesn't really matter. We pwned machines. Once you get access to a machine, you usually want to do something with that. And by itself, of course you can prepare your exploit to do everything you need upfront, but usually you don't actually know your objective exactly upfront. So you kind of want maintain control as a server afterwards when you affected it.

8:53So this is called C2 or Command and Control. It consists of three parts. There's the implants that you have on a machine. This is kind of what defines what you can or what you cannot do. For instance, it might have capabilities for reading files, for running commands, for connecting to other hosts. But it defines what you can or because usually once you install this that's what you have and the implant then by itself doesn't do anything but it does connect to a c2 server which is the orchestrator of the exercise and then view as the operator as a red team engineer can then connect to the c2 server this is where you dispatch commands to your implants and then receive the response again um so this is kind of what a c2 does um yeah

9:51So, when you look at C2, there's kind of three different classes of C2s. There's the ones you can find on GitHub, like Mythic Framework, they're off -the -shelf, they're quite convenient, but they have known signatures. So it's not really a good solution for emulating a targeted attacker. You also have the option of building your own C2 for a specific exercise. This has some benefits. that I'll talk about in the next slide. But we also have the C2s for targeted attackers like APTs. They're in a different class of their own because they usually have different objectives than what you would with a red team C2. They're usually built for stealth.

10:37They're built to stay as long as possible without detection. But I think for the next slide, we usually... our own C2. The reason we do this is that when we do exercises in a corporate environment, we need absolute certainty that what we're doing doesn't compromise the security of Cloudflare. And it also cannot compromise the availability of Cloudflare. So we need a bunch of additional safety checks in our C2. We need to make sure that it can only ever run on corporate devices. We need to make sure that even if our C2 server gets... compromise, that does not equate to compromising the machines the C2 implant is installed on.

11:23The reason you build a C2 is also that, whereas a targeted attacker might want to stay in the network for a long time, we don't really care about that because when we are done, when we got to our objective, we hand everything over to the blue team and then that's the exercise done. So there's really no benefit in staying in the network. for a long time um what it also allows us to do is we can build logging into the into the c2 itself so that any action we run is is audited it's locked if something goes wrong we can go back and and see what actually happened uh also it provides an audit log of of commands that we run that we can then provide to the blue team afterwards and they can they can cross uh reference that with their own edr logs to to actually trace uh trace how the attack happened

12:11And I think Dan will show now an internal exercise and brings all this together. Yeah, so we're on the red team, right? We do red team exercises. We hack Cloudflare. That's one of the things we did here. We're talking to you about a supply chain exercise that's partly simulated, partly real, in which we've reached Cloudflare.

12:32So if a supply chain compromises a developer's editor, how far can it go? We chose this scenario because it's something that a real actor can do right now. You get editors, you get IDEs, things that developers write code in, which have plugins. You get plugin marketplaces. Sometimes, IDEs change their plugin marketplaces without necessarily telling people, or people don't really realize what this means. And one of the things this does mean is that if you're using a plugin that's only on one marketplace, but not on the one that you're moving to, someone else could possibly register something there. Which is the way we... We got code execution on developers' laptops. We didn't put a real public plugin out. That would be not great. That would probably land in the wrong hands. That would draw attention to it. So we simulated it with our own town network because as we're an internal red team, we can do stuff like this.

13:20And the window is short on purpose. We wanted to know what a determined hacker could do in a day, not in a month. We want to know that if someone breaks in, makes a lot of noise and leaves, which is quite a lot what people do now with LLMs because an LLM can be a really, really... you know, it's a sophisticated attacker, but LLMs are not really trained to be quiet. So that's generally the sort of thing we're emulating.

13:42And we took sort of three things that run up on our own backlog. We knew about these. They were all low severity bugs. These are things that are now fixed, that we've worked out ways to solve them in different ways. Some of the details I'm going to be a little bit vague on, but in general we fixed every single problem we're talking about here, and this exercise was about a year ago. internal secure package proxy for a lot of internal stuff we have our internal package proxy this was not the case because it was an oversight um for um plugins for ides and that sort of thing it is now um and then when the marketplace switched this is something we knew about internally but again it was a low risk what was the worst that someone could do with this didn't seem that bad at the time and again ssh session reuse when you're sshing from one device to another device quite often you can hop alongside it.

14:30You can just reuse the SSH socket, which means that when someone types SSH on your laptop, if there's malware on there, that can automatically hop along with it, which is what we did. We, you know, the editor swapped the marketplace. We registered and leave. As I said before, it wasn't the real marketplace, we simulated this bit. But this did result in us putting malware down on two corporate laptops. And then also, ask this. real malware that you know it was very unlikely we'd ever land on someone's device because of the way we did it but we also have to have multiple levels of checking and validation in the malware itself to make sure that if it's not a cloudflare device it will just silently remove itself it won't do anything it will actually act like the real plugin um and then that's yeah that's how we got on there when we first did it our own web filters blocked the first attempt before it got connected which is a good sign um the domain we used it just happened to get fingerprinted um which is summed up detectives and preventives working

15:28but yeah every single thing was a low on its own the marketplace was swapped it's kind of low someone stores it it's kind of low it's hard to exploit no one really knows what editors are doing SSH session reuse or people go into that when you've got malware already down the laptop and also secrets and keys we were able to as part of this exercise we were able to access some of our internal secrets we were able to get onto network devices we were able to look there was also some things that we couldn't get to. We couldn't access any customer data where we landed. All the protections were there in place. We were able to mint some credentials and some secrets, but we couldn't use them for anything because we didn't mint them properly. They weren't minted by the proper authority. The keys we had, they could technically create them, but they weren't correct. They weren't registered as correct credentials, which means they were rejected by other systems. Which is good, right? We had lots of wins here from the defensive side.

16:16Lots of our controls held. This was, you know... From a Cloudflare's point of view, if an attacker did this, it would be pretty bad. But we had lots of things in place that happened to make sure that it wasn't the end of the world. But, you know, it is still pretty serious, right? We got root infrastructure in one of our data centers from an external attacker perspective. We were able to look at config management for network devices, including some secrets, which have all now been rotated. Service credentials and asset inventories, we were able to access all of this stuff. This is stuff that we really don't. want attackers to get their hands on. Because if attackers can draw a map into our network, that may only be a low severity thing. Attackers know what devices you've got where. But as we've known so far, low severity things stack. And we really want to minimize how many of them attackers have access to.

17:02And also, one of the things that was kind of funny, AI coding assistants have guardrails. When you're doing this stuff and you're trying to manipulate AI on a developer's laptop, because that's a really, really easy way to make a laptop do something. The AI assistants have to know why we're doing this stuff. do that, that's obviously malicious action. Which is something else that held and it worked.

17:26This is roughly the timeline. It was 23 hours. Blocked by a web filter attempt one, it failed. We had to work out what happened. And a standalone attacker would never have been able to figure out exactly why it didn't work. But again, as we were an internal red team, we were able to go with this, look at this and debug it using some of our internal tools. Then we did a second attempt with a second second domain, and it works. And then from this, someone SSH'd in as part of their normal day-to-day job, but we expected this because I can look at the developer internally. I know that this is someone that was on the SRE team, and as part of their job, they accessed production stuff, which, again, is not something that attacker could easily do. And then from there, we were able to get SSH onto root metals, and from there, we were able to start expanding inside, looking at config management and finding secrets. And then we were detected. And after detection, we write a report.

18:12The blue team finds us, they write a report, and we compare the report. we see what was found and we see what was missed but also one thing that's really really important to think about is the luck of this a lot of stuff went wrong right from the attacker's point of view the first register callback domain it got rejected it was filtered one of the relays broke before it connected we don't necessarily know why exactly all the things things happens because even though we have access to the developers laptops we can look at all the logs things just break sometimes. And when you're writing malware, when you're deploying malware and trying to do it safely, that is still quite a hard job. And you can't necessarily have perfect access to all the logs and everything. And also, by design, endpoint privacy, it blocked part of the home directory. We couldn't even look at the stuff that these developers were working on because the home directory was locked down. We could just execute code.

18:58We couldn't touch most of the files in the system. EDR was present on all of these systems. And we knew, as we're internal again, that if we did anything, the EDR would trigger, which would generally be spinning up another process we would get spotted really quickly and kicked out the system which meant that we were really really restricted in what we could do and we couldn't deploy any additional capabilities and then all the database access all the secrets access we were able to get some secrets but not most by any means all of these access controls held so even though it does seem pretty bad there was actually a lot of stuff that went well for cloudflare and for defending in this scenario um and i'm going to pass you back over to albert which is what we did about it So, as I've talked about previously, red teaming, the point of it is to find issues before an attacker does it.

19:46But you kind of have to do something about it also afterwards, otherwise that doesn't really help. So, as Dan has just explained, how low security bugs can be chained into higher impact. We actually use this to change how we treat vulnerabilities internally. You might have read our blog post about our AI harnesses and how we approach that. we actually build like a whole internal catalog of vulnerabilities that these ARN systems write to. And what this allows us to do is we can now have our scanner go back in the backlog and look at all of our vulnerabilities and then take these otherwise low severity bugs and try to chain them together. And when it does so successfully it then builds vulnerability stories that it services in the system so that it's much easier for us to go to engineering and say, hey, actually Yeah, we know these five issues are low severity, but when you combine together here's here's the impact you need to prioritize this This has kind of changed how we how we approach vulnerability management here.

20:42It's it's Whereas previously we we would just do it based on on the severity of the bug now. We actually Group them together and and Lucas at and like attacks as a whole as the as the measure of what we need to fix and how How urgently we need to fix them? But for this exercise specifically, we did make a few changes. For instance, now we don't allow people to install arbitrary extensions in their IDEs. You can only do so from the verified publishers that we allow. We also had this package proxy that we built for NPM and other packages for other languages. IDEs now go through that, so we can make sure that new packages that get published and may contain malware are quarantined for a certain period of time before they're released to clients and that way we avoid uh avoid this issue in the future um also we we made some changes to ssh configuration on our on our servers to prevent this uh broad session reuse so uh that you can't just uh jump along anymore unknown association um yeah i think we one of the things we we did uh after the exercises we we had all of the commands we ran so so we then take and we start a meeting with the blue team we go through the usually we give them time first to actually take a look at what they saw from their network telemetry and and their edr logs to see did they actually spot how how

22:15how we did it and they they did so then we go we go and give them everything we have and we we can then cross compare that just to see if there's anything anything they missed that's you how we deal with it after an exercise is done.

22:34So, red team in the age of AI. I don't know how much you've heard about AI. Maybe it's a bit new. But it enables attackers to go faster. It enables red teams to go faster. But it also enables defenders to go faster. Chaining bugs used to need patience and skill. Finding that needle in the haystack. Finding that one thing that would enable an attacker. these bugs to get some way more serious. It's something that LLMs are really, really good at. They're really good at picking signal from noise. They're really good at bulk data processing, and they're really good at connecting to dots. But doing this by hand for people would take hours. It would be a really long time. If you've got a thousand open vulnerabilities in your backlog, that's a lot of them. That's a lot of possible chains. Doing that with a person could be really, really tricky. And also, like, AI agents on your devices, that's a new trust boundary, right?

23:23you've got AI agents running on your laptop, someone could abuse these. And it's not even just from, you know, your agent seeing something and doing something you don't expect. It's that someone could put malware down and then use your local AI agent to perform actions on behalf of you. Which again, this is to do with guardrails. This is perimeter. This is logging. All of this stuff is things that are even more important in the age of AI. And then also at Cloudflake, we use AI to scale red team work massively. This is not possible without AI. We're able to move faster. we're able to build more malware we're able to do exercises quicker we're able to analyze our own logs with ai quicker faster understanding did we miss something because when you're chaining bugs together you can do it statically you can test things out you can combine all of these things you can bring up environments where you can look at this stuff and work out what's next what if we missed um and if attackers can do it too defend defenders should do it as well but we also really the main point that we want to get um from this talk is that you really need to start looking at all those severity bugs.

24:19Lots of places in the world, if it's below a medium, don't even look at it. You may have thousands of them on your backlog. You may justify why it's not a problem. But quite often, they are a problem. Unless you know what's around them, what you can combine them with, you may be missing something, which is really not what we want to do. So, when you're looking at bugs, you've kind of got three things you should do. What can this bug reach? Where is this bug exploitable from? Can one of our open risks or bones do? this. This is something you can do with AI. AI is really good at this stuff. When you're scanning vulnerabilities, when you're doing static analysis, whether you're doing other stuff, whether you're doing perimeter scanning, you can make your scanner do these and emit them in a format that other things can link together. And also, the test session is not only logins, right? Local host may not be a security boundary.

25:06If something is on your laptop, on your device, on a server, ask how it got there. Is it possible that it was a redirect with something else? is it malware? Because every single chain has steps. And unless you break lots of these chains, you're still going to have issues. Attackers still might get in, which is really not where we want to go. But yeah, that's the end of the talk. I'm getting into the speaker lounge after this. I think it starts at 12 if people want to come and chat to me.