Good morning, good afternoon and good evening, everyone. Thank you for joining us today for this webinar, Red Team Insights, what we’ve learnt from breaching the best.

Um, we’ve got something really special lined up for you, um, sharing some real world insights from our red team that we’ve gathered from breaching some of the most secure organizations out there.

Many of you joining today are already part of the Threat Spike family. It’s great to have you back. But before we get underway, just a quick bit of housekeeping. So you’ll see a chat icon on the right-hand side of your screen.

That’s um for you to send us some messages throughout the, the webinar. Say hello, tell us where you’re joining from, but it will also act as our Q&A panel. So feel free to drop a question in there throughout the speeches from Chandna and Simon.

And we have some time scheduled at the end to run through those questions. We are recording today’s webinar, so if you do need to jump off early, not a problem at all. We’ll send the recording out to everyone afterwards.

Feel free to rewatch it, share it with your friends or your colleagues. So without further ado, let’s get, let’s get started. So I’m really pleased to introduce you to. Our two speakers here today. We’ve got Simon Exley, who is one of our lead penetration testers. He heads up all of the physical engagements for our Treat spike Red Service. He’ll be taking you through how we perform these types of attacks and ultimately emulating what a real attacker would do.

On the other hand, we’ve got Chandler, who is our Head of Defensive Security.

Um, he is the one protecting against these attacks. Um, so he’ll be showing you the other side of how to actually stop those attacks from being successful.

Um, what I’m gonna do now is hand over to Simon to take you through the first part.

Thank you very much, Ellie. I’d just like to echo those words. Um, Simon and I lead the physical testing side of the red team at Threat Spike. I started my ethical hacking journey about a decade ago when my dad wouldn’t let me on the Wi Fi to play games.

So I just decided to hack it, and I mean, the rest is history.

So on the agenda today, we’ll be covering the three most common themes I see again and again in red teams and how to stop them. So number 1 is fishing, stopping threats at the front door. So there are many routes to the initial access of a network. An outdated server that has a remote code execution exploit or even physically plugging into a corporate network.

But the #1 entry point time and time again is none other than fishing.

So number 2 is securing remote access. With the rise of people that work from outside the They are remote entry points. Thing like VPNs.

And RDP compromise would be the main topics.

Number 3 is protecting critical accounts. So we’ll wrap up with how the most important accounts in your environment are always being compromised and how we stop them.

So moving on to the slide, what I’ve seen in the wild. So as a physicals lead, I spend a lot of time breaking into our clients’ buildings. The thing that always amazes me is how secure the digital estate is. People have things like the best WAF, the top of the line EDRs, etc. etc. But if you just rock up to a client facility, tailgate a couple of people, and plug in a rogue raspberry Pi, boom, you’re on the network. Taking a look at some of our team’s successes down below helps get the message across. Better than words ever can. So firstly, you can see myself using my extra long fingers to welcome myself into the premises. Then you can see Clinton.

Using his Spider-Man skills to ignore the fence that was in his way. And finally, some people are so generous that they just leave their computers unlocked for me to download some malware. What nice people.

So, Fishing. Stopping threats at the front door. But even with all of that stuff on the physical side, I don’t always get inside of every client’s premises. But if you would allow me to toot my own horn a little bit, something that I do have a 100% success rate in is the humble fishing campaign. Every one of them that I’ve ever done, I’ve gotten some poor soul to offer up their username and password. That is why I would like to start with it as the first main topic in today’s webinar.

So, fishing threats in 2025.

From my own experience, it is no surprise that the global statistics agree with me. As you can see from the stats below, 1 in 3 breaches start with a successful fishing compromise. I’m sure everyone on the call is well aware of the financial headaches that these cause, but if I could direct your attention to the last statistic on the slide, the 1,265% surge in the amount of phishing emails since the emergence of generative AI.

Personally, I make use of AI in every campaign I use. I get it to write the HTML, get the branding correct, make sure there are no spelling mistakes, etc. etc.

Now if I’m doing it, I can guarantee you that so are the threat actors.

