Posted on 2024-05-17 by Alexei Doudkine in Volkis News
Over the last couple of weeks, we had a fellow security consultancy perform a penetration test on us! That’s right, even though we can do it ourselves, it’s always best to get someone independent to look at your security. We believe in following our own recommendations, so here we are. What did we learn?
Our threat model and the goal
Before the pentest even began, we had to consider why we wanted to get one done. Sure, “to find vulnerabilities,” that’s obvious. But broader than that, we hold a lot of sensitive data. Private code, customer contact details, but by far the most important is the data around the pentests we perform and the resulting reports. A lot of the time our reports are a, “How to hack Company X for dummies.” If this data were breached, our reputation would suffer a huge, business threatening, hit.
With this, the goal of the pentester was to compromise sensitive information focusing on report and testing data.
The scope
Being an all-remote company, we don’t have an “internal” or a “wireless” network. That leaves external, web apps, and SaaS systems we use, as well as our employees. All of this was in scope and we provided the following information to the pentester:
- A dump of all our DNS records
- Credentials to a few key assets such as our custom report delivery system
- Access to source code for some of our critical applications
- A list of everyone’s email addresses
We wanted to give the pentester as much insider knowledge as possible. In reality, we shouldn’t assume that we’ll be safe simply due to attackers’ lack of knowledge. That’s called ‘Security through Obscurity’ and is a no-no with infosec.
Results of the pentest
No vulnerabilities were found in the external infrastructure or web apps (yay)! 🎉 A few additional recommendations were made, but we decided they were not worth implementing since they didn’t have any meaningful security benefit.
Now the part you’re probably here for: The phishing results! Well… 2 of our security consultants had their GitLab credentials stolen. 🫣 “But we’re security experts, right?? How could this happen?” As we tell all our clients, anyone can be tricked. Given the right combination of pretext, time, situation, and vigilance, even people working in infosec day-to-day can fall for social engineering.
This is what the email looked like:
It came from the gitlab.contact domain and, as you can see, it has all the hallmarks of a pretty convincing phish:
- It looks legit.
- It suggests authority in that it appears to come from a director (me).
- It suggests urgency by alluding that the victim missed this 10 days ago.
Here’s what the 2 victims were thinking at the time they got tricked:
It was Friday, I had a lot to do, and this seemed like something easy I can just get done quick. It wasn’t until I didn’t get prompted for MFA that I knew something was wrong.
10 days ago, I was interstate on a job. It’s very likely I missed it then as I was focused on the work.
The second one was an “unlucky coincidence” you may think. But that’s why phishing works with volume. With enough chances, you’re going to find that one “unlucky” person - making it not so unlucky after all.
A few things to note: The campaign was allow-listed through all our security controls. GitLab’s use of Cloudflare Turnstile prevented the pentester from using Evilginx and bypassing MFA (thanks GitLab!) If this were a real attack, MFA would have prevented the attackers from logging in, in this specific scenario. Keep in mind, though, that MFA can, generally, be bypassed with phishing unless you’re using “phishing resistant” MFA like FIDO2 or Passkeys.
This was a good lesson in staying humble and being sympathetic to those around us who are phished, or scammed, or tricked. No matter how protected you think you are, you can still be tricked.
Learn from our experience
What should you learn from all this?
- Anyone can be phished. Make sure you have multiple layers of protections in place, such as MFA, mail filters, and a non-email verification process for sensitive actions like bank transfers.
- If you’re getting a pentest, do a quick threat modelling exercise to see what you actually care about and want the consultant to focus on.
- Give the consultant insider info. This will speed up the pentest process and has very few downsides.
- Human-built, custom, phishing campaigns are better than off-the-shelf ones and are a more realistic test for your staff.
Looking for a pentest, or want to see how your staff would react to a phishing attack? Reach out to us for a chat!
About the author
Alexei Doudkine is Co-Founder and Offensive Director at Volkis. Hacker, tinkerer, car modder and dog person, Alexei has been in the infosec game for over 10 years focusing on the “attack” side of security. You can catch him on Twitter and LinkedIn.
If you need help with your security,
get in touch with Volkis.
Follow us on Twitter and
LinkedIn