Skip to content ↓ | Skip to navigation ↓

Earlier this week, Symantec issued a report about the Regin family of malware. The malware itself appears to be sophisticated enough that many security analysts and researchers believe it was developed by a government specifically for cyber espionage.

This family of malware has been compared to Stuxnet; however, this is a poor comparison since Regin does not spread the way Stuxnet did. In fact, the purposes of each malware are quite different.

Stuxnet was designed for sabotage, whereas Regin was likely designed for espionage and as a result was deployed with a great deal more of precision. If anything, the purpose and behavior of the malware is more similar to Flame, another malware family specifically designed for espionage purposes.

There is still very little known about the initial attack vector used to deploy Regin. It appears to have been dropped using a variety of methods, including social engineering, an exploit in Yahoo Messenger and a link to a fake LinkedIn page that functioned as a watering hole.

Sophisticated or Just Good Software Design?

Although Regin was designed to be stealthy, the various phases of the malware deployment can still be detected. The Regin malware actually makes a lot of ‘noise’ given the number of changes it makes on a host system if you have the right tools in place to monitor these changes on host systems.

Many of the methods used by Regin are not necessarily new and from conversations with developers are actually general best practices for developing Windows drivers.

Many of the “sophisticated” techniques used by Regin have been seen before:

  • Regin’s use of naming a driver something innocuous dates back to some of the first viruses floating around in the DOS days
  • The use of a kernel memory pool tag that is generic is not particularly novel, as it’s the default for most drivers
  • Hiding the MZ executable header marker from an executable memory image is an old technique, as well, dating back to the earliest days of 16-bit DOS executables
  • Hiding encrypted data in the registry or NTFS “extended attribute streams” is something the OS does for legitimate reasons and a technique used by many forms of malware (eg. ZeroAccess)
  • Encrypting data for transport is now standard practice for pretty much all malware

The sophistication of the malware isn’t necessarily in the technical implementation, but what appears to be a mature software development lifecycle. The malware has evolved and adapted, using best practices for development, borrowing techniques from other successful malware and has clearly been tested thoroughly to ensure it avoids detection by most antivirus tools.

It is important to realize that malware is now rarely created through ad hoc development, but is a business in itself. Many of the tools, techniques and strategies commercial software vendors use are also in use by malware developers. Just like the commercial software world with malware development, there are open source, as well as well-funded proprietary projects.

Since the details of the malware are now available to the general public, there is a high likelihood that similar malware may be created by criminal groups or other state actors. Although various indicators of compromise have been made available, odds are that the hash values, file names and other indicators have already changed in later versions of the malware.

Leveraging forensic artifacts are useful in identifying known malware, but more important is the ability to detect patterns and behavior of malware and quickly searching for indicators of compromise when signatures and artifacts are known.

Below are a list of hashes and other indicators of compromise related to Regin from the Symantec report. As these are all host based artifacts, Tripwire Enterprise customers can search for these elements in their environments.

File Names and Paths

usbclass.sys msrdc64.dat
adpu160.sys msdcsvc.dat
%System%\config\SystemAudit.Evt %System%\config\SecurityAudit.Evt
%System%\config\SystemLog.evt %System%\config\ApplicationLog.evt
%Windir%\ime\imesc5\dicts\pintlgbs.imd %Windir%\ime\imesc5\dicts\pintlgbp.imd
%Windir%\system32\winhttpc.dll %Windir%\system32\wshnetc.dll
%Windir%\system32\svcstat.exe %Windir%\system32\svcsstat.exe

File MD5

2c8b9d2885543d7ade3cae98225e263b 06665b96e293b23acc80451abb413e50
4b6b86c7fec1c574706cecedf44abded d240f06e98c8d3e647cbf4d442d79475
187044596bc1328efa0ed636d8aa4a5c 6662c390b2bbbd291ec7987388fc75d7
ffb0b9b5b610191051a7bdf0806e1e47 b29ca4f22ae7b7b25f79c1d4a421139d
1c024e599ac055312a4ab75b3950040a ba7bb65634ce1e30c1e5415be3d1db1d
b505d65721bb2453d5039a389113b566 b269894f434657db2b15949641a67532



 Extended Attributes

%Windir% %Windir%\cursors
%Windir%\fonts %Windir%\System32



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].