So I’d like to introduce Martin to get the message across our best, but I believe the best way is with the story. So introducing Martin, our friendly and overworked IT help desk administrator. Martin spends his time juggling tickets, telling users to turn their computers off and on again. I’m sure you get the picture.

So.

Back when Martin began his career in IT phishing, emails were easy to spot. I’m sure everyone on the call can relate to the one on screen right now. Bad grammar and obvious links were easy for everyone to send this to the death of the spam inbox.

But As time and internet progressed, so did the sophistication of phishing emails. We now see ones using perfect branding, clean layouts, and buttons that hide the destination. As you can see on the screen now, the PayPal example shows everything looking legitimate except the link that resolves to PayPalaccounts.com, which actually isn’t a PayPal domain.

But my secret to keeping my 100% success rate is one word, impersonation.

So impersonation emails never let me down. As you can see in my.

Martin’s case, the threat actors had sent him a generic Microsoft 365 reset your password email, which he didn’t click. But then they impersonated Simon, who in this scenario is Martin’s boss. Simon asked Martin to reset his password as he didn’t do it initially when he got the generic Microsoft 365 email. So Martin clicks the link and gets directed to a Microsoft 365 spoof logging page, where he submits his credentials and then completes the MFA step after that. However, that 365 login page on the right there is not a real one. And rather a spoof man in the middle one that now has captured his credentials and authorization cookies. I’m gonna hand over to Chandler now to tell you how this could have been stopped.

Yeah, thank you for that, Simon, and you’re right, phishing uh is absolutely massive. Um, so the question is, how do we as cyber defenders, uh, prevent the threat actors, uh, like Simon, uh, from phishing our end users, uh, and protecting our organization.

Uh, so first and foremost, it’s probably no surprise, uh, we need a, a, a, you know, an email gateway, uh, and this email gateway, you know, it’s your first line of defense, it’s gonna stop phishing.

Uh, emails from even, you know, arriving, uh, to your end users in the first place, will, it will stop them from even interacting with the threat, um, if it’s configured well.

So, uh, a few points on that, you know, we need all domains to be covered by an email gateway. Uh, there’s no use having, you know, some email domains with active users that does not have any protection because chances are those users will still have access to.

Uh, various different applications, uh, you know, and have credentials that you would not want falling in the hands of an attacker. So you need to make sure you have, uh, you know, full protection in that respect. Um, you need to make sure that your email gateway cannot be bypassed, you know, it’s, uh, a lot of email gateways can be bypassed, uh, and a lot of threat actors find it quite trivial, uh, to bypass them, so we need specific rules set up to prevent this and also specific detections, uh, in place to alert us to when this is, you know, when this has happened.

Um, we need the rules, uh, of your email gateway to be constantly updated, um, and we need like the blacklist as well. Um, so we need ideally it to be overseen by a security team, um, because as Simon said, he’s got a 100% success rate, right? So there’s always room, uh, for improvement in terms of, uh, updating rules, updating the blacklist, updating our detections. Um, and because it’s ideal to have this as like a managed gateway and overseen by.

team, we need, uh, you know, the ability for end users to report back to the team if they believe phishing has landed in their inbox, um, you know, they need to get in touch, uh, so the security team can investigate. And, you know, if phishing has bypassed the email gateway, we need to, you know, quickly, uh, you know, uh, have SOPs for what the security team should do, uh, in that case.

However, it’s not just limited to an email gateway in terms of what we can do on the defensive side. Um, there are lots of SAS policies, uh, and detections and controls that we can have in place. Um, lots of your different SAS applications, uh, and services will have lots of confidential data, uh, that you will not want your, um, uh, you know, you know, you won’t want a threat actor to, to get hold of. Um, so in terms of detecting, uh, access to these SAS applications, unauthorized access, um, we need, you know, active log monitoring.

