Don’t just track threats. Test them.
Security leaders have no shortage of threat intelligence. The harder part is knowing what to do with it. How do you know whether your organization could withstand the attacks you’re reading about? We’ve created three practical attack scenarios modeled on current attack techniques observed in the wild. Use them to challenge assumptions, validate controls, and test how your organization would respond if the attack happened tomorrow.
Scenario: Lazarus Group targets financial institutions through the compromise of core infrastructure in a supply chain incident
This scenario was derived from a regulated threat-led penetration test conducted by Reversec for an unnamed organisation in the financial sector. It is inherently relevant to the key themes presented throughout this report. While full scenarios are derived from extensive reconnaissance, threat assessment, and understanding of internal and external infrastructure, this is as close as is possible.
Indicative high-level scenario
Reversec attempted to gain initial access to the organisation by targeting the password reset process. Passwords could be reset remotely for any employee and were handled by the Help Desk. The process, roughly, involved an employee calling the Help Desk and asking them to reset their password.
In a mature organisation, Multi-Factor Authentication (MFA) is the minimum standard nowadays, so an attempt was made to reset that as well. Before the call to the Help Desk was made, external reconnaissance and user enumeration were conducted. As the red team did not know the exact password reset process, it was crucial to target an employee about whom as much information as possible was known. Once sufficient data had been collected, a call to the Help Desk was placed.
Due to poor identity validation, both the password and MFA were reset, allowing the red team to gain access to a virtual desktop infrastructure (VDI). Since Reversec operates a “non-interruption policy” for target users, the engagement continued using synthetic accounts created by the organisation. This approach caused minimal disruption to the user. Although their access was affected, requiring them to reset their credentials again on the next working day, it did not meaningfully impact their ability to perform their duties.
Once the red team started operating within the environment, reconnaissance revealed that a Jenkins installation was exposed in a shared folder accessible to any user in the domain. Inside that directory, all the information required to decrypt credentials stored in Jenkins was available. Reversec decrypted those credentials and gained access to the Jenkins web interface. By using the Groovy plugin, it was possible to execute operating system commands on the underlying Jenkins server. Although unfiltered internet access was not permitted, Reversec was able to disguise SSH traffic to bypass inspection controls, enabling a long-term persistent SSH tunnel to be established. This provided an alternative command-and-control (C2) channel to the more traditional implants that had previously been used.
Additionally, various types of credentials were identified. Most importantly, AWS keys were discovered that provided access to highly sensitive AWS resources. By performing lateral movement within AWS, Reversec obtained sufficient permissions to read secrets related to payment systems.
As a proof of concept, Reversec demonstrated access to a payment system database. Due to the nature of the data stored within the database, Reversec did not proceed any further, as the objective had already been achieved.
Threat intelligence tells you what attackers are doing. Attack simulation shows whether it would work against you.
If this scenario feels uncomfortably plausible, it may be time to validate your resilience. Reversec’s research-led offensive security experts help organizations identify and address the security gaps that matter most to their business.
