Malware RSS Feed

Infosecurity Europe 2015

Malware Alerts - Thu, 06/04/2015 - 04:23

This week we joined droves of vendors and executives in celebrating InfoSecurity Europe’s 20 year anniversary. The venue, the London Olympia, is a behemoth filled wall-to-wall with company banners, awkward sales pitches, gimmicky totebags, gift lightsabers, and ‘free’ prosecco readily exchanged for cloud security pitches.

Security vendors, security vendors everywhere

This year, the organizers wisely decided to add a small conference annex under the banner of ‘Intelligent Defence’ with the intention of attracting a more content-oriented crowd. The talks were largely research-oriented and included a fair serving of IoT bashing and malware hunting.

Here we presented our ongoing research project on whitelisting titled ‘Wolf in Sheep’s Clothing: Your next APT is Already Whitelisted’ – stay tuned for an extensive analysis!

Intelligent Defence included notable presentations by Andrew Hay (OpenDNS), Daniel Mende (ENRW), and Sergey Bratus (Dartmouth). Hay gave us a preview of his ‘labor of love’ paper on IoT beaconing in the enterprise (found here), an extensive research into the domain queries common IoT products perform out of the box and their unregulated penetration into industry verticals.

Daniel Mende walked us through performing an analysis of proprietary network protocols, effectively lifting the veil of security by obscurity by not just showcasing the failure of this particular nameless protocol but also providing the crowd with a sense of the relative ease with which these protocols can be probed, dismantled, and effectively obviated.

Finally, Sergey Bratus shared a brilliant exposition of the complex relationship between defensive and offensive computing, partially defined in terms of ‘weird machines‘  to ease a widespread difficulty in describing the dynamics that enable fruitful InfoSec research  – that difficulty subsequently leads to problematic regulatory over simplifications like the expansion of the Wassenaar arrangement currently under consideration.

Intelligent Defence is a strong step in the right direction for Europe’s largest InfoSec conference. We hope to see you there next time.

Change that password!

SANS Tip-of-the-Day - Wed, 06/03/2015 - 22:36

Know your IMEI?

SANS Tip-of-the-Day - Sun, 05/31/2015 - 21:37

Mobile Forensics World 2015

Malware Alerts - Sun, 05/31/2015 - 18:52

A little discussed but well-attended dual-lineup conference on forensics and investigations started today in Myrtle Beach, South Carolina as “Mobile Forensics World” and the “Techno Security and Forensics Investigations Conference”. Presentation content here mostly focuses on technologies used in fighting cybercrime malware and the general misuse of mobile and computing power for serious criminal activities. Some of the talks focused on the new complexities and challenges in working with ubiquitous SSD storage technologies. One of the notable talks on SSD was from our colleagues at Belkasoft, developers of a set of reliable and effective memory dump and analysis tools. We met some of Yuri Gubanov‘s squirrels that help drive much of their tool development (a “belka” is a squirrel).

Other talks and vendors today brought to light problems and solutions for dealing with Tor, remote system access, data wiping tools, forensically acquired drives that require startup, iPhone and Android encryption and lockout technologies, and others that require examination. Upcoming talks provide discussion around audit strategies and methods, investigation and forensic tools, and more.

Lessons learned from Flame, three years later

Malware Alerts - Fri, 05/29/2015 - 07:08

Three years ago, on May 28th 2012, we announced the discovery of a malware known as Flame. At the same time we published our FAQ, CrySyS Lab posted their thorough analysis of sKyWIper. A few days earlier, Maher CERT published IOCs for Flamer. In short, Flame, sKyWIper and Flamer are different names for the same threat, which took the world by surprise as the first major discovery after Stuxnet and Duqu.

Since the discovery of Flame, we reported on many other advanced malware platforms, including Regin and Equation, yet Flame remains special in terms of being one of the most complex, surprising and innovative malware campaigns we have ever seen.