Uh, and in terms of what those logs should be monitoring, we should be log, uh, you know, mainly focusing on logins, um, you know, logins from suspicious IP addresses, whether they’ve been reported for abuse, uh, in the past or hosting this sort of thing. Uh, logins from strange locations, you know, if we have a UK based team, uh, and then we see logins from, you know, other places in the world, they should, you know, raise alarm bells and alert us. Um, and very closely related to that, we should have detections for impossible travel.

Uh, so if a user’s logging in from the UK, and then there’s a very, you know, another quick login from Brazil and then from the United States, this should be, uh, setting off alarm bells, uh, as well, changes in the user-client that, uh, we’re seeing in the logins, so if a user is always logging in from their Windows PC and then all of a sudden we see logins from, you know, a Mac device or an iPhone, that should be something that we’re alerting on.

Uh, and then finally, specifically related to actual email inboxes that may have been compromised, uh, we need alerts for the creation of suspicious mail filtering rules. So for example, if your CFO, uh, creates, uh, an email rule that says, you know, every email from, you know, your banking provider is gonna be marked as red immediately and put into an archive folder, uh, that should be raising alarm bells as well.

So all these detections are great, of course, but it’s like what can we do about them, uh, on the security team. What we need is, you know, 2 24/7 monitoring of these alerts, preferably by a managed SOC team, uh, who can, you know, respond to these alerts immediately, uh, disable user accounts, reset passwords, revoke sessions, um, you know, to immediately cut a user, uh, you know, a threat actor’s access off if that’s, uh, what we believe has happened.

Um, and also, uh, more generally, we want strong conditional access policies. So ideally these SAS applications shouldn’t be accessed, uh, from things like, you know, bring your own device. We want all the accesses to take place from managed devices because it makes it much, much more difficult, uh, for an attacker to gain access if this is the case.

Um, there’s a lot we can do on endpoints as well for fishing protection. I don’t have time to go into them today, um, but I’m happy to answer any questions you have at the end or, uh, if you want to connect with myself or Ellie, uh, at the end of the webinar, I’m happy to talk to you, uh, through that. Um, but back over to Simon now for our, um, uh, for finding number 2 of the day.

Thanks Chandler. So in the, the second common theme that I see a lot is securing remote access. So this will cover everything staff use to reach the environment from outside. So VPNs, RDP, all kinds of remote management tools, SSO portals, those sorts of things.

The reason why I chose to talk about this one is because it’s a direct entry point into your networks. It’s Pretty low effort in terms of compromise, but it has an extremely high reward.

You can just imagine you’re a criminal sitting at a beach in South Africa, busy escalating your privileges inside of some poor IT guy’s network who’s sitting in the cold and darkness of the UK. But anyway, let’s pick up Martin’s story. He was very kind enough to submit his credentials to us in the phishing campaign. But now what? Well, I’m here to tell you that in my time doing this, the one thing I’ve learned is that people reuse passwords a lot.

I’ve repeatedly taken harvested Microsoft 365 rates, sprayed them across VPN, Citrix, and other portals and landed inside of company networks.

So as you can see from this slide here, Martin reuses his Microsoft 365 password for the company’s VPN.

That’s now turned one phishing campaign into a network foothold. I’ll pass that over to to Chandler to dig into the controls that could have prevented this.

Uh, yeah, thanks for that, Simon. So a really good point on remote access actually, and there’s kind of two main areas I’m gonna speak about today, one of which is, uh, VPN security, uh, and one of them is remote access tool security. So as far as VPNs goes, uh, VPNs are of course necessary for, you know, your users who are at home or traveling to access, you know, on-prem resources. Um, but of course, it, you know, it provides, uh, basically a direct line into your network if it’s not secure for a threat actor.

Uh, so of course, we need strong credentials on those VPNs. Uh, if the VPNs are authenticating with domain accounts, we need strong credentials on those domain accounts.

Uh, we need MFA enforced on all, uh, accounts, no excuses.

Uh, and we need, uh, VPN patching and firewall appliance patching. So, um, of course, no amount of strong credentials in MFA, uh, will help you if there’s, you know, a zero day that’s impacting your VPN, um, which allows an attacker like remote code execution, uh, allowing them to basically just come straight in, uh, unauthenticated.

