Today's malware of the moment, something called Regin, has just made the news because of an announcement by security researchers at Symantec. But it's important to know that the only thing that's new is Symantec's announcement. Regin has actually been around for years, perhaps as long as a decade.
In fact, I'd heard from senior security executives about some state-sponsored malware they were trying to get a handle on during meetings at CeBIT in 2013. At the time nobody was really sure exactly what this cyber-spy malware did, where it came from or what its intended purpose might be.
Most of that is still true. But it turns out that the original reason why the much-discussed Regin malware may have been created was as a way to get call data from GSM phone networks. The National Security Agency has admitted to gathering such call data from voice networks and by all accounts is still gathering it.
But what makes Regin unique is not so much what it does, but rather how it works. What Regin (short for reg–in or "in registry") provides is a platform that can be used to load nearly anything that you're likely to want for information gathering. Researchers have found a wide variety of intelligence-gathering functions in the malware, including key logging, network sniffing and password stealing, according to Liam Murchu, senior development manager for Symantec Security Response.
"It's a sophisticated platform for delivering modules onto computers," Murchu told eWEEK. "Each victim gets different modules." He noted that one thing that's very unusual is that Regin has been used to attack a variety of targets including telecom companies, airlines, hotels and government agencies. But according to research by Kaspersky Lab, it was initially aimed at telephone networks.
Regin is also unusual in the means by which it loads itself into the Windows computer that's hosting it and in how it avoids detection. While the initial loader exists as a device driver or application on the hard disk of the target computer, the rest of the executable code exists in two places that aren't always checked. One is in the portions of Windows Extended Attribute code that were originally written to support Microsoft's long-abandoned collaboration with OS/2.
The second area is in the Windows Registry on infected computers. The registry is a database on Windows computers that keeps track of the resources and configuration of installed software. The sequence appears to be that the initial loader gets the rest of its code from where it's stored in the Extended Attributes.