Looking back at the discovery of Flame, here are some lessons we learned.

  1. High-end, government-grade malware can be big. A fully deployed set of Flame modules took about 20 megabytes, which was a lot. Previously, sophisticated malware would range in the order of kilobytes or hundred of kilobytes; most people would discard a 6MB executable file as “uninteresting”. Not anymore.
  2. Jumping airgaps. Flame was one of the first malware to implement a mechanism to bypass airgaps through the use of USB sticks. When a USB stick was plugged into a Flame infected computer without connection to the Internet, the malware saved stolen information into a hidden file on the stick. This file was invisible to most file explorers and contained up to 16MB of stolen documents and other information from the victim’s machine. When such a stick was connected to a machine infected by Flame connected to the Internet, the hidden information was taken off the stick and sent to its C&Cs.
  3. Dozens of C&Cs. With Flame, we ended up counting almost 100 different command and control servers. For a targeted malware, this is both unusual and a very large number. The authors of Flame created different versions of the malware connecting to many C&Cs in order to limit the impact of a takedown.
  4. Capturing Bluetooth audio. One of the Flame modules attempted to identify Bluetooth devices in the vicinity of the compromised machine and use them to record audio from the room. This is a rare type of attack pioneered by Flame.
  5. The age of mass surveillance. We believe the main purpose of Flame was to facilitate mass surveillance. The malware was designed to automatically collect everything from infected machines, ranging from documents to screenshots, keystrokes and audio. The C&C servers of Flame did not include a provision for a manual operation of the malware; everything happened automatically.
  6. MD5 is dead. One of the most interesting features of Flame was the way it infected other computers in the local network. The attack involved the almost magical re-engineering of a certificate that could be used to sign Windows updates. The certificate relied on an MD5 signature, which the attackers managed to fake, indicating they had the ability to break arbitrary MD5 hashes.
  7. Subversion of trust in Windows updates. One of the most interesting modules in Flame performed what eventually described as a “God mode” exploit – subversion of Windows updates by hijacking Windows update requests. For years, we told people to update Windows, as well as any other third party, as often as possible. Flame took advantage of the trust people have put into updates, effectively subverting it.
  8. The tip of the iceberg. After we discovered Flame, our generic detection started to trigger on other samples as well. By code similarity, we found two other malicious programs from the same group: Gauss and MiniFlame. This made us realize that there are many other undiscovered malware and it will probably take years to find them all.
  9. Everything’s connected. When we discovered Flame, most people asked – “is it related to Stuxnet?”. We’ve said, “no, there are no signs”. We were wrong. Weeks later, we found a Flame module that was also used by the 2009 version of Stuxnet for replication. Essentially, the 2009 Stuxnet was built to replicate using an exploit from Flame. This indicates the two were indeed connected. At the same time, Stuxnet was connected to Duqu and, as we found more recently, the Equation group, through their exploits originally used by the Fanny worm. Sometimes it takes longer to see all the connections, even if they are not obvious in the beginning.
  10. “Flame is lame”. When Kaspersky and CrySyS Lab published our analyses of Flame, some people discarded it as uninteresting. “A 20 megabytes malware can be l33t? Impossible!”. (The complaints died when the Microsoft Windows Updates attack and MD5 collision was found and patched). Mikko Hypponen from F-Secure has a wonderful blog on this topic:

Finally, we’d like to end with a recording of a fantastic speech by privacy rights activist Chris Soghoian, titled “Lessons from the Bin Laden Raid and Cyberwar: Immunizations and Security Updates”.

His take on Flame begins at 5:00, however, we recommend you watch the entire clip. As Chris puts it in the clip: “no matter the short term intelligence advantage to hacking software updates, it isn’t worth it”. We concur and add, subverting security will always backfire.

Statistics on botnet-assisted DDoS attacks in Q1 2015

Malware Alerts - Fri, 05/29/2015 - 05:00

Statistics on botnet-assisted DDoS attacks in Q1 2015 [pdf]


A DDoS (Distributed Denial of Service) attack is one of the techniques mostly often used by cybercriminals. It is intended to reduce an information system, typically a website, to a state where it cannot be accessed by legitimate users. One popular DDoS scenario is a botnet-assisted attack.

Kaspersky Lab has long-standing, recognized expertise in combatting cyberthreats, including DDoS attacks of different types and varying degrees of complexity. The company’s experts, in particular, monitor botnet activity with the help of the DDoS Intelligence system (a part of Kaspersky DDoS Protection solution), which allows them to continuously improve our DDoS attack protection technologies. The DDoS Intelligence system is based on analyzing commands that arrive to botnets from C&C servers; it does not require a bot to be present on a user device, nor commands from the C&C server to be executed.

There are different approaches to analyzing DDoS activity. One of these is to focus on attacks against specific web resources, typically those belonging to clients protected against DDoS attacks by security service providers. However, the analysis of botnet activity in this report provides a different view of this problem, compared to the individual client-based approach.

