Why ‘Regin’ Malware Changes Threatscape Economics

Recently, Symantec and Kaspersky Lab released research on an advanced persistent threat (APT) dubbed Regin. Symantec focused on the software’s technical sophistication, its use as an espionage tool, and indications of nation-state origins. Kaspersky concentrated on victimology, the attackers’ objectives, and the compromise of at least one cellular communications network. Impressive (or terrifying, depending on your point of view) as these attributes are, Regin’s real impact on the threatscape is programmatic in nature: Regin fundamentally shifts the economics and timelines of APT development and deployment in the attackers’ favor.

Unlike other APTs, Regin is not a self-contained software package. It’s an evolutionary design, mirroring general software design trends. Historically, software was developed in a monolithic manner. Applications were completely encapsulated and independent from other applications. They contained all the logic necessary to complete any function required. While they might function reliably, monolithic applications were neither easy nor inexpensive to adapt and maintain. Due to their tightly coupled architecture, a minor change in one portion of the codebase often had an impact on other components. This results in lengthy and costly regression testing, repair, and re-engineering phases. Additionally, due to its specialized nature, it is generally difficult to reuse a monolithic program’s components in other development projects.

The answer to monolithic architecture’s inherent shortcomings was modular software architecture. Here, a program’s functionality is divided along logical boundaries into discrete, interchangeable components, each of which executes a specific part of the overall functionality. Typically, modules use well-defined standards to communicate. As long as compliance with the standard is maintained, a module’s internal mechanics can be modified, or the entire module swapped out with another, without affecting the program’s overall functionality. For conceptual purposes, think of Lego® bricks. As long as the studs on top and the hollows on the bottom (the interfaces) are of the proper dimensions, the bricks will snap together, regardless of internal composition or external shape.

It’s all about SOA
The most sophisticated and versatile instantiation of the modular architecture concept is found in a class of products known as service oriented architecture (SOA) middleware platforms. These platforms provide application developers with a set of composable infrastructure components that manage critical functionality between the specific business logic the developer is seeking to implement and the data on which the logic is acting. The platform’s components may provide a combination of capabilities such as (but not limited to) data transport, transformation and mediation, asynchronous communication, data access, identity management, data analytics, application execution, and real-time event processing and analysis.

Developers take advantage of SOA middleware platforms by using them to create versatile and reusable application infrastructures. If properly designed and implemented, an application infrastructure is agnostic to both the business logic that it supports and the data that it processes. As a result, the same infrastructure that is used to support a cellular telephone network can form the basis for a military command-and-control application or an automated concert venue ticketing capability. All that needs to be created are the specific business application modules and data sources. While neither of those is a trivial endeavor, they represent a far smaller resource investment (e.g., time, personnel, funding) than developing both the infrastructural and business logic every time a new capability is desired.

Regin, as Kaspersky and Symantec noted, is not a malware payload in and of itself. Rather, it is a malware platform onto which the attacker can deploy specific business logic to achieve mission objectives. In other words, unlike earlier generations of malware or espionage tools, Regin can be tailored after deployment to exploit targets of opportunity.

[Find out more about Regin in Newly Revealed Cyber Espionage Attack 'More Complex' Than Stuxnet, Flame.]

It’s worth a quick look at the Regin architecture to see how this works. As noted in the reports, Regin loads in five stages. Of these, the fourth stage (called the dispatcher library by Kaspersky and the user framework by Symantec) is the core of the Regin framework, managing complex tasks such as the application programming interface (API) supporting plug-in integration, communications, storage, and data transport. In middleware terms, this is Regin’s application infrastructure. Stage five (Kaspersky: Plug-ins, Symantec: Payload Module) is a tailorable collection of business logic apps, ranging from keyloggers to email message extractors and cellular network command and control utilities.

Taking an architectural page from the SOA middleware book, Regin’s creators have fundamentally altered threatscape economics. Using Regin’s “malicious middleware” paradigm, attackers need not reinvent the wheel each time an APT is generated for a new target. Instead, they can deploy a common platform (Regin), and configure it as necessary with relatively low-cost, quick-turnaround business logic apps. This model provides tremendous economic and temporal efficiencies for the attacker that shorten decision cycle times, thus increasing difficulty for cyber defenders.

By technically addressing the programmatic and economic side of the malware development lifecycle, Regin represents a leap forward in sophistication, planning, and effectiveness. Extensible, composable, and modular malware, it seems, is here to stay. Defenders, up your game.