Simulating a Cyber Attack Against Cermati Fintech Group’s Call Center Facilities

Edwin Tunggawan
Cermati Group Tech Blog
8 min readJan 9, 2024

The call centers in Cermati Fintech Group are one of our primary means of communication with our customers, where a vast majority of them are strangers to our staff, and in many cases, our customers are the ones initiating the contact. This makes it easy for attackers to disguise themselves as customers when attempting to attack Cermati Fintech Group by targeting the divisions stationed in our call centers.

With that risk in mind, in 2023, Cermati Fintech Group’s information security team decided to perform a simulated attack against our call centers to test the call centers’ security and see if there are things we can help improve.

In this article, we’d like to share how we conducted the operation. However, some of the details should be kept confidential to avoid revealing sensitive information regarding our security implementations. Taking that into consideration, we’re going to focus mainly on how the operation was conducted from a high-level perspective while omitting some details we consider too sensitive to share.

Methodology

The 5 phases of cyber intrusion, image taken from an article on Graylog’s site.

The above diagram shows the phases of a cyber intrusion. The phases show how real attacks are conducted, and what defenders need to do in order to detect and respond to the attacks at each phase.

In the offensive operation we conducted, we adjusted the phases to better suit the goal of our attack simulation. The win condition for the attackers we set in the operation was compromising one machine inside any of our call center facilities and persisting control over the machine. Hence, we didn’t need the “Move Laterally” phase as the win condition should be fulfilled once we manage to establish persistence in the call center.

Another adjustment was on the “Collect, Exfil, Exploit” phase. Our purpose wasn’t to cause damage to the system, hence this phase can be omitted. Instead, we added “Reporting, Feedback, and Improvements” as the final phase, since our purpose was to guide the company in improving our security posture. The remaining phases are also tweaked to better support our goals.

So we ended up with the following phases:

  • Information Gathering, replacing the “Reconnaissance” phase.
  • Exploit Development, replacing the “Initial Exploitation” phase.
  • Attack Delivery and Persistence, replacing the “Establish Persistence” phase.
  • Reporting, Feedback, and Improvements, replacing the “Collect, Exfil, Exploit” phase.

There are more adjustments made in each phase of the attack simulation to make it more effective for us to achieve the goal of the operation, which we’re going to discuss in more depth in the following sections.

Phase 1: Information Gathering

This phase is mainly about gathering information on our targets— in this case, our call center facilities. We specifically renamed this phase from “Reconnaissance” to “Information Gathering” because we’re going to leverage our status as employees within the organization to gather the context more effectively while also contributing to improving the organization’s security posture in parallel.

A relation graph of information collected in an information gathering operation, image taken from Maltego.

The quarter prior to the attack simulation, we dedicated some time to gathering information about our call centers’ operational workflows and procedures, the physical security implementation, and also the IT infrastructure setup installed to support the call centers’ operational needs.

As employees in the company, we decided to perform the information gathering by inspecting the documents and procedures related to the call centers’ operations management, facility management, and IT infrastructure management. We also interviewed relevant personnel regarding the topics which we needed to dig deeper into.

Given the method we decided upon to gather the information, we practically conducted a general security audit — instead of just a reconnaissance — during this phase, where we could directly give feedback to the relevant divisions if we found anything of concern that might be a potential security weakness.

Delivering feedback to the call center divisions in this phase would make the following phases of our attack simulation more challenging as they might close the gaps before we could carry out the attack and exploit it. But considering that it was in the best interest of the organization to address possible flaws as soon as possible, we decided that this was the way to go.

We documented everything that might be relevant to our attack simulation and tried to identify possible ways to compromise our call centers based on the information we collected during the security audit. After we were done with collecting information and delivering our feedback to the relevant divisions, we started making hypotheses on possible weaknesses in the system that weren’t visible to us during the general audit phase.

Phase 2: Exploit Development

As we entered the quarter we designated to execute the attack simulation, we started exploring possible attack vectors for us — posing as outside attackers — to gain a foothold inside the call center facilities by leveraging the information we had collected about the call centers.

The goal of this phase is to find a method we can theoretically use to gain unauthorized access to the call center facilities by exploiting possible vulnerabilities and gaps in the call center IT systems and operational workflows. Once a feasible approach is found, we have to develop the right kind of malware that we can deploy in the attack scenario we’re aiming to simulate.

