In recent years, we noticed that more and more malicious Adobe Flash (.SWF) files are being incorporated into exploit kits like the Magnitude Exploit Kit, the Angler Exploit Kit, and the Sweet Orange Exploit Kit. However, we did some more digging and found out that the number of Flash files isn’t the only thing that has changed: these files use obfuscation techniques than files from two to three years ago.
Antivirus evasion is the primary goal of obfuscation. SWF files use obfuscation techniques to avoid detection by signatures and by emulation. While there are numerous obfuscation techniques, I will discuss four techniques that are commonly used and found in exploit kits.
In this technique, key data may be disguised as strings, which will be processed by the String.substr and String.replace APIs. If the data is numeric, it could be translated from the parseInt function.
Figure 1. Sample strings
Figure 1 comes from a sample of the Sweet Orange Exploit Kit. In this screenshot, the data is hidden in strings such as FRE2325D5E0CC4. This particular data is a memory address, used in malware code.
Special address values could also be hidden in strings that would be processed dynamically. Such a method could be used to evade signature detection by way of checking information in the constant pool. The constant pool saves important information that could be used by Flash Player—which can be used as a detection method.
Figure 2. Sample strings
In Figure 2, the value of _loc23_ is 0x9FRE2R9FRE2R9FRE2R9FRE2R. In reality, the value of _loc23_ is actually 0x90909090, which could be used as a NOP instruction in shellcode. The NOP instruction is often just a placeholder but this is often used in heap spraying. Thus, one simple detection technique would be to check for the value 0x90909090. Replacing it with 0x9FRE2R9FRE2R9FRE2R9FRE2R is a way of avoiding detection.
Array-based Embedded Flash
In this type of obfuscation, the malicious SWF content is stored in an Array object, which is built in a sub function, such as the function cartd() in the screenshot below. If they analyze the decompiled code, security products will not detect any malicious behavior (as the malicious SWF content did not load).
Figure 3. Sample from the Fiesta Exploit Kit
In Figure 3, the embedded SWF content is saved into the Array object. Once the array is deobfuscated, the content is decoded and the embedded SWF content is loaded by the loadBytes API.
This sample also displays the string replacement technique. The strings writeUnsignedInt and addEventListener are used in decoding obfuscated data in SWF content. Here, they are processed via string concatenation. String concatenation is the process of appending one string to the end of another string. It would be hard to find evidence of malicious routines via string matching as concatenation would result in modified strings.
Control Flow Obfuscation
This type of obfuscation changes the control flow by the goto instruction. Control flow refers to “the order in which the individual statements, instructions, or function calls of an imperative or a declarative program are executed or evaluated.” Changing the control flow makes it difficult to literally read and process the malicious Flash file in p-code detections.
Figure 4. Changes in flow of code in the sample from the Angler Exploit Kit
Obfuscation in DoSWF Packer
As one of the more well-known exploit kits, the Magnitude Exploit Kit uses highly obfuscated malware. In this particular sample, it’s packed by a commercial Flash packer named DoSWF. A close look shows that the obfuscated data (the embedded .SWF file and some control data) is saved in the binary data tag.
Figure 5. Malicious SWF file saved in binary data; highlighted portion is the trademark of the packer used
The code below is used to extract content from the binary data shown in Figure 5. Here, ZG is a ByteArray that represents the obfuscated data. It defines its own memory domain—the Flash file runtime environment—by using flash.utils.ByteArray. Modifying its domain not only makes it harder for AV products to detect it but also make it easier for the malware to perform its routines. It then uses op_li8/op_li32 to use direct memory access through the avm2.intrinsics package. These could be used to evade emulators as most VM software do not implement these instruments. The intrinsic instruments are implemented by Tamarin, which is the ActionScript Virtual Machine (AVM) in Adobe Flash Player.
Figure 6. Code used to extract the binary data
Looking at the uncompressed data, we can see that some garbage .SWF files will be created in memory, which can disturb memory searches and make it harder for products and researchers to find the malware. It will then load the malicious .SWF file by calling the loadBytes API to execute the said file.
Figure 7. Garbage files generated
The Future of Flash Files
We predict that we will continue to see malicious Flash files be used in exploit kits. As Flash packers can easily obfuscate SWF files easily, we can predict that these will be used more in cybercriminals’ schemes. Of course, the increased use of Flash packers could also mean more difficulty in detecting the malicious files.
Trend Micro detects and blocks the malware (detected as SWF_EXPLOYT.MJE) mentioned in this entry.
Hashes for the samples mentioned in this entry are as follows:
Posted: 24 Nov 2014 | 10:32 am
Posted: 24 Nov 2014 | 8:27 am
In the spring of 2012, following a Kaspersky Lab presentation on the unusual facts surrounding the Duqu malware, a security researcher contacted us and mentioned that Duqu reminded him of another high-end malware incident. Although he couldn't share a sample, the third-party researcher mentioned the "Regin" name, a malware attack that is now dreaded by many security administrators in governmental agencies around the world.
For the past two years, we've been tracking this most elusive malware across the world. From time to time, samples would appear on various multi-scanner services, but they were all unrelated to each other, cryptic in functionality and lacking context.
It's unknown exactly when the first samples of Regin were created. Some of them have timestamps dating back to 2003.
The victims of Regin fall into the following categories:
So far, we've observed two main objectives from the attackers:
While in most cases, the attackers were focused on extracting sensitive information, such as e-mails and documents, we have observed cases where the attackers compromised telecom operators to enable the launch of additional sophisticated attacks. More about this in the GSM Targeting section below.
Perhaps one of the most publicly known victims of Regin is Jean Jacques Quisquater (https://en.wikipedia.org/wiki/Jean-Jacques_Quisquater), a well-known Belgian cryptographer. In February 2014, Quisquater announced he was the victim of a sophisticated cyber intrusion incident. We were able to obtain samples from the Quisquater case and confirm they belong to the Regin platform.
Another interesting victim of Regin is a computer we are calling "The Magnet of Threats". This computer belongs to a research institution and has been attacked by Turla, Mask/Careto, Regin, Itaduke, Animal Farm and some other advanced threats that do not have a public name, all co-existing happily on the same computer at some point.
The exact method of the initial compromise remains a mystery, although several theories exist, which include man-in-the-middle attacks with browser zero-day exploits. For some of the victims, we observed tools and modules designed for lateral movement. So far, we have not encountered any exploits. The replication modules are copied to remote computers by using Windows administrative shares and then executed. Obviously, this technique requires administrative privileges inside the victim's network. In several cases, the infected machines were also Windows domain controllers. Targeting of system administrators via web-based exploits is one simple way of achieving immediate administrative access to the entire network.
In short, Regin is a cyber-attack platform which the attackers deploy in the victim networks for ultimate remote control at all possible levels.
The platform is extremely modular in nature and has multiple stages.
Regin platform diagram
The first stage ("stage 1") is generally the only executable file that will appear in victim' systems. Further stages are stored either directly on the hard drive (for 64 bit systems), as NTFS Extended Attributes or registry entries. We've observed many different stage 1 modules, which sometimes have been merged with public sources to achieve a type of polymorphism, complicating the detection process.
The second stage has multiple purposes and can remove the Regin infection from the system if instructed so by the 3rd stage.
The second stage also creates a marker file that can be used to identify the infected machine. Known filenames for this marker are:
Stage 3 exists only on 32 bit systems - on 64 bit systems, stage 2 loads the dispatcher directly, skipping the third stage.
Stage 4, the dispatcher, is perhaps the most complex single module of the entire platform. The dispatcher is the user-mode core of the framework. It is loaded directly as the third stage of the 64-bit bootstrap process or extracted and loaded from the VFS as module 50221 as the fourth stage on 32-bit systems.
The dispatcher takes care of the most complicated tasks of the Regin platform, such as providing an API to access virtual file systems, basic communications and storage functions as well as network transport sub-routines. In essence, the dispatcher is the brain that runs the entire platform.
A thorough description of all malware stages can be found in our full technical paper.
The most interesting code from the Regin platform is stored in encrypted file storages, known as Virtual File Systems (VFSes).
During our analysis we were able to obtain 24 VFSes, from multiple victims around the world. Generally, these have random names and can be located in several places in the infected system. For a full list, including format of the Regin VFSes, see our technical paper.
With high-end APT groups such as the one behind Regin, mistakes are very rare. Nevertheless, they do happen. Some of the VFSes we analyzed contain words which appear to be the respective codenames of the modules deployed on the victim:
Another module we found, which is a plugin type 55001.0 references another codename, which is U_STARBUCKS:
The most interesting aspect we found so far about Regin is related to an infection of a large GSM operator. One VFS encrypted entry we located had internal id 50049.2 and appears to be an activity log on a GSM Base Station Controller.
According to the GSM documentation (http://www.telecomabc.com/b/bsc.html): "The Base Station Controller (BSC) is in control of and supervises a number of Base Transceiver Stations (BTS). The BSC is responsible for the allocation of radio resources to a mobile call and for the handovers that are made between base stations under his control. Other handovers are under control of the MSC."
Here's a look at the decoded Regin GSM activity log:
This log is about 70KB in size and contains hundreds of entries like the ones above. It also includes timestamps which indicate exactly when the command was executed.
The entries in the log appear to contain Ericsson OSS MML (Man-Machine Language as defined by ITU-T) commands.
Here's a list of some commands issued on the Base Station Controller, together with some of their timestamps:
2008-04-25 11:12:14: rxmop:moty=rxotrx; 2008-04-25 11:58:16: rxmsp:moty=rxotrx; 2008-04-25 14:37:05: rlcrp:cell=all; 2008-04-26 04:48:54: rxble:mo=rxocf-170,subord; 2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a; 2008-04-26 10:06:03: IOSTP; 2008-04-27 03:31:57: rlstc:cell=pty013c,state=active; 2008-04-27 06:07:43: allip:acl=a2; 2008-04-28 06:27:55: dtstp:DIP=264rbl2; 2008-05-02 01:46:02: rlstp:cell=all,state=halted; 2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active; 2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x; 2008-05-12 17:28:29: rrtpp:trapool=all;
Descriptions for the commands:
The log seems to contain not only the executed commands but also usernames and passwords of some engineering accounts:
In total, the log indicates that commands were executed on 136 different cells. Some of the cell names include "prn021a, gzn010a, wdk004, kbl027a, etc...". The command log we obtained covers a period of about one month, from April 25, 2008 through May 27, 2008. It is unknown why the commands stopped in May 2008 though; perhaps the infection was removed or the attackers achieved their objective and moved on. Another explanation is that the attackers improved or changed the malware to stop saving logs locally and that's why only some older logs were discovered.
The C&C mechanism implemented in Regin is extremely sophisticated and relies on communication drones deployed by the attackers throughout the victim networks. Most victims communicate with another machine in their own internal network, through various protocols, as specified in the config file. These include HTTP and Windows network pipes. The purpose of such a complex infrastructure is to achieve two goals: give attackers access deep into the network, potentially bypassing air gaps and restrict as much as possible the traffic to the C&C.
Here's a look at the decoded configurations:
184.108.40.206 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443 220.127.116.11 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443 18.104.22.168 transport 27 22.214.171.124 ; transport 50035 194.z.z.z:8080 126.96.36.199 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322 188.8.131.52 transport 50271 DC ; transport 50271 DC
In the above table, we see configurations extracted from several victims that bridge together infected machines in what appears to be virtual networks: 17.3.40.x, 50.103.14.x, 51.9.1.x, 18.159.0.x. One of these routes reaches out to the "external" C&C server at 184.108.40.206.
The numbers right after the "transport" indicate the plugin that handles the communication. These are in our case:
The machines located on the border of the network act as routers, effectively connecting victims from inside the network with C&Cs on the internet.
After decoding all the configurations we've collected, we were able to identify the following external C&Cs.
|C&C server IP||Location||Description|
|220.127.116.11||Taiwan, Province Of China Taichung||Chwbn|
|18.104.22.168||India, Chetput||Chennai Network Operations (team-m.co)|
|22.214.171.124||India, Thane||Internet Service Provider|
|126.96.36.199||Belgium, Brussels||Perceval S.a.|
One particular case includes a country in the Middle East. This case was mind-blowing so we thought it's important to present it. In this specific country, all the victims we identified communicate with each other, forming a peer-to-peer network. The P2P network includes the president's office, a research center, educational institution network and a bank.
These victims spread across the country are all interconnected to each other. One of the victims contains a translation drone which has the ability to forward the packets outside of the country, to the C&C in India.
This represents a rather interesting command-and-control mechanism, which is guaranteed to raise very little suspicions. For instance, if all commands to the president's office are sent through the bank's network, then all the malicious traffic visible for the president's office sysadmins will be only with the bank, in the same country.
Over the past two years, we collected statistics about the attacks and victims of Regin. These were aided by the fact that even after the malware is uninstalled, certain artifacts are left behind which can help identify an infected (but cleaned) system. For instance, we've seen several cases where the systems were cleaned but the "msrdc64.dat" infection marker was left behind.
So far, victims of Regin were identified in 14 countries:
In total, we counted 27 different victims, although it should be pointed out that the definition of a victim here refers to a full entity, including their entire network. The number of unique PCs infected with Regin is of course much, much higher.
From the map above, Fiji and Kiribati are unusual, because we rarely see such advanced malware in such remote, small countries. In particular, the victim in Kiribati is most unusual. To put this into context, Kiribati is a small island in the Pacific, with a population around 100,000.
More information about the Regin victims is available through Kaspersky Intelligent Services. Contact: firstname.lastname@example.org
Considering the complexity and cost of Regin development, it is likely that this operation is supported by a nation-state. While attribution remains a very difficult problem when it comes to professional attackers such as those behind Regin, certain metadata extracted from the samples might still be relevant.
As this information could be easily altered by the developers, it's up to the reader to attempt to interpret this: as an intentional false flag or a non-critical indicator left by the developers.
More information about Regin is available to Kaspersky Intelligent Services' clients. Contact: email@example.com
For more than a decade, a sophisticated group known as Regin has targeted high-profile entities around the world with an advanced malware platform. As far as we can tell, the operation is still active, although the malware may have been upgraded to more sophisticated versions. The most recent sample we've seen was from a 64-bit infection. This infection was still active in the spring of 2014.
The name Regin is apparently a reversed "In Reg", short for "In Registry", as the malware can store its modules in the registry. This name and detections first appeared in anti-malware products around March 2011.
From some points of view, the platform reminds us of another sophisticated malware: Turla. Some similarities include the use of virtual file systems and the deployment of communication drones to bridge networks together. Yet through their implementation, coding methods, plugins, hiding techniques and flexibility, Regin surpasses Turla as one of the most sophisticated attack platforms we have ever analysed.
The ability of this group to penetrate and monitor GSM networks is perhaps the most unusual and interesting aspect of these operations. In today's world, we have become too dependent on mobile phone networks which rely on ancient communication protocols with little or no security available for the end user. Although all GSM networks have mechanisms embedded which allow entities such as law enforcement to track suspects, there are other parties which can gain this ability and further abuse them to launch other types of attacks against mobile users.
Kaspersky products detect modules from the Regin platform as: Trojan.Win32.Regin.gen and Rootkit.Win32.Regin.
If you detect a Regin infection in your network, contact us at: firstname.lastname@example.org
Posted: 24 Nov 2014 | 6:00 am
On 23/11/14 At 10:54 PM
Posted: 24 Nov 2014 | 1:59 am
Security software outfit Avast are trying to figure out why the combination of recent Windows patches and updates to the latter company's software are breaking PCs.…
Posted: 24 Nov 2014 | 12:32 am
As you see, all Windows traffic captures have identical fields following the GZIP stream, while OSX traffic has different data. The jar files that had Pony Downloader payload did not have other OSX malware packaged and I saw no activity on OSX other than calling the C2 and writing to the randomly named timestamp file (e.g VblVc5kEqY.tmp - updating current timestamp in Unix epoch format)
Posted: 18 Nov 2014 | 4:25 am
There’s a lot of sites covering this vulnerability but I wanted to document some indicators for anyone who might need it.
What follows is a brief walk-through of evidence found on a couple of compromised hosts. YMMV.
Logging into phpMyAdmin and checking out the “users” table. Two accounts were created. The “drupaldev” account seems to have been found on many compromised hosts.
There was one host that had hundreds of accounts. What made the malicious accounts stand out was the missing mail field. This would occur if the user could get past the requirement on the registration page or if the account was added directly to the table.
Going to the “sessions” table, there’s one entry with the “uid” that matches the account created by the attacker. You can find out the attacker’s IP address this way.
Here’s info on this IP address:
The firewall logs showed activity over port 8888. If you visit the IP:port, you get this site:
Looking at the webserver logs, we can see POSTs hitting the user/login file on the host. The server 500 errors probably indicate a failed first attempt.
Going back to phpMyAdmin, a quick search for “.php” was done across all of the tables.
There was an entry found in the “menu_router” table which seems to be a very common indicator.
Clicking on the link, you can download the blob.
Going to the file system, there is a directory called “README.txt” with a php file inside. The folder and file names appear to be random but the script itself is the same as what others have reported.
This PHP script is particularly interesting, it’s a simple backdoor that’s triggered by a cookie. Sucuri covered this awhile ago.
Here’s a cleaned up version. If you hit the script straightaway, you will get the results of phpinfo(). If you wish to send your own commands, you need to pass three variables. The “Kcqf3″ variable contains a value that triggers the script. The second variable “Kcqf2″ will be preg_replace. “Kcqf1″ contains the command. I imagine the attackers might send commands along the lines of uname, wget, curl, etc.
I wrote a program to craft HTTP requests and can include my own cookie values into the header. Here, I’m sending the phpinfo command and you can see the result in the background. What stands out is its simplicity and cleverness.
You could create an IDS rule to look for HTTP requests that contain a cookie with the value “preg_replace” and detect/block those coming in. You can then follow up on the targeted host to see if the backdoor is there.
Posted: 2 Nov 2014 | 3:52 pm
Yesterday, another cyber espionage group with Russian roots made it to the New York Times headlines again courtesy of FireEye and a new report they published.
FireEye did a pretty good job on attribution and giving some technical indicators; however, they neglected to reference previous work on this threat actor from companies like PWC, TrendMicro, ESET and others.
We have been tracking this threat actor (Sofacy) for a few years when it first appeared on our radar in one of the CVE-2012-0158/CVE-2010-3333 clusters. Based on the lure content contained in the malicious documents as well as the phishing campaigns we have seen in the past, this group tends to target NATO, Eastern Europe government and military institutions and defense contractors. We have seen lures related to Ukraine, Chechnya and Georgia that indicates one of the group's objectives is gathering geopolitical intelligence.
The techniques used by this group have evolved over the years.
Most of the Spearphishing campaigns launched by this group involve a malicious Word document exploiting one of the following vulnerabilities:
As described by FireEye and others, this group uses different payloads including a downloader and several second-stage backdoors and implants.
We cover these tools using the following rules with USM:
- Web compromises
The group has been seen infecting websites and redirecting visitors to a custom exploit kit being able to take advantage of the following vulnerabilities affecting Internet Explorer:
The following rule detects activity related to this exploit kit:
- Phishing campaigns
This actor uses phishing campaigns to redirect victims to Outlook Web Access (OWA) portals designed to impersonate the legitimate OWA site of the victim's company. This technique is used to compromise credentials and access mailboxes and other services within the company.
Inspecting the content of the malicious redirect we can alert on this activity using the following rule:
Posted: 28 Oct 2014 | 9:30 pm
A few days ago Admiral Mike Rodgers, director of the NSA and Commander of the U.S. Cyber Command, gave a keynote address at the Billington Cybersecurity Summit. His message was strong and clear, CYBER-RESILIENCY. He discussed the impractical reactions typical to cyber intrusions today. After an attack a network may temporarily shut down and operations will cease in government and private sector organizations alike. Both the Admiral and us here at Cyber Engineering Services believe this is an unnecessary and damaging response.
The goal of network security should be to monitor traffic and be ready to fight as quickly as possible in the face of an attack while keeping the network and productivity online. In his speech the admiral emphasized something that the experts at Cyber Engineering Services were forced to acknowledge long ago, cyber intrusions will happen no matter what defenses are in place. As fast as the good guys can develop technology to stop them, cyber criminals develop new weapons to get into networks.
Accepting this can be a hard pill for companies to swallow as it is natural to want to put an end to all intrusions and data loss. However accepting this problem doesn’t change it’s nature, it allows for the development of more realistic strategies. As the admiral puts it, “This is not a small problem. It’s not going away. Technology will not catch up. This is foundational to the future. I need your help.” Basically, the director of the NSA is explaining the government alone is not going to conquer this problem, private sector needs to step up to the plate and get realistic and proactive.
At Cyber Engineering Services we are very excited to see key individuals in the Cybersecurity war spreading accurate and motivating information. Our whole strategy at Cyber Engineering Services is based on a deep understanding of these realities. We have designed a system and a team of experts that is ready to watch, respond, and stem damage at a moments notice. We are ready to do our part in the Cyber-Resiliency revolution by helping companies monitor their network traffic and respond in a way that stops the damage while keeping companies running and production as smooth as possible.
If you’d like to read more of the Admirals message see the link below to a summary written by Mike Donohue.
Posted: 19 Sep 2014 | 2:46 pm