This report presents DDoS Intelligence statistics collected from 1 January to 31 March 2015 (or Q1 2015), which is analyzed in comparison with the equivalent data collected within the previous 3-month period (1 October to 31 December 2014, or Q4 2014).

In this report, a single DDoS attack is defined as an incident during which there was no break in botnet activity lasting longer than 24 hours. Thus, if the same web resource was attacked by the same botnet after a 24-hour gap that would be regarded as two separated DDoS attacks. Attacks on the same web resource from two different botnets are also regarded as individual attacks.

The geographical distribution of DDoS victims and command & control servers is determined according to their IP addresses. In this report, the number of the unique DDoS targets is defined based on the number of unique IP addresses reported in the quarterly statistics.

It is important to note that DDoS Intelligence statistics are limited to those botnets that were detected and analyzed by Kaspersky Lab. It should also be borne in mind that botnets are only one of the tools for carrying out DDoS attacks; thus, the data presented in this report does not cover every last DDoS attack that has occurred within the specified time period. 

Main findings
  • In Q1 2015, 23,095 botnet-assisted DDoS attacks were reported, which is 11% lower than the 25,929 attacks in Q4 2014.
  • There were 12,281 unique victims of DDoS attacks in Q1 2015, which is 8% lower than the 13,312 victims in Q4 2014.
  • China, the USA and Canada were the countries that faced the largest number of DDoS attacks.
  • The most prolonged DDoS attack in Q1 2015 lasted for 140 hours (or about 6 days). The most frequently attacked resource faced 21 attacks within the 3 months.
  • In Q1 2015, SYN DDoS and HTTP DDoS were the most common scenarios for botnet-assisted DDoS attacks.
Geography of attacks

In Q1 2015, 23,095 DDoS attacks were reported, targeting web resources in 76 countries. The number of attacks was down 11% against Q4 2014 (25,929). There was an increase (76 against 66 in Q4 2014) in the number of countries where DDoS targets were located.

In Q1 2015, 23,095 DDoS attacks were reported, targeting web resources in 76 countries


Most DDoS attacks targeted web resources in China, the USA and Canada – this was no change from Q4 2014. There were some changes in the order of the 10 most frequently attacked countries, but there were no new additions to that list.

Figure 1. The 10 most frequently attacked countries in Q4 2014 and Q1 2015

As seen in the above diagram, there has been a significant decrease in the number of attacks against the web resources in China and the United States of America; however, there was an increase in the number of attacks against Canadian servers. There was also an increase in the number of attacks against web resources in Russia, South Korea and France.

If we consider the number of DDoS attack victims in each country, the top 10 looks the same as the previous one. In Q1 2015, botnets attacked a total of 12,281 victims, which is 8% lower than the 13,312 targets in Q4 2014.

Figure 2. TOP 10 countries with the highest numbers of unique DDoS victims in Q4 2014 and Q1 2015

In Russia, South Korea and France, the number of attacked web resources has increased compared with Q4 2014, and so did the number of attacks on all targets located in these countries. In Canada, the number of attacks has increased, but the number of targets has decreased, which suggests that cybercriminals are more actively attacking a limited number of web resources in the country.

China, the USA and Canada were the countries that faced the largest number of DDoS attacks


The fact that China and the USA lead the two rankings, both in terms of numbers of DDoS attacks and in numbers of victims, is explained by the relatively low web hosting prices in these two countries that encourage many companies to use hosting providers there.

In in Q1 2015, the maximum number of attacks carried out on the same web resource reached 21:

Number of DDoS attacks The targeted web resource 21 A Russian-language web-site (a group of investment companies) 16 A Vietnamese web-site (wedding services provider) 15 A hosting provider in the USA

Figure 3. TOP 3 most frequently attacked web resources in Q1 2015

Although China, the USA and Canada sustained the highest number of DDoS attacks in Q1 2015, the top two most frequently attacked web resources were respectively a Russian and a Vietnamese web-site. Only one of the top three, a US hosting provider, is based in the most frequently attacked trio of countries. 

Time variations in the number of DDoS attacks

In Q1 2015, there were substantial time variations in the numbers of DDoS attacks*. In late January there was a peak in botnet activity and the low point came in mid-February.

Figure 4. Number of DDoS attacks over time in Q1 2015

*DDoS attacks may last for several days. In this graph, the same attack may be counted several times along the timeline, i.e. one time for each day of its duration. This results in a larger total number of DDoS attacks (30,064) than if each uninterrupted attack is counted as one (23,095).