Um, what also helps is basically subscription to like, uh, threat intelligence, which can inform you if there are critical CVEs impacting your VPN or zero days, um, and then you can start to have the conversation. If there is a zero day, you know, do we need to have this VPN appliance switched on?

Can we switch it off and, you know, use something else until we can patch it because otherwise it’s just a gaping wide door to your network.

Uh, and on top of that, we need long monitoring for all of these, so any sort of potential intrusion via VPN or attempted intrusion, we want, uh, you know, our managed soft team to be able to investigate that, uh, immediately, uh, block IP addresses, that sort of thing.

And as far as RMM tools go, these are the tools that, you know, your IT team are going to use to assist end users if they have technical issues, uh, but also a lot of your third party vendors, uh, will need to remote into various devices, uh, on your network potentially to, you know, render support for applications.

Um, when I’m on boarding clients to threats like Blue, I find that in their environment, there aren’t necessarily strict rules about which RMM tools can be used.

They’re not blocked from being downloaded, they’re not blocked from running on the endpoints. What we should do is reduce, uh, the number of tools, uh, that can be used in the network down to an absolute minimum.

And any use of these tools is going to be allowed on a per device, uh, per user basis, and everything is gonna be audited because the last thing we want is, for example, someone posing as, uh, you know, a vendor, uh, calling up one of your users saying, you know, hey, I’m, I’m here to support you your finance application, something’s broken. I just need you to download any desk, uh, and open a session so I can connect, um, because, you know, the attacker’s straight on your network there.

Um, and that, you know, follows very closely to the user awareness training. So we need to, you know, make sure our users are aware, um, that this sort of attack is very common and increasing in popularity, uh, so to be aware, you know, like just because someone calls you saying they’re from one of your vendors does not necessarily mean they are, so they should always be, uh, very aware of this.

Uh, but back over to Simon for now for the final finding of the day.

Thanks Chandler.

So moving over to the third common theme I see critical account. So domain admins, cloud tenant admins are all prime targets both before and after initial access. So once the threat actor pivots to these identities, it’s pretty much game over. As the name suggests, they are critical.

So, Sorry, slide.

OK.

On a recent internal test, I began my quest for domain admin privileges by doing a very common attack technique which is known as LLMNR poisoning. So very simply, you can think of this as if a fake receptionist answered a phone call that was meant for the real office, then recorded the caller’s secret password exchange for later. The password is stored in a hash, which is just a fancy way to store passwords that people with access to the database can’t see them.

What they are in plain tech.

However, if these passwords are weak or commonly used, their hashes can be cracked, which is exactly what happened on this test.

I was able to crack the hash for the domain admins user, who was the very person who asked for the test.

So the irony there is quite strong. He probably thought his password was long. I mean, it, it was long if you look at it. It had capital letters, numbers, and special characters. But the password was the first three columns of the QWERTY keyboard, followed by 123.

This password can be found inside of Rocky.txt, which is a word list that contains the top 1 billion passwords. This specifically, this password was roughly around number 30 on that list. So in about 30 seconds of when I started the test, I was domain admin. I mean, luckily for them, it was me and not a rogue threat actor.

So moving over to this slide here. So helpdesk admins like Martin often sit in powerful Active Directory groups that make them prime targets for privilege escalation paths. So once you crack the domain admin’s password, you pretty much have full control over their Active Directory estate.

And unfortunately, the reality of that is if a threat actor is a domain admin in your environment, it pretty much ends the same way, which is ransomware. So back over to childhood to close and the practical next steps.

Thanks, Simon. So, uh, let’s assume Simon or Treat actor has actually got onto our network. What can we do to prevent him from elevating his privileges to administrator?

As you mentioned, the administrator accounts really are the keys to the kingdom. Uh, when we think about our network, they have, you know, elevated access to Uh, data, uh, to potentially steal that, they have the ability to install, uh, applications which could be malware, you know, gain persistence on the network. It’s really a game over scenario if one of these accounts, um, gets compromised.