We first set up a test lab environment with an identical setup to the call center IT system we were targeting. We then prepared exploits, malware, and attack plans for us to test on the lab environment according to the hypotheses we previously made.

We also considered scenarios where we must perform a physical break-in to install our custom malware in a call center machine directly to gain remote access and move laterally from there, but in the end, we decided to keep our focus on remote attacks due to time constraints.

A disassembled binary file, image taken from Sentinel One.

By the end of this phase, we had found ways to get around some of the technical security measures implemented by our call center IT team. We also found ways to persist a backdoor in the system, which we had successfully tested in our test environment.

While everything seemed to work flawlessly in the test environment setting, we still needed to see if it would work on our real call center facilities, with real staff and operators. So, we needed to prepare a plan to deliver the attack and install the backdoor on our call center IT system.

Phase 3: Attack Delivery and Persistence

At this point, we already prepared the exploit, the malware, and the C2 (command and control) infrastructure for the attack. The next step was delivering the attack to the call center facilities we were targeting.

Depending on the attack scenario we want to execute, we can choose to deliver the malware by phishing our call center personnel, by exploiting a vulnerable service in the call center, or by physically going to the call center and sneaking into the staff area to install the malware on a workstation. If the malware works as expected, we should gain remote access to a machine inside our call center that we can use to move laterally or to perform further simulated attacks into the system.

We chose to pose as a customer and try to phish our call center operators by sending malware disguised inside customer emails. The result was very good from the perspective of our call center operations security: our attacker didn’t manage to gain access to any of our call centers despite knowing a reliable way to bypass the technical security measures implemented by the call center IT team.

A diagram showing how CrimsonRAT malware is delivered, which is quite similar to how we delivered the malware in this operation. Image taken from Cisco Umbrella.

While we couldn’t tell for sure if the call center operators who received the emails realized that they were dealing with malware, they strictly responded according to their standard operating procedure and didn’t engage with the malware we sent them. And for a case where an operator did try to interact with the malware, they seemed to realize something was off and decided not to engage with it any further before it managed to infect their workstation — despite our attacker’s persistent attempts to push and persuade them into running the malware.

Since the time we allocated for the operation was almost up at that point and the team had several other projects that we needed to handle, we decided to not bother our call center operators any further and move on to the next phase.

Phase 4: Reporting, Feedback, and Improvements

We didn’t manage to fulfill our win condition of gaining a foothold and installing a backdoor inside our call center facilities, but we did notice a few areas we could improve in our call center’s security posture — especially in how the call center operators’ responded to our attacker and in how the technical security measures were implemented by the call center IT team.

We wrote a report of our attack simulation and the security concerns we identified during the operation and sent it to relevant divisions as feedback with a list of actionables for each respective division. This served as valuable insights for the organization to further improve the security of the call center divisions.

What we hoped would happen to the company after we submitted the report.

For the actionables in the IT system improvement department, we also explored a few alternative solutions the call center IT operations team can explore related to the system components we have security concerns with — specifically for the components used in the security measures we managed to bypass consistently in our test environment setup. We explored a few alternative solutions and did some benchmarking to compare them. We then presented the data to the call center IT operations team along with our recommendations for system improvements.

Conclusion

While we didn’t manage to fulfill the win condition of the operation — gaining persistent access to our call center using an unauthorized mean — it doesn’t necessarily mean that the operation was a failure. In fact, the operation ended with a win for both the information security team and the organization as a whole.

We managed to identify several weaknesses in the system — which might be exploitable by a more persistent attacker — and helped drive the organization to address the said weaknesses. The information security team served as an advisor to the call center divisions when they were addressing the issues we brought to light, to help ensure the organization ends up with an improved security posture — which is the purpose of the team and the primary value the team brings to the organization.

The simulated attack on our call centers was our first attempt at an offensive operation with a relatively big scope and a lot of room for creativity in our choices of attack methods. Aside from providing us with the insights we can use to improve the company’s security posture, this operation also serves as a great learning experience for our information security team.

--

--

Edwin Tunggawan
Cermati Group Tech Blog

If I’m not writing code, I might be reading some random stuff.