As seen in the chart below, last December saw a dramatic increase in the number of botnet-assisted DDoS attacks. The number of attacks declined steadily through January and February, but then began to rise again in March. The December peak could be linked to the Christmas / Near Year holidays, when the cybercriminals redoubled their efforts to disrupt the operation of websites and services popular with users.

Figure 5. Monthly numbers of DDoS attacks in Q4 2014 and Q1 2015.

In Q1, Thursday became the most active day of the week in terms of numbers of botnet-assisted DDoS attacks, rather than Monday in Q4 2014. Sunday remains the quietest day for cybercriminals.

Figure 6. Numbers of DDoS attacks performed on each day of the week in Q4 2014 and Q1 2015

Types and duration of DDoS attacks

The duration and the scenario of a DDoS attack are among its most important characteristics, as they define the extent of the damage inflicted on the target. Within the analyzed time period, the vast majority of attacks lasted less than 24 hours. In Q4 2014, some attacks lasted for up to two weeks; in Q1 2014, there were no attacks that would last this long.

Attack duration, hours Number of targets in
Q4 2014
Number of targets in Q1 2015 150+ 5 0 100-149 8 3 50-99 299 121 20-49 735 433 10-19 1679 703 5-9 2161 1426 Less than 4 8425 9594

Figure 7. Duration of DDoS attacks in Q4 2014 and Q1 2015

The type of a DDoS attack is defined by the format of junk requests sent to the target web resource. SYN DDoS was the most popular method of performing a DDoS attack in Q1 2015, just like in Q4 2014. TCP DDoS attacks were overtaken by HHTP DDoS attacks in second place.

Figure 8. The most frequently used types of DDoS attacks in Q4 2014 and Q1 2015

C&C servers and botnet types

The C&C servers used by cybercriminals to control botnets may be located in different countries. Their locations are not typically related to the cybercriminals’ physical location(s) or to the geographic distributions of the botnets controlled via these C&C servers. The USA, China and the UK host the largest numbers of C&C servers that were active in Q1 2015.

Figure 9. Numbers of botnet C&C servers by country, Q1 2015

In Q1 2015, just like in Q4 2014, bots designed to infect Linux servers were more active than those targeting Windows devices. At the same time, there was virtually no change in the number of attacks launched using Windows botnets, while the number of attacks from Linux botnets has decreased.

Figure 10. The number of attacks launched from Windows and Linux botnets in Q4 2014 and Q1 2015

Although there are far fewer Linux-based botnets, the number of attacks launched from them is larger than that of the attacks launched from Windows-based botnets; also, the attacks from Linux-based botnets are more powerful. This is because a successful infection of a Linux-based server provides the cybercriminals with vast opportunities to manipulate network protocols. In addition, infected servers typically have faster internet connections than individual computers, so more powerful attacks can be carried out.

Besides, Linux-based botnets have much longer lives than Window-based botnets do. This is because Linux-based botnets are more difficult to detect and deactivate, since Linux servers are much less likely than Windows-based servers and devices to be equipped with dedicated security solutions.

It should be also pointed out that 93.2% DDoS targets in Q1 were attacked by just one family of bots. In 6.2% cases, two families of bots simultaneously participated in an attack, and three or more participated in 0.6% cases. In such cases, either the cybercriminals simultaneously used several different bot families to perform the attack, or the clients used the services of several attackers at once.


The number of botnet-assisted DDoS attacks has declined in Q1 2015 against Q4 2014; so has the number victims of these attacks. At the same time, this type of threat has grown to target more countries. Historically, most attacks target web resources located in the USA and China, as these two countries offer the cheapest prices for web hosting, and many web resources are located there. However, the 10 most frequently attacked targets also include victims from Europe and the APAC region. These statistics demonstrate that botnet-assisted DDoS attacks are relevant for most diverse web resources irrespective of their geographic location. Moreover, this threat is increasingly expanding its boundaries.

The cybercriminals who use botnets to carry out DDoS attacks are willing to persevere: the longest DDoS attack reported in Q1 2015 lasted for about 6 days, and the most frequently attacked web resource survived 21 attacks within the three month period. However, study shows that even a short, one-off attack may render an unprotected web resource inoperable. One such attack may cost the victim up to $444,000, not including the reputational damage associated with the unsatisfied users who failed to receive the service they expected.

