By David Roccasalva, Privasec’s Managing Consultant
In this blog, I explain the techniques of how I gained privileged, remote access to an organisation’s internal network through social engineering. These events, while anonymised, are from a recent red team attack simulation performed by the Privasec RED team.
Security is hard.
Think about your typical medium to large organisation. Perhaps multiple physical offices across Australia and maybe even an international presence. More than likely, a large internal network compromising of multiple domains, hundreds if not thousands of workstations, servers and networking infrastructure. Sensitive data is stored, probably encrypted (let’s hope so…) somewhere within this nest of infrastructure. Staff headcount likely in the thousands, several Information Technology (IT) teams and most likely a dedicated cyber security team. Over the years, sure the security posture has probably improved, but it is likely a constant battle of implementing security as the business moves… and rightly so. The business must keep going.
Then you have internet facing assets… that could be an organisation’s website, remote access for staff to Work from Home (WFH), email services, perhaps an Office 365 presence, file transfer services like FTP, and various terminal services and web applications required to manage things remotely or provide access for staff, vendors, and Managed Service Providers (MSPs).
So, what you have now is a common but complex environment to secure …not to mention a LARGE attack surface. Ok, let’s have some firewalls and Web Application Firewalls (WAFs) at the perimeter, we’ll only expose necessary services to the public Internet… but sometimes we just need to open things up… in those cases, we’ll ensure strong complex passwords are used. Cool. We’ll also ensure Multi-Factor Authentication (MFA) is enforced for anything external. On top of that, let’s ensure we deploy the latest security updates to systems.
Likewise, internally, all systems will have processes, policies and controls to ensure unauthorised or unnecessary access is restricted. IT admins will have separate accounts to manage systems and applications. Logs for critical applications centralised, stored and monitored by an internal Security Operations Centre (SOC).
Despite all of this, somehow the lights stay on and we are relatively confident in the security of our systems. This is just an example of your typical organisation. Most of the time, you are on top of things and managing your risks.
One sunny Morning...
Then, tomorrow morning when you least expect…
All file shares in the internal corporate network are suddenly encrypted. Including your critical and sensitive data. Workstations are displaying a ransom note. Staff can’t login. Internal incident responders are drastically trying to identify the cause. Business is screaming for answers. Customers vent frustrations on social media. News sites get wind of it and now it’s a front-page headline…
Sound familiar? Too close to home? Give you goosebumps?
What have we forgotten or not mentioned…?
Quite a lot actually, but for the purpose of this blog, we’ve missed one of our most critical security controls. People.
“Hi. This. Is. The. ATO. We. Have. A. Warrant. For. Your. Arrest…”
So up until this point I’ve focused purely on technical controls to protect assets. But what happens when a highly convincing attacker outside the organisation calls a staff member, says they work for your IT department and asks them to provide their credentials to ‘fix something’ that they’re actually currently having an issue with?!
Suddenly… your chest of gold that was surrounded by a castle wall, has now opened its doors for an intruder hiding under shining armour, walked through the castle gates, past the guards and is now roaming inside the grounds without raising any flags.
You’ve probably heard similar stories with scammers on the phone trying to get your bank details, the ATO having a warrant for your arrest and the like. But what I want to share with you today is a real-life (obviously anonymised) example where I was that ‘scammer’ on the phone and to give you a sneak peek into the perspective from the Privasec RED side.
As a member of the Privasec RED team, my daily job is to try and break defences and gain access to things that should otherwise be protected by security controls. I’ve been involved in many red teams and attack simulations. In these engagements, we’re generally testing an organisation’s holistic security posture and defence capabilities.
An objective for us may simply be ‘try and steal customer data’, with everything in scope and on the table. Hack their external infrastructure, masquerade as a trusted person to access their physical office or send phishing emails to try and get passwords… Just like an attacker, depending on our reconnaissance and objectives, we’ll do whatever is necessary to achieve them and gain unauthorised access. All of course while not doing anything illegal.
Let me paint the picture...
So back to my opening example, this is not too far from a real red team engagement the Privasec RED team was recently involved in. We had spent a few days scoping out the organisation looking at their internet facing systems. Using Open-Source Intelligence (OSINT) techniques, we profiled the organisation, mapped out High Value Targets (HVTs) such as those that would likely to have privileged access within the environment, and even identifying details about internal systems, building layouts, security systems and applications. All before we start ‘hacking’.
In this case, we had found that externally, they were relatively well setup and protected. We planned a few attack scenarios including targeted phishing emails with very tailored pretexts for specific individuals and even applying for a vacant job position in software development, with the intention to gain access to the head office building and plant an implant device within their network.
Firstly though, we focused on the external perimeter and had located their remote access system that staff use to WFH. Problem was, it was protected by MFA. During our reconnaissance, we had found many ‘low risk’ vulnerabilities that provided some information, however in isolation were not that useful.
But, as we analysed all the information we had collected and begun pre-planning our attack phase, we identified a vector that could work by chaining a few of those low-risk vulnerabilities…
Piecing the puzzle together…
As I said, some lower risk vulnerabilities were found earlier on. One of those was a Mobile Device Manager (MDM) web application that we were able to access by brute-forcing the login prompt. What that means, is we tried numerous combinations of usernames and passwords and eventually found a pair that got us into the system. While we only had ‘limited’ privileges under the context of a specific person, it allowed us to identify details about their work mobile phone. We could see their mobile phone manufacturer, software version, serial number, installed applications and even its last IP address. Not that bad, but I’ll come back to that later.
In addition to the MDM website, we also had access to a Service Desk portal using the same credential pair. Here, we could view service requests that had been submitted by this particular person. Lucky for us, one had recently been raised to request access to something. All I needed was the request number.
Now… what we really want is access to the internal network. During early perimeter fingerprinting, we determined their remote access system would require MFA. Never fear, I’ll just call and ask for the MFA code…
Hello, this is ‘Bob’ from the Service Desk…
Vishing, to put it simply, it is the ‘voice’ equivalent of email phishing. It is a form of social engineering where you build trust with someone and exploit it to achieve something. For example, this is where an attacker lures a victim into providing sensitive information or performing some action in an effort to achieve the attacker’s objectives.
Now that I had a few bits of information about this individual I could call them, masquerade as someone else and leverage it to access their remote access system. To manipulate them into believing I was legitimate, I had the following details that could be considered ‘intimate knowledge’ to them, I knew:
- Obviously, their name and mobile number from various internet sources
- Work phone manufacturer and serial number
- That they were in the office… or at home, as their phones most recent IP address was in the 10.x.x.x range (Private IP).
- A recent service desk service request number
With that, I called them… (This has been anonymised and paraphrased. In this case, we’ll refer to the ‘victim’ as Alice.):
Me: “Hello, this is Bob from the IT security desk, how are you doing?”
Alice: “Sorry who is this?”
Me: “It’s Bob from the service desk, how about this weather, it’s crazy”
Alice: “…”
Trust level: 0% and about to hang up.
Me: “I’m calling about REQ123456789, for access to XYZ and if you had a minute, I can help you out with that?”
Alice: “Oh yes, can you please, I really need this access”
Trust level: 90%
Me: “Looks like your work phone MFA has somehow lost sync with our systems, so I just need to quickly resync it and then you’ll have access. Have you got 2 minutes so I can set that up?”
Alice: “Hmmm, ok…”
Trust level: 60%
Me: “Just to confirm we have the right device, can you please go to your Apple iPhone settings”
Alice: “yes”
Me: “Serial number is ABC123DEF345 correct?”
Alice: “yep!”
Trust level: 80%
Me: “Awesome, and you have the XYZ application installed to receive the MFA code?”
Alice: “Sure do”
Me: “Ok, I’ll be sending a code to it now, you’ll just need to read the code out to me so I can resync it…”
Me: Login to the remote access portal with the brute-forced username and password
“MFA code should be coming through any second”
Alice: “Yep, got it!”
Trust level: 90%
Me: “Ok great, if you could please read that out to me?”
Alice: “It’s 987654”
Me: Remote access granted and now have access to the internal network
“Ok, that seemed to work. But for whatever reason it hasn’t given you access to what you’re after. But I will work on that now. Can I call you back in 5-10 minutes?”
Alice: “Ok, thanks”
10 minutes later, I call them back so they feel reassured and trust my actions, who I am, and that I am “legitimate”.
Me: “It’s still not 100% working, but I’ll update REQ123456789 and escalate this to the support team for action. Apologies for not being able to fix it here, but we’ll get to it ASAP. Have a great day, and we’ll be in touch soon”.
From this point, our initial ‘entry point’ into the organisation had been achieved. In the end, we gained administrator access to the internal domain, but perhaps that is for another blog to explain…
“But I have a firewall?!”
Unfortunately, the above example is reality. This is what the bad guys do. And this is how quickly your reinforced castle wall comes crashing down.
Yes, in this case there were a few things that should have not been possible or exposed, such as restricting access to the MDM and service desk portal. But really, all that did was help speed up a convincing pretext to build trust. With more time and an attacker’s determination, that could have been any pretext. Perhaps something from social media in their personal lives… whatever, there are no boundaries (for a real attacker), just the imagination.
Many organisations have got really good at protecting external assets with technical security controls, but most of the time and what we see quite often is a lack of security awareness in staff. It’s been said by many others before that every single person, whether you’re the CEO or a junior staff member in their first few months at a job, all play a role in the cyber security of an organisation. You all play the role of a ‘security guard’.
Trust, but verify
Just like any standard crime, if you see something or experience something that doesn’t feel right, report it to your security team.
I’m not reinventing the wheel here, but organisations should strive to create a culture of ‘trust, but verify’. We don’t want to have our colleagues with squinting suspicious eyes on each other all the time, but it should be encouraged for everyone to feel confident in challenging something that isn’t right. For example:
- Someone walking around the office without displaying their security lanyard
- Someone calling and asking for private information
- Receiving an email asking you to login to something
With my example, could this have prevented the Privasec RED team? No, no one can stop the Privasec RED team!
Jokes aside, ‘maybe’. A mature organisation that provides constant security awareness training would be armed with everyone being able to identify something abnormal. Maybe the person would’ve just hung up on me? Maybe they would have questioned me more to identify myself and call me out? Maybe they would have reported it to their cyber security team, who could’ve investigated the incident, discovered their credentials were being used from several IP addresses and actioned accordingly…?
Either way, it’s always a ‘maybe’, as I could’ve just moved onto the next person.
Protecting an organisation from cyber-attack will forever be a game of cat and mouse. You’re NEVER going to be 100% resilient from attack. But, what we can do is uplift our people to understand cyber security. EVERYONE should know what they need to do, EVERYONE should understand what’s normal, what’s not, what’s ok to share and how to report something. Constant cyber security awareness training is a must and should be mandatory! It should also be readily accessible to everyone and at any given time!
When a compromise happens, similar to the example I’ve given, (within reason) this is hardly the fault of the victim. All it identified was a lack of training and understanding.
This is an organisation-wide responsibility. Constant training, learnings and discussions is what helps to strengthen the security of your organisation. …oh yeah, and you still need to patch your systems and do everything else I mentioned earlier on.
Anyway, I hope this little insight was helpful or at least got you thinking about it for your organisation. You could be doing everything right, but most of the time, all it takes is for the failure of a single control that could ultimately lead to the compromise of your application, system or, something as big as a large-scale ransomware attack in your environment.
It’s definitely not easy and there is no ‘one-size fits all’. It’s all about gradual change and improvement.