Um, and, you know, recently there have been some high profile cases in the news of, you know, high privileged accounts being compromised and really having a devastating impact, uh, on the business. So what, you know, what can we do, uh, on the business side, um, on the defensive security side, uh, to prevent this sort of privilege escalation, so.

We really need monitoring to detect privilege escalation. We also need controls to prevent it. So as far as the monitoring goes, we need to obviously be alerted if there are any modifications to uh administrator, uh, groups or high privileged groups, whether that’s, you know, local administrators on your workstations and servers, or the domain administrator group or the enterprise uh administrator group.

Anytime there’s a new account added, we need to be alerted. Our security team needs to be alerted to make sure that that was, um, you know, Legitimate, uh, activity. Um, we need detections to detect things like curb roasting, uh, curb roasting is incredibly stealthy, um, but we can have, you know, endpoint protections to detect and alert our security, uh, team when this sort of thing, uh, is happening. Uh, and similarly for, for things like LSAS memory access, um, for things like pass the hash, which is something that Simon, uh, outlined previously, um, we need, uh, you know, detections for when, you know, LSAS memory has been, has been accessed, uh, specifically on the endpoints.

So that’s a little bit in terms of what we can do for the detection side, but what should we do in terms of the security controls, because again, it’s all well and good to detect these things, but if we don’t have security controls in place that will prevent these things from happening, we’re kind of always on the back foot.

Um, so obviously most, uh, importantly, we need strong password policies, uh, for these high privileged accounts. Um, so, you know, in Simon’s example, he cracked the admin password. Uh, for an account, if they have a strong password, you know, this is really not gonna be, uh, feasible for the attacker, even if they do get that hash. Uh, we also need strong storage of passwords, we shouldn’t have users.

You know, you know, keeping passwords, uh, insecurely on spreadsheets on their desktop or sharing them to other users, uh, in the business via WhatsApp or Teams or this sort of thing, uh, and it can be really hard to gain visibility, uh, as to when users are doing this, you know, are they copying and pasting them into, uh, these applications. It’s like, if we don’t have the right technology, it’s really difficult to know, um.

We also want controls to prevent the modification of admin groups, so I said we should have detections for when the modifications happened. We also want controls to prevent the modification from being possible in the first place, so, uh, you know, users can’t elevate, you know, can’t, uh, add, uh, a new admin account on their workstation, for example.

Um, we should think about having controls to clear the hashes, uh, of high privileged accounts, uh, from devices, uh, as well. Uh, and really importantly, we should be auditing who has access, you know, who has these high privileged accounts. Do we have, you know, 10 domain administrators? Do we need 10 domain administrators? If we have an IT helpdesk guy, why, you know, why does he need to be domain administrator? We should operate on least privileged access, uh, just to ensure that, you know, our attack surface is as small as it possibly can be. Um.

And finally, we, you know, always, we want staff training on the blue side to prevent, uh, the likes of Simon from elevating himself, uh, to an administrator, um, uh, specifically regarding uh password resets. Um, again, this is something that’s come up in the news recently where, you know, an IT help desk, uh, admin was socially engineered into resetting the password, uh, an MFA potentially for an attacker who claims to be the owner of a high privileged account in their environment.

Um.

Either there wasn’t a process in place for the user to follow or they didn’t follow it, um, and what they did was they basically gave the attacker the keys to the kingdom via that high privileged account. So this is something that we need to be super aware of, uh, as well.

Um, I will hand now back to Ellie to wrap us up for today.

Thank you, Chandler and Simon for those insights. It’s really good to see the workflow from the attack to the defense. Um, just on the screen here, you will see a quick snippet of our Threat Spike Blue service, which is the team that Chandler heads up.

So with Threat Spike Blue, we detect alerts from your entire digital estate.

We manage all the the alerts from our own platform, um, as well as any alerts that are triggered with your current tool stack.

We layer on security best practices and help you towards any compliance requirements that you’re looking to achieve.

This is all wrapped up in our 24/7 365 SOC team and unlimited incident response.