Internet security companies make their contribution to combating DDoS attacks and botnets: among other things, they detect new pieces of malware and add signatures for them to the appropriate databases, protect servers from being compromised, protect computers against infections, curb C&C server activities, etc. Nevertheless, DDoS attacks remain a very popular tool with cybercriminals, so companies must take proactive care of their security. A junk traffic filtration service will allow an online resource to remain accessible for legitimate users even during a long and powerful attack.

Links that may be of interest:

The botnet ecosystem
The economics of Botnets
IT Security Risks survey 2014: DDoS
Kaspersky DDoS Protection webpage
Kaspersky DDoS Protection whitepaper


A bot is a malicious program that performs various actions at a cybercriminal’s command.

A family of bots is an aggregate of bots sharing the same source code. In other words, these are different versions of the same bot, even if they are serviced by different C&C servers.

A botnet is an aggregate of devices infected with the same bot that is serviced by the same C&C server. Cybercriminals distribute special malicious programs which turn servers, computers or mobile devices into remotely managed ‘zombies’ (or bots).

A C&C (command and control) server is a server used by cybercriminals to send orders to bots and to receive reports from them. In the case of a DDoS attack, cybercriminals command bots to simultaneously send requests directly to the targeted web resource or via third-party servers, and thus carry out a ‘distributed attack’.

SYN DDoS is an aggregate of DDoS attack scenarios which exploit peculiarities in the implementation of the TCP (Transmission Control Protocol). A TCP connection is established in three steps, which resembles the process of a handshake. The client sends a packet with the SYN flag. The server receives the SYN packet and replies with a packet with the headers SYN and ACK. Then the client sends an ACK packet, and thus validates the connection. In a SYN flood attack, the attacker sends packets with a SYN flag but does not require a response packet with SYN+ACK flags to establish a connection; this causes the targeted server to waste resources on processing these requests and sending response packets.

TCP DDoS is an aggregate of attack scenarios which, just like a SYN flood, exploit peculiarities in the implementation of the TCP protocol, but establish a connection to the targeted server. In a TCP flood-type attack, once the handshake procedure is completed successfully, the attacker side uses the established connection to send a lot of junk data, or send junk data in a very slow fashion. This overloads the attacked server, so it cannot allocate resources to legitimate users.

ICMP DDoS is an aggregate of attack scenarios using the ICMP (Internet Control Message Protocol). This protocol is normally used to send messages about errors or other exceptional situations that occur while transmitting data. In the case of an attack, the attacker sends plenty of ICMP requests to the victim side, forcing it to use its computational resources to process junk requests in place of legitimate requests.

UDP DDoS is an aggregate of attack scenarios that use UDP (User Datagram Protocol), which does not require a connection to be established. The attacker sends plenty of UDP packets to the victim’s side. Each packet requires processing resources from the targeted server and its communication equipment; this overloads the victim’s computational resources.

HTTP DDoS includes all types of DDoS attacks which have web applications as their target. While carrying out an attack, the attacker may send simple GET/POST requests to the main page of the web application as well as non-typical requests, such as requests to search for information in the web application’s database, execute scripts on the web server side, etc. Extra headers or cookie files may be inserted in the request body; this is done to bypass the filters that determine a legitimate user by the presence of cookie files. Besides, the attacker may open the browser on an infected device in order to imitate the activities of a regular website visitor, and thus prevent the security systems on the victim side from detecting bots in the general visitor traffic.

Grabit and the RATs

Malware Alerts - Wed, 05/27/2015 - 22:00

Not so long ago, Kaspersky clients in the United States approached Kaspersky researchers with a request to investigate a new type of malicious software that they were able to recover from their organizations’ servers. The malware calls itself Grabit and is distinctive because of its versatile behavior. Every sample we found was different in size and activity from the others but the internal name and other identifiers were disturbingly similar. The timestamp seems valid and close to the documented infection timeline. Our documentation points to a campaign that started somewhere in late February 2015 and ended in mid-March. As the development phase supposedly ended, malware started spreading from India, the United States and Israel to other countries around the globe.

All of the dozens of samples we managed to collect were programmed in Windows machine 32bit processor, over the Microsoft .NET Framework (Visual Basic/C#). Files were compiled over the course of three days, between March 7th and 9th of 2015. The following chart illustrates how the group or individual created the samples, the size of each sample, the time of the day when each was compiled and the time lapses between each compilation.

Malware compilation timeline

The smallest sample (0.52Mb) and the largest (1.57Mb) were both created on the same day, which could indicate experiments made by the group to test features, packers and “dead code” implementations.

Looking at the chart, it is interesting to see the modus operandi as the threat actor consistently strives to achieve a variety of samples, different code sizes and supposedly more complicated obfuscation.

Along with these different sizes, activities and obfuscation, a serious encryption algorithm was also implemented in each one of them. The proprietary obfuscated string, methods and classes made it rather challenging to analyze. ASLR is also enabled, which might point to an open source RAT or even a commercial framework that packed the malicious software in a well written structure. This type of work is known as a mitigation factor for threat actors to keep their code hidden from analysts’ eyes.

During our research, dynamic analysis showed that the malicious software’s “call home” functionality communicates over obvious channels and does not go the extra mile to hide its activity. In addition, the files themselves were not programmed to make any kind of registry maneuvers that would hide them from Windows Explorer. Taking that into an equation, it seems that the threat actors are sending a “weak knight in a heavy armor” to war. It means that whoever programmed the malware did not write all the code from scratch. A well trained knight would never go to war with a blazing shield and yet a stick for a sword.

Looking into the “call home” traffic, the Keylogger functionality prepares files that act as a container for keyboard interrupts, collecting hostnames, application names, usernames and passwords. However, the interesting part lies here.

The file names contain a very informative string:

HawkEye_Keylogger_Execution_Confirmed_<VICTIM> 3.10.2015 6:08:31 PM

HawkEye is a commercial tool that has been in development for a few years now; it appeared in 2014, as a website called HawkEyeProducts, and made a very famous contribution to the hacker community.

In the website, the product shows great versatility as it contains many types of RATs, features and functionality, such as the traditional HawkEye Logger or other types of remote administration tools like Cyborg Logger, CyberGate, DarkComet, NanoCore and more. It seems to support three types of delivery: FTP, SMTP and Web-Panel.

As seen, the malware uses a number of RATs to control its victims or track their activity. One of the threat actor’s successful implementations contained the well-known DarkComet. This convenient “choose your RAT” functionality plays a very important role in the malware infection, routine and survival on the victim’s machine. The DarkComet samples are more complicated than the traditional HawkEye logger. One instance had a random key generator which sets an initialization vector of the first 4 bytes of the executable file and appends a random 5 byte key that unpacks another PE file, less than 20Kb in size. The PE file then contains another packer with an even more challenging obfuscation technique. The last sample we tested had still more complicated behavior. The code itself had the same obfuscation technique, though traffic was not transferring in clear text. Stolen data was packed and sent encrypted over HTTP random ports. This means that the group is trying to produce other types of malicious samples with different RATs.

Approximately 10,000 stolen files have been collected. Companies based in Thailand and India had the largest percentage of infected machines. By looking at the stolen credentials, it is very clear that employees sent the malware to one another, as stolen host names and internal applications are the same.

The following is the full chart, updated to May 2015:

Malware distribution by country

Demonstrating the effectiveness of their simple Keyloggers, one C2 (on May 15th) maintained thousands of victim account credentials from hundreds of infected systems.

To sum it up, Grabit threat actors did not use any sophisticated evasions or maneuvers in their dynamic activity. It is interesting to see the major differences between the core development of the malware and the actual functionality it uses.

Some malware samples used the same hosting server, and even the same credentials. Could it be that our threat actor was in a hurry?
Our guess is that we are looking at a group and not an individual. Some members of the group are more technical than the others and some are more security oriented and aware of the risks they might expose themselves to.

Back nj square one:

From what we have seen so far, the malware is being delivered as a Microsoft Office Word (.doc) email attachment, containing a malicious macro called AutoOpen. This macro simply opens a socket over TCP and sends an HTTP request to a remote server that was hacked by the group to serve as a malware hub, before downloading the malware. In some cases the malicious macro was password protected, but our threat actor might have forgotten that a .doc file is actually an archive and when that archive is opened in a convenient editor of your choice, the macro strings are shown in clear-text.

The malware is in plain view, modifying commonplace registry entries, such as the startup configurations, and not covering its tracks. Its binaries are not deleted in most cases, and its communication is in clear-text, where the victim can sniff the communication and grab the FTP/SMTP server’s credentials.

Malware derivatives are mainly located in:

C:\Users\ <user> \AppData\Roaming\Microsoft

Phishing extensions: .doc



Icons: .pdf, .doc, .ttf, .xls, .ppt, .msg, .exe

Stealer: .txt, .jpeg, .eml

Additional Executable names:


Malware extensions: .zip or .exe
















IP Addresses:

Does CCTV put the public at risk of cyberattack?

Malware Alerts - Wed, 05/27/2015 - 04:00

The research was originally presented at DefCon 2014. It has been published as part of Kaspersky Lab’s support of Securing Smart Cities – a global not-for-profit initiative that aims to solve the existing and future cybersecurity problems of smart cities through collaboration between companies, governments, media outlets, not-for-profit initiatives and individuals across the world.

Thomas Kinsey from Exigent Systems Inc. contributed to this report.

Late one night, a colleague and I decided it would be a good idea to climb up a public fountain in the middle of a city. Suddenly a disembodied voice from the heavens boomed out: “PLEASE GET DOWN FROM THE FOUNTAIN.” We were shocked, until we noticed a number of cameras – complete with speakers attached – pointing to us from various lamp-posts in the city. This was the first time we’d ever felt so closely monitored so we decided to take a look at how the systems worked.

It is nothing new that police departments and governments have been surveilling citizens for years with the help of security cameras set up throughout various cities. These days most of us accept this as a fair tradeoff that we are willing to make, sacrificing a measure of privacy in the hope that it will keep us safer from criminals and terrorists. However, we also expect that our private data, in this case video feeds of our public life, will be handled responsibly and securely to ensure that this surveillance does not end up doing more harm than good.

In our recent research, we came across many cities that use wireless technology for their security cameras and infrastructure, rather than the hard-wired setups that were common in the past. This change makes things more cost and time effective for the city authorities.

Unfortunately, the problem is that right now wireless technology is not as secure as it could be. As security-conscious people, we instantly saw that handling data in this manner could potentially be vulnerable to a number of attacks, and so we started looking into whether these systems were implemented in a way that handled our data safely, or whether the data could be easily manipulated for malicious intent.

Although wireless technology itself can be vulnerable, there are still many additional improvements which can be implemented to add a sufficient level of security. Ideally, there should be many levels of security in place, so if a hacker clears one hurdle, he must then face a greater challenge at the next. However that was not the case in this instance.


Our research started on the physical level: we traveled to various locations around the city, looking at how the hardware was set up, and finding the first sign that the city really had not put enough thought and effort into properly handing their own systems.

The security system

As the picture shows, the security system was set up in a sloppy way. The units that will be carrying our data have not been masked at all; on some units we could clearly see the name and model of the hardware needed in order to identify the devices and begin the research.

Why it is so important to protect the labeling of the hardware that you use? I will provide an example to help illustrate why this is such a major flaw. When there is a server that needs to be secured, a major factor in preventing it from being exploited is that the server binary is not publicly available. The reason for this is that if a researcher can get his hands on the binary, it can be reverse engineered and studied to find bugs and vulnerabilities. It is rare that a vulnerability can be discovered without being able to look at the code implementing the service. This is why not covering up the device labeling, seemingly a small mistake, actually has a massive effect.

Returning to the camera network: if a hacker was to crack the wireless security of these systems (which only implement your standard WEP or WPA wireless protections), he would at this point only be able to see unknown protocols, headers, and wireless packets with no reference to what system they belong to. In our analysis, we initially had no idea what software was generating these packets, as it is a proprietary system. Without getting our hands on the actual code, it would have been more or less impossible to reverse the protocol they use, which is really the only way to properly examine the network. At this point, our work was cut out for us.

Encryption modules had not been set up and clear text data was being sent through the network#SmartCitySecurity


Having obtained the hardware, we realized, despite the fact that the police department’s setup was weak, the hardware they chose was actually not the problem at all. The mesh nodes were actually a very complex and well-made solution, and there are modules built into it to secure communications beyond the outlying wireless security. It just needed a sufficiently knowledgeable person to implement this technology and ensure it was properly set up. Unfortunately, having inspected many of the packets, we quickly realized that these encryption modules had not been set up and were not being implemented at all. Clear text data was being sent through the network for any observer who could join. There was no encryption to subvert, so we knew that it would just be a matter of recreating our own version of this software in order to manipulate the data traveling across it.

A quick comparison of how the mesh network works to transport video feeds will help give an understanding of what exactly we learned in order to manipulate the system. In a traditional Wi-Fi network, each device is typically connected to a router that serves as a central point. In order to send one piece of data to another part of the network, you would send it to that address, and it would travel via the router to the connected device. This works well in close proximity, but in order to be able to communicate over a long distance, the camera network used a topology and protocol that we will not name in this article.

Traditional topology of a home wireless network. Clients can be any device connected to the Internet

An attacker tells the user he is the router, and tells the router he is the user, thus intercepting traffic to and from the web server

In general, being on any wireless network – a home wireless network, for example – makes it possible for anyone connected to perform regular Man-in-the-Middle attacks by using methods such as ARP poisoning. This essentially enables the user to alter any data sent to and from the router. Because of the nature of the mesh software, however, this standard method would not be very valuable if attempted in the vanilla form. Basically, each node in the mesh network can only have a direct line of sight to a few of the many nodes that exist in the network. In order to send a packet to a device that is not within range, the packet must travel from the origin point, through several other nodes, and eventually reach the destination node. The hardware vendor’s system implements a pathfinding algorithm in order to efficiently transport data and to be able to find the most reliable route to destination. The algorithm is very similar to that which is commonly used in video games to determine the path a character will take to get to his destination, avoiding obstructions.

The Pathfinding algorithm find routes for characters to travel based on variables such as difficulty of terrain

The pathfinding algorithm used for the cameras relies on a number of variables, but most important is the signal strength between one node and the next and the number of nodes it travels through in order to reach to the destination.

Packet originates from Node A and travels through B to C and finally to Destination (Simulated police station). Meanwhile, all other nodes travel through a completely different path and thus cannot be intercepted by listening in at a single location

With that set up, a classic man-in-the-middle scenario is possible on the video data #SmartCitySecurity


This is exactly what we took advantage of. By lying to the other nodes, telling them that we had a direct line of site to the simulated police station and would behave as a node by forwarding the packets along, the cameras set up in proximity actually began forwarding their packets directly to us because of the A* implementation. With that set up, a classic Man-in-the-Middle scenario is possible, but now on a very wide range of video feeds. A good analogy here with the RTS game above would be like building a bridge across the lake, so all characters would follow that path, rather than traveling around the shore of the lake.

So what are the implications?

We are not in the business of hacking, we simply wanted to create a proof of concept to demonstrate that this kind of attack is possible, to expose that a vulnerability exists, and ultimately to alert the authorities to a weakness that needs to be fixed. Because of that, our research was done on our own private lab setup, replicating the systems the police had in place, and did not actually harm their network in any way.

As frequently seen in Hollywood movies, if hackers with criminal intent were to take advantage of the problems which we have shown, many dangerous scenarios could unfold. Being able to launch Man-in-the-Middle attacks on the video data is a short step away from replacing real video feeds with pre-recorded footage. In this scenario a cybercriminal gang could lead the police department to believe that a crime is taking place in one area of the city, and wait for the department to dispatch officers there. This would leave a window of opportunity for crime in another region of the city where there are no officers available. This is just one way in which someone could maliciously use these systems to actually assist them in committing crimes much more efficiently than if they were not in place at all. Unfortunately, this is not just a Hollywood scenario. We successfully replicated this functionality in our lab.

It is a short step away from replacing real video feeds with pre-recorded footage #SmartCitySecurity


We trust the proper authorities to access our private data, but when those authorities do not spend the time and resources necessary to responsibly handle this data we are better off without this technology at all. Thankfully, after we alerted them to the problem, the cities involved expressed their concern and have since acted to increase security.

The unfortunate truth here is that everything is connected these days, and as new technology is being implemented across the board to modernize older technology, it will inevitably introduce new vulnerabilities. Aside from just the surveillance systems which we analyzed today, there are many more systems which are, and will be, vulnerable to various attacks. The race is on for “the good guys” to test security, before “the bad guys” can use it for malicious intent. Our task is to continue in this effort, to keep the world a safer place.


The following considerations are necessary to bring a mesh network to a reasonable level of security:

  • Although still potentially crack-able, WPA with strong password is a minimum requirement to stop the system from being an easy target.
  • Hidden SSID and MAC filtering will also weed out unskilled hackers.
  • Make sure all labels on all equipment are concealed and enclosed to deter attackers who do not have insider information.
  • Securing video data using Public-key cryptography will make it more or less impossible to manipulate video data.


Subscribe to RIT Information Security aggregator