Adopting an Offensive Approach Towards Raising Security Awareness
Cermati Fintech Group’s information security team has a range of responsibilities. One of them is holding internal security awareness sessions periodically to share relevant security tips, and also share the organization’s overall performance against the phishing campaigns performed by the information security team against our employees.
While security awareness as an issue isn’t solely the information security team’s responsibility — other teams such as infrastructure platform engineering, data engineering, and the IT support teams are also responsible to ensure their users’ awareness of the operational security best practices related to the domain they’re working on — the information security team is the only team in the company that’s authorized to perform attacks against our employees to test our organization’s ability to recognize attackers and properly respond to it. The attacks against our employees are usually conducted by phishing.
While this sounds simple, even tech-savvy people can fall victim to an attack as simple as a well-crafted phishing email sent to their inbox at the right time.
We started adopting phishing campaigns in 2021, which is still quite recent. It is meant to raise awareness and measure our employees’ performance when faced with various phishing scenarios.
In this article, I’d like to share about the methodology we use for our phishing campaign operations and what we have learned and improved from our experience. The methodology involves several steps, which will be covered in the following sections.
Planning
We always start our phishing campaigns with high-level planning, based on the specific goals we’d like to achieve from the campaign.
Usually, we start by defining what information we’re trying to extract from the target. This can be their login credentials (without their passwords, for ethical reasons), specific information contained within their machines, or some other information that we consider valuable enough to be set as the flag we’re trying to get from the operation.
But it is also possible for us to go in a different direction — for example, aiming to compromise and gain remote access to the target’s machine instead. In this case, we might be aiming to leverage the access to move deeper into the network which our designated attacker normally doesn’t have access to.
Our next few steps in the operation will depend on whether we’re simply trying to harvest as much information as possible from a large number of targets or we’re trying to compromise a few specific targets in order to gain access to a certain internal resource.
In the case where we’re simply trying to harvest as much information as possible from a large number of targets, we usually define how many people from each targeted division we’re going to randomly pick as the targets — we sample a certain number of people from the targeted divisions and rotate them with a new sample on the next batch of phishing email blasts, so there will be some time until the same person is sent another phishing email to lower their guard against a similar scenario. In the case where we’re aiming for specific people to extract more sensitive information or to gain access to a specific internal resource, we’re going to pick fewer targets but put more effort to compromise each individual target.
Infrastructure Setup
Now that we already have a general idea of which direction the phishing campaign should go, the next step is deploying our phishing infrastructure. The phishing infrastructure itself has evolved since our first phishing campaign back in 2021, and setting it up is a lot simpler now than it was back then.
When we first performed our internal phishing campaign, we didn’t have any internal tools to make the phishing campaign process easier. Our information security team needed to code the fake login page and deploy it manually to free hosting services (sometimes it got taken down very soon after the deployment due to it being detected as malicious by the hosting services) and deliver the links to the fake login page via an email blast that’s manually sent to the targets.
Later, we explored KnowBe4’s phishing campaign capabilities. But KnowBe4’s phishing campaign management features were quite basic and didn’t really provide the features to support the workflow we were aiming for. We couldn’t host any real phishing site with KnowBe4 as their expected phishing campaign workflow was simply sending the emails containing the “phishing link” to the targets and notifying the users that they got “phished” when they click the link. KnowBe4 provides analytics for us to see who got phished (basically, who clicked the link), but this isn’t really an upgrade from our previous iteration of the phishing campaign because, in the previous iteration, we already have a working phishing site that we can use to identify which targets got phished by checking the usernames they submitted to the form — also, we have a different opinion about what should count as getting phished.
We’d like to have the capability to easily deploy phishing sites, automatically sending phishing emails to the targets, and analytics capabilities to see how far into the phishing funnel our targets go — to see if they opened the email, visited the phishing site (KnowBe4’s definition of getting phished), and submitted their credentials to the site (our definition of getting phished). So we decided to develop our own phishing toolkit, which we call Phisherman.
Phisherman also includes templates of various login pages from the applications used by our employees and templates of fake notification emails from the said applications that we can immediately use if we need it quickly.
Nowadays, whenever we’re preparing for a phishing campaign, we’re going to deploy and configure Phisherman and its supporting infrastructure according to the requirements of our phishing campaign — and make sure the basic setup works correctly before we’re moving to the next step.
We also solved the problem where our phishing sites are flagged as malicious by the web hosting services because we deploy Phisherman to our own VM and the sites supported by Phisherman are hosted on the same VM.
Scenario Preparation and Technical Adjustments
Now that we already have Phisherman up and running, we can start refining the scenario we’re planning to use for the campaign.
We can go for a generic scenario when trying to harvest credentials from a large number of targets. An example scenario we can use is to send a fake password reset instruction from one of the web-based applications our employees use for work. For this kind of scenario, we don’t usually need to put much effort into tweaking Phisherman’s configurations because Phisherman already provides us with templates we can use to phish people using simple generic scenarios.
We can also try going for simple spear phishing where we send a link to fake login pages hosted by Phisherman to the target — but with more personalized email content impersonating someone the target works closely with, instead of the regular email blasts impersonating the application’s automated system mailers. This usually just requires the designated attacker to do some research on the target in order to be able to tailor the scenario according to the target to make the phishing emails look real.
But for more intricate scenarios, we might need to put in some extra technical work in order to make it work with Phisherman.
One example that we have tried is sending custom-made malware to our employees. The malware is sent using Phisherman, and once executed it will contact a back-end HTTP server to upload information contained in the machine running the malware to inform our information security team who runs the malware. In this case, we need to set up a web service that serves the functionality required by the malware that’s acting as a client to the web service.
Or we can deploy a C2 (command-and-control) server instead if we’re planning to remotely control the target’s machine so we can leverage it to move laterally in the network. In this scenario, we can try to gain access to resources that the target has but the designated attacker doesn’t — some of our internal resources can only be accessed using a certain workstation and a TOTP (time-based one-time password) token, which will require the designated attacker to gain persistent access to the workstation in order to increase their chances to be able to access the said resources.
After we decide on the scenario we’ll be executing, we can proceed to prepare the necessary adjustment to the infrastructure setup to support the attack and test it to ensure it will work smoothly once we deliver the payload to our targets. Once we’re certain that everything is working correctly, we can move to the next phase of the operation.
Delivery
When the scenario is decided and the infrastructure setup is ready, we can decide when to deliver the blow. Our team usually prefers the time of day when the targets are likely to be less alert.
After we agree on the time of delivery, we’re going to send the messages to the targets when the agreed time comes. We will then monitor the victims’ activities via Phisherman to see how many of them opened the email, clicked the phishing link, and submitted their credentials to the phishing site. Or in the case of the malware distribution scenario, we’re going to monitor who ran the malware on their workstation instead of who submitted their credentials on the phishing site.
When the messages have been delivered, it’s generally just a “let’s wait and see” phase for us.
We’re also responding to the targets reporting phishing attempts at this stage. Sometimes we decide to try adding more targets in this phase and schedule for another delivery if we think that we might benefit from having more targets based on the data we observe from the phishing analytics.
Analysis, Reporting, and Concluding the Campaign
After we’re done with the phishing campaign and concluded that we’ve done enough in our attempt to attack our employees, we will write a report to document what we did. We will include the data we take from Phisherman to be visualized in the report with some analysis.
The report is mainly for the internal consumption of the information security team — and senior management, if they require it — as it might include some information that’s considered somewhat sensitive. But a more friendly version of the report is usually presented as a section of our security awareness deck, which will be scheduled not too long after the phishing campaign is concluded.
Aside from the phishing campaign results, we also add some tips for our employees to avoid falling victim to the scenarios we used during the campaign to be presented at the security awareness session. If there are relevant concerns regarding security from the general public recently — for example, recent huge data breaches or the rise of new technologies that might pose a significant risk to us if used incorrectly such as ChatGPT — we might also include some tips on how to address and mitigate those issues in the session.
Once we’re done with the phishing campaign and the reports, we must take down the infrastructure we set up because it’s not going to be used for a while. We also need to make sure that we don’t have any residual malware from the attacks we performed running on any machine after we conclude the operation because it might end up leaking information somewhere else or opening a gap that can be exploited by someone else to gain access to our machines if we’re not careful.
Conclusion
As one of the information security team’s responsibilities is to raise our employees’ awareness of information security issues, one of the methods we chose to raise the awareness is by performing relatively benign phishing campaigns against our employees.
The phishing campaigns evolved over each iteration. When we initially performed it in 2021, we didn’t have any tools prepared for the operation so we needed to make do with what we had.
For the next iteration, we started exploring tools we can use to make our lives easier and decided to try KnowBe4. But we felt that it was still missing a few things that we’d like to have, so we developed Phisherman and have been using it for all of the following iterations so far.
Now that our basic phishing needs have been covered by Phisherman, we can explore more variations in the phishing scenario by introducing spear phishing and malware attacks to the operations.
The information security team keeps exploring new scenarios and techniques we can use to test our system from the offensive side, while also working on the other aspects of the security improvements from the defensive side.