This sort of service is especially critical around the holiday period when you and your team definitely want some time off. Um, if you are interested in finding out more, our contact details will be shared after this webinar, but before we finish up, let’s dive into some questions. We might not have time for them all, so all responses will be shared alongside the recording after the webinar is finished.

So.

The first question here from Adam is, in your experience, which user’s roles are most likely to be targets?

I will hand that over to Simon.

Thank you, Adam. That’s a great question. So, I mean, every environment is different, but generally the themes are things like backup operators groups. They’re always very interesting, um, as well as local administrator accounts. So the the GPP.

Password. It’s normally found in the net logon shares in SMB, which is normally set up in default Active Directory environments where you can then exploit that on a local machine so you can become a local admin on there. And then I’ve seen password reuse there as well where domain admins have used the same password as a local administrator when setting up an Active Directory environment as well. So it does depend on each environment, but, but, uh, those ones normally make up the majority of the recurring themes that I see.

Thank you, Simon. And second question from Katie is, in your defensive team, do you provide technology as well service as well as technology? And if yes, how hands-on can it be asking for companies with small security teams?

Chandler,

I, yes, I’ll take that one. So, um, the answer is, uh, yes, uh, all the technology that, uh, we offer is wrapped in a service. Um, it can be as fully managed as you want it to be, um, it’s particularly if you have a small security team, if you want us to do all the configuration. You know, if you want us to act as security consultants, um, for you to, you know, bounce ideas off of, we can look at your environment, make recommendations based on what we see, you know, that’s all part of the service, um, and it really gives it that kind of personal touch, uh, in a way, and it’s how you get the kind of the the most out of the service.

Uh, as if you allow us to kind of guide you, but equally, um, if your team want to get super hands-on with the tool, uh, and wanna be looking at incidents themselves and configuring controls, we will provide, you know, all the training you need in order to, to, to accommodate that, uh, as well, but the idea is we kind of can operate as an extension of your security team, uh, or just kind of an additional security team, it’s really whatever arrangement suits you best.

Fantastic, thank you Paula. I actually have one question for myself.

So, um, are there any particular times of the day or is it night where you’re more susceptible to attacks or even any particular times of the year um that you should be extra cautious?

Um, in terms of times of day, uh, potentially the evenings, um, we’ve seen some cases where, uh, for example, a user doing night audit, uh, is targeted by an attacker because the attacker potentially knows that there won’t be, you know, IT staff around to warn the user, uh, or for the user to contact and say, hey, is this, uh, attempt, um, uh, you know, is this remote access, uh, request, uh, valid, um.

Uh, and it’s likely the user’s tired in the evening working and they just kind of wanna, uh, get on with whatever it is the, the threat actor is asking them to do, um.

In terms of times of year, potentially around the Christmas period, now as we come up to it because, uh, you know, people are taking time off and unfortunately the threat actors don’t take time off, uh, so they’re willing to kind of, um, try and get in when there will be fewer people looking at alerts if that makes sense.

Fantastic. Yeah, and, and like I’ve heard you’re definitely not taking any time off for yourself, Chandler. Um, we’ve just got one more question here on, uh, will there be any other sessions like this in the future? So Graham has popped a quick response in our chat, but we are absolutely planning on running more sessions like this across various topics, um, from. The offensive security, defensive security, and full IT suite as well. Um, and what we will be doing following this webinar is sending out some feedback forms. So if there are any particular topics that you would like us to speak on, um, just pop that into the feedback form, and we’ll add that into the roadmap for the future webinars.

Um, but that is the end of the questions. So, a couple of thank yous to give out. So thank you again, Chandler and Simon, for all of the insights you have provided. Um, thank you for everyone joining. And also a big thank you to our customers as well for all of your collaboration, which ultimately allowed us to put this content together across the thousands of pen tests we’ve done for you over the years.

Um, as I mentioned before, the recording for the webinar will be sent out, um, alongside the transcripts of the questions and the feedback form alongside that.

So for, for now, enjoy the rest of your day and we look forward to seeing you on our next webinar.

Thanks everyone.

Cheers guys.