Feed aggregator

Five Year Old Phishing Campaign Unveiled

Threatpost for B2B - Mon, 07/14/2014 - 16:04
Active for about five years, a campaign in which attackers have pilfered victims’ credentials from Google, Yahoo, Facebook, Dropbox and Skype, was recently revealed.

Outside Panel Finds Over-Reliance on NSA Advice Led to Dual EC Problems

Threatpost for B2B - Mon, 07/14/2014 - 13:47
A group of outside experts found that the process that led to the inclusion of the weakened Dual EC_DRBG random number generator in a NIST standard was flawed and there were several failures along the way that led to its approval. The committee also recommended that the National Institute of Standards and Technology increase the number of […]

Oracle Clarifies XP Support Ahead of Quarterly Patches

Threatpost for B2B - Mon, 07/14/2014 - 12:45
Oracle is expected to release 113 patches across its product lines as part of its quarterly Critical Patch Updates.

First Version of LibreSSL Debuts

Threatpost for B2B - Mon, 07/14/2014 - 11:23
An early version of LibreSSL, a fork of OpenSSL developed by the OpenBSD Foundation, was released for a number of platforms beyond OpenBSD.

LastPass Fixes a Pair of Security Flaws

Threatpost for B2B - Mon, 07/14/2014 - 09:58
LastPass, the popular password manager for most of the top Web browsers, has fixed a couple of vulnerabilities that could have allowed an attacker to target users and generate his own one-time passwords for the victim’s account. The company said that its security team hasn’t seen any active attacks exploiting these vulnerabilities and doesn’t think that […]

Shylock/Caphaw malware Trojan: the overview

Secure List feed for B2B - Mon, 07/14/2014 - 06:00

Recently Kaspersky Lab has contributed to an alliance of law enforcement and industry organizations, to undertake measures against the internet domains and servers that form the core of an advanced cybercriminal infrastructure that uses the Shylock Trojan to attack online banking systems around the globe.

Shylock is a banking Trojan that was first discovered in 2011. It utilizes man-in-the-browser attacks designed to pilfer banking login credentials from the PCs of clients of a predetermined list of target organizations. Most of these organizations are banks, located in different countries.

Kaspersky Lab products detect the Shylock malware as Backdoor.Win32.Caphaw and Trojan-Spy.Win32.Shylock.

We detected this malware generically from the end of August 2011, as Backdoor.Win32.Bifrose.fly. Specific detection of this separate family was added in February 2012. Since then we have observed a very few detections – approximately 24,000 attempts to infect PCs protected by Kaspersky Lab products worldwide.

These are very modest numbers, especially in comparison with other infamous banking malware such as ZeuS, SpyEye, Carberp which have generated (and, in the case of some of them, such as ZeuS , still generate) tens or hundreds of thousands of detections. Of course, these numbers don't tell us everything about how widespread or effective Shylock is, because Kaspersky Lab "sees" only a part of the total number of PC users - only those who use our products.

Low popularity doesn't make Shylock less dangerous though. The set of malicious techniques it utilizes is no less dangerous than that used by other similar malware. It is able to inject its body in multiple running processes, has tools to avoid detection by anti-malware software, uses several plugins which add additional malicious functions aimed at bypassing anti-malware software, collects passwords for ftp-servers, spreads itself via messengers and servers, provides remote access to the infected machine, video grabbing and of course web injection.

This last function is used to steal online banking credentials by injecting fake data entry fields into the web page loaded in the victim's browser.

During the entire period we've seen two relatively big peaks in detection rate for this malware.

The first one was in November 2012 and the second one was in December 2013.

The geography of the November 2012 peak was as follows:

United Kingdom Italy Poland Russian Federation Mexico Thailand Iran Turkey India Spain

The table above shows the top 10 countries wheremost attacks using the Shylock malware were registered. A little more than a year later, in December 2013, the picture had changed dramatically.

Brazil Russian federation Vietnam Italy Ukraine India United Kingdom Belarus Turkey Taiwan

As these tables show, the criminals behind this malware definitely stopped paying so much attention to the developed e-money markets of the UK, Italy and Poland in favor of the actively developing markets of Brazil, Russia and Vietnam. It's slso interesting that both peaks happened in the late autumn to early winter period, a traditional high retail season in many countries around the world.

According to Europol data, this malware has infected more than 30,000  PCs worldwide. This is a big enough scale to cause huge financial damage, so the disruption of the Shylock backbone infrastructure is very good news.

And even better news is that the recent operation, coordinated by the UK's National Crime Agency (NCA), brought together partners from the law enforcement and the private sector, including – besides Kaspersky Lab – Europol, the FBI, BAE Systems Applied Intelligence, Dell SecureWorks and the UK's GCHQ (Government Communications Headquarters), to jointly combat the threat. We at Kaspersky Lab were glad to add our modest contribution to this operation. Global action brings positive results – an example being the operation targeting the Shylock malware.

Microsoft Updates July 2014, etc

Secure List feed for B2B - Thu, 07/10/2014 - 14:21

Looking past the 23 Critical Internet Explorer remote code execution vulnerabilities being patched this month by MS14-037 that require immediate attention, most interesting is CVE-2014-2783, the Internet Explorer "Extended Validation (EV) Certificate Security Feature Bypass Vulnerability". The vulnerability itself, reported by Eric Lawrence of "Fiddler" fame, is applicable in a "corner case" situation and can lead to man-in-the-middle (MiTM) attacks.

Let's narrow down the complexity of the issue for everyone's sake. What is an "EV" certificate? Well, it's a special certificate that an organization or individual would pay extra money to a certificate authority like Verisign to create and then use to "secure" their communications. Sites using them are usually handled in a special manner by the major web browsers. The address bar turns green, a special rectangle is set around the address, or some other visual image assures the user that the connection is with the right web site and encrypted. Here is an example of a web browser presenting the green bar EV visualization, please click on the image for a closeup:

The related flaw being patched this month is a tricky one. Internet Explorer versions 7 through 11 all allow for wildcard subdomains with EV Certificates, which should never be allowed. Neither Certificate Authorities nor web browsers should allow for such a flaw, but their compliance is questionable. In the past, CAs like Diginotar, Comodo, TrustwaveTurkTrust, and currently the National Informatics Centre in India, all maintained incidents of major improprieties at the CA level.

So, coupled with this flaw in IE 7,8,9,10 and 11, attackers (whether or not they are state sponsored or more traditional cybercrime organizations) could set up sites with wildcard EV certs to spoof major web properties like at google, twitter, facebook and elsewhere, and steal data from sensitive communications there. The Certificate Authority infrastructure trust model continues to show major cracks as a flawed trust model, and this "corner case" simply enables more situations like it. Potential solutions like Convergence have not been seriously pushed. At the same time, cheers to Microsoft for patching and reporting on the two current issues.

Unfortunately, these sorts of issues find their way into software products all the time. Partly, they are very tricky to understand by QA teams and developers certainly need to narrow the scope of their projects. You can't automate this sort of test, and even if it is found, it is not assigned a severity of 5 or "showstopper" because it doesn't immediately disrupt operation of the product. So they can sit unaddressed in a product for four or five versions or more even if privately known. Only an exposure because of a security researcher's work or a major public incident might push it to the front of the priority list.

All of this discussion of corner cases lays down groundwork for further discussion of the "Internet of Things". Whenever there are cross-disciplinary approaches (like heavy mathematics and communications, or internal network computing and automobiles) to solutions, there is an elevated risk of incident because of practical and theoretical issues. As the industry progresses, and as the startups generating IoT solution code are dealing with their own corner case issues, and as adoption and acquisitions move forward, IoT technologies will demonstrate on a larger scale that we are not learning from past mistakes.

New gTLDs, same attacks

Secure List feed for B2B - Thu, 07/10/2014 - 07:11

Cybercriminals around the world have already started to point their guns and attacks at the new gTLDs, the 'generic Top Level Domains' approved by ICANN and offered by registrars to people interested in buying a new domain name. Recently we found malicious activities including malware and phishing pages registered in the top level domains .club, .berlin, .blue, .computer, .camera, .futbol, .link, .pink, .report, .travel, .vacations and .xyz.

The new gTDLS were recently approved by ICANN and registrars are already offering them as a solution to those bored with the traditional .com or .org and who want more possibilities when registering internet domains. You should be prepared to see websites like"funny.dance"or "joe.dentist"or even "my.creditcard".

According nTLDStats.com, more than 1.4 million domains have already been registered using these new gTLDs:

There are now more than 322 new top level domains granted by ICANN, among these the most popular are .xyz (designated at Feb. 2014), .berlin and .club (both designated in January 2014):

Brazilian phishers and domains squatters are particularly interested in these new gTLDs, already having registered several new domains using names of local brands such as banks, online stores, and credit card companies. For example:

  • cielo-seucartaobateumbolao.xyz
  • megasaldao-americanas.xyz
  • lojadoricardoeletro.xyz
  • hsbc.club
  • santander.club
  • bradesco.club
  • ricardoeletro.club
  • ricardoeletro.computer
  • ricardoeletro.camera

These domains were registered with the intention of being used for phishing campaigns, so it comes as no surprise that the data registered in the respective "whois" databases is completely fake:

Malware is also involved. We're aware of bad guys hosting their exploit kits in such domains – the Nuclear Exploit Pack is currently using the .blue, .pink, .futbol, and .report gTLDs, as pointed out by security researcher Frank Denis.

But Brazilian bad guys aren't the only ones interested in the new gTLDs as English-speakers have showcased similar interests by already starting a fraudulent domain that sells coins for online games such as Fifa '14 and others.

Other phishers already started their phishing campaigns, even using older TLDs such as .travel (started in 2005). As you can see in the following abused domain that hosts a phishing page aimed at a Brazilian bank:

If you're a regular user, be aware of such links appearing in email messages or in social networks – they can be just as dangerous as others links. If you're a company, it's a great idea to start a brand monitoring process to insure that your company name or brand aren't being used in campaigns involving these new TLDs.

Kaspersky users are protected against all of these attacks.

Versatile DDoS Trojan for Linux

Secure List feed for B2B - Thu, 07/10/2014 - 04:40

In February 2014, an article was published on a popular Russian IT website under a curious title - Studying the BillGates Linux Botnet. It described a Trojan with sufficiently versatile DDoS functionality. The capability that we found the most interesting was the Trojan's ability to conduct DNS Amplification-type attacks. In addition, it followed from the article that the Trojan had a sophisticated modular structure, something we had not seen in the world of Linux malware before.

The article also provided a link for downloading all of the Trojan's files (taken directly from an infected machine) - which is what we did.

The archive that we downloaded contained the following files, which, according to the author of the article, were all modules of the same Trojan:

  • atddd;
  • cupsdd;
  • cupsddh;
  • ksapdd;
  • kysapdd;
  • skysapdd;
  • xfsdxd.

The files cupsdd and cupsddh are detected by Kaspersky Lab products as Backdoor.Linux.Ganiw.a; atddd and the remaining files are detected as Backdoor.Linux.Mayday.f.

The archive with the files also contained a configuration file for cron - the Linux task scheduler. In this case, the utility is used by the Trojan as a means of getting a foothold in the system. The Trojan uses cron to perform the following tasks:

  1. Once a minute - terminate the processes of all applications that can interfere with its operation: .IptabLes, nfsd4, profild.key, nfsd, DDosl, lengchao32, b26, codelove, node24
  2. Approximately once in ninety minutes - terminate all of its processes: kysapd, atdd, skysapd, xfsdx, ksapd
  3. Approximately once in two hours - download all of its components to the /etc folder from http://www.dgnfd564sdf.com:8080/[module_name] (module_name = name of the Trojan's module, e.g., cupsdd), after deleting these files from the /etc folder
  4. Once in ninety minutes - relaunch all of its modules
  5. Every minute - purge system logs and bash command history and execute chmod 7777 [module_name]

During subsequent analysis of the files, we did not find any code responsible for saving the config file for cron. Most likely, the file was manually downloaded to the victim machine by a cybercriminal after gaining remote access to the system.

Backdoor.Linux.Mayday.f (atddd)

The file atddd is a backdoor designed to conduct various types of DDoS attacks against the servers specified. As mentioned above, Kaspersky Lab products detect it as Backdoor.Linux.Mayday.f. The files kysapdd, skysapdd, xfsdxd, ksapdd are almost exact copies of atddd - with one exception, which is discussed later in the text.

The backdoor starts its operation by calling the function daemon(1, 0), continuing to run in the background and redirecting standard input, output and errors to /dev/null

Next, atddd collects relevant information about the system, including:

  1. system version (by calling uname())
  2. number of CPU cores and their clock rates (taken from /proc/cpuinfo)
  3. CPU load (taken from /proc/stat)
  4. network load (data for interfaces with the "eth" prefix taken from /proc/net/dev)

The information listed above is stored in the g_statBase structure.

After this, the backdoor decrypts strings defining the C&C server's IP address and port number. The encryption algorithm used is very simple: an encrypted string is taken character-by-character, with 1 added to the ASCII code of a character if its number is odd and subtracted from it if the character's number is even. As a result, the string "3/3-2/4-269-85" yields the IP-адрес "", while "2/:82" stands for port number "10991".

After this, atddd reads configuration file fwke.cfg, which is located in the same folder with the malicious program. Information from the config file is saved in the g_fakeCfg structure. If the file does not exist, the backdoor attempts to create it and store the following information in it:

1st line: 0        //flag, if 1 then begin attack, if 0 then terminate attack

2nd line:        //range of outgoing IP addresses

3rd line: 10000:60000        //outgoing port range for an attack

4th line: an empty line        //domain name in the case of DNS flood (see below)

This information is subsequently sent to the C&C server and can be updated with a command from the C&C.

Next, the backdoor creates a new thread, CThreadTaskManager::ProcessMain(), in which commands to begin an attack and terminate an attack are put into the execution queue. After this, a new thread is created - CThreadHostStatus::ProcessMain(). In this thread, data on CPU and network load is updated every second and can subsequently be sent to the C&C server if requested.

After this, 20 threads are created, which read information from the task queue and, depending on the information read, launch an attack or terminate it. However, some of the threads may not be used in an attack if the relevant C&C command has a parameter (the number of threads to be used).

Then the malware enters an endless loop of processing messages from the C&C. After a connection with the C&C is established, information about system version and CPU clock rate, as well as data from the g_fakeCfg structure, is sent to the C&C every 30 seconds.

In response, the server should send 4 bytes, the first of which is the serial number of a command - from 1 to 4.

Next, if the command has parameters, the C&C sends another 4 bytes defining the amount of data that will be sent (i.e., the parameters). Then the parameters themselves are sent; their size should match the number from the previous C&C response.

About each command in greater detail:

  • 0x01. Command to launch an attack. Parameters define the attack's type and the number of threads to be used. The attack type is defined by a byte which can take values from 0x80 to 0x84. This means that 5 attack types are possible:
    • 0x80 - TCP flood. The destination port number is sent by the C&C in its response as a parameter. The source port range is defined in fwke.cfg. Each new request is sent from a new port within the range defined, in the ascending order of port numbers. The destination IP address is also defined in parameters.
    • 0x81 - UDP flood. The same as 0x80, but UDP is used as the transport layer protocol.
    • 0x82 - ICMP flood. Same as above, but via ICMP.
    • 0x83, 0x84 - two DNS flood attacks. The only difference is the domain name sent in the DNS request. In the former case, the name is generated randomly, in the second, it is defined in a parameter (the fourth line in fwke.cfg). Essentially, both attacks are similar to 0x81, except that port 53 (the default port for the DNS service) is used as destination port.
  • 0x02. Command to terminate an attack. The value in the first line of fwke.cfg is changed to 0 and the attack is terminated.
  • 0x03. Command to update the file fwke.cfg. The response also includes a structure similar to g_fakeCfg, data from which is used to create the new fwke.cfg file.
  • 0x04. Command to send the current command's execution status to the C&C server.

In addition to the above, the backdoor includes several empty methods (without any code), which have curious names: CThreadAttack::EmptyConnectionAtk, CThreadAttack::FakeUserAtk, CThreadAttack::HttpAtk. Apparently, the malware writer had plans to extend the malicious program's functionality, and this is a test version rather than a final version. The file cupsdd, which is discussed below, provides a confirmation of this.

The files kysapdd, skysapdd, xfsdxd, ksapdd are almost identical copies of atddd, with the exception that they contain different C&C server addresses:,, and, respectively. The names of their configuration files are also different: fsfe.cfg, btgw.cfg, fake.cfg, xcke.cfg, respectively.

This means that, contrary to our expectations, the files atddd, kysapdd, skysapdd, xfsdxd, ksapdd are not modules of a single piece of malware but rather different copies of the same Trojan, each connecting to its own C&C server. However, this is not the most curious part of it by far.

Backdoor.Linux.Ganiw.a (cupsdd)

Like the files described above, this file is a backdoor designed to carry out various types of DDoS attacks. However, cupsdd is significantly more feature-rich and sophisticated than its 'colleagues', although in places its code is very similar to that found in atddd.

The backdoor starts its operation by initializing the variables it needs from the string "" (separator - ":"), which it first decrypts using the RSA algorithm. The string contains the following variables:

g_strConnTgt= - C&C server's IP address

g_iGatsPort=30000 - C&C server's port

g_iGatsIsFx=1 and g_iIsService=1 - flags used later

g_strBillTail=h - postfix for the name of the file that will be dropped (see below)

g_strCryptStart=578856, g_strDStart=579372, g_strNStart=579888 - pointers to RSA data (encrypted string and key)

Next, the malware drops and executes a file, which is located at offset 0xb1728 from the beginning of the original file and is 335872 bytes in size, provided that the file is not already running. The malware checks whether the file is running by trying to bind a socket to If the attempt is successful, it means that the file is not running, and it needs to be dropped and executed.

If the file is already running, its process, whose PID can be found in the file /tmp/bill.lock, is terminated (kill(pid, 9)). Then the file is dropped anyway, replacing the existing copy.

The name of the file that is dropped is generated from the name of the current file that is running + postfix from the variable g_strBillTail. In our case, the file was named cupsddh and was located in the same folder with the dropper.

After this, the current process forks and the child process calls the function system("/path/to/cupsddh"), which executes the file dropped.

Next, the function daemon(1, 0) is called, for the same purpose as in the case of the sample described above (atddd).

After this, the malware handles the situation if cupsdd was executed earlier and is currently active. For this purpose, it checks whether the file /tmp/gates.lock exists. If it does exist, the current process is terminated (exit(0)). If not, the file (/tmp/gates.lock) is created and the PID of the current process is written to it.

Then, if flag g_iIsService == 1, the backdoor sets itself to run at system startup by creating the following script named DbSecuritySpt in /etc/init.d/:


The malware also creates symbolic links to the script in /etc/rc[1-5].1/S97DbSecuritySpt

Next, the malware reads the configuration file conf.n (if it exists) from the same folder as the one in which cupsdd is located. The first 4 bytes of the file define the size of the data which follows. All the data is stored in the structure g_cnfgDoing.

Then the malware reads the file containing commands - cmd.n. The format is the same as in conf.n. The data is stored in the structure g_cmdDoing.

After this, the malware obtains all the necessary information about the system, including:

  • The operating system's name and kernel version (e.g., Linux 3.11.0-15-generic), by calling uname()
  • CPU clock rate, taken from /proc/cpuinfo
  • Number of CPU cores, taken from /proc/cpuinfo, and CPU load, taken from /proc/stat
  • Network load, taken from /proc/net/dev
  • Hard drive size in megabytes, taken from /proc/meminfo
  • Information about network interfaces, taken from /proc/net/dev

All the data is stored in the structure g_statBase.

Next, a new stream, CThreadTaskGates::ProcessMain, is created, in which the following commands are processed:

  • 0x03. DoConfigCommand(). Update the configuration file conf.n.
  • 0x05. DoUpdateCommand(). Start a new thread, CThreadUpdate::ProcessMain, in which update one of its components. The command accepts a number from 1 to 3 as a parameter. Each of the numbers is associated with one of the following strings:

    1 - "Alib" - the file /usr/lib/libamplify.so
    2 - "Bill" - the dropped module (cupsddh)
    3 - "Gates" - the dropper (cupsdd)

Depending on the parameter, one of the malicious program's components is updated. An update is launched by sending 6 bytes containing the string "EF76#^" to the C&C server, followed by one of the strings described above (depending on the parameter).

The C&C responds by sending 4 bytes containing the length (in bytes) of the file that will be transferred next. Then the C&C transfers the file itself in 1024-byte packets.

First, the file is saved in the /tmp folder under a random name consisting of digits. Then, depending on the file that was received, the existing file cupsdd (or cupsddh) is replaced or the file is copied to /usr/lib/libamplify.so

Next, the temporary file is deleted from /tmp, and the chmod command is used to set 755 permissions for the resulting file. After this, in the case of updating cupsddh, the active process is terminated and the new file is launched. In the case of updating cupsdd, the final stage (starting from copying a file from /tmp) is carried out by cupsddh, to which the relevant command is sent.

  • 0x07. DoCommandCommand(). Write a new command to cmd.n.
  • 0x02. StopUpdate(). Close the current connection, which was established in order to update modules.

Next, the backdoor starts several threads, in which it simultaneously performs several additional operations:

  • CThreadClientStatus updates the data on CPU and network load in the g_statBase structure every second.
  • CThreadRecycle removes completed tasks from the queue.
  • CThreadConnSender reads commands from the queue and passes them to the cupsddh module via a TCP connection with on port 10808. In response it receives the status of their execution.
  • CThreadMonBill checks whether the module cupsddh is running once every minute. If not, it drops and executes it again.
  • CThreadLoopCmd reads commands from g_cmdDoing (the file cmd.n) and executes them using the call system(cmd).

Next, the main thread enters the loop of receiving and processing commands from the C&C server. There are two possibilities in this case, depending on the g_iGatsIsFx flag:

  1. If the flag is set (==1), the malware simply uses the new thread to send information about the system and the current configuration from g_cnfgDoing to the C&C and waits to receive commands in response, like the sample (atddd) described above;
  2. If the flag is not set, then the communication session is initiated by the C&C. In other words, the malware waits for the C&C to connect and begins to transfer the data mentioned above only when a connection has been established.

Commands received from the C&C are divided into two queues: either for execution in the current module (in the thread CThreadTaskGates described above) or for passing to the cupsddh module (thread CThreadConnSender).

Backdoor.Linux.Ganiw.a (cupsddh)

The file is packed with UPX. After being unpacked, it calls daemon(1,0). It creates the file /tmp/bill.lock, in which it stores the PID of the current process. cupsddh stores system data in the structure g_statBase, which is identical to that used by cupsdd.

Next, it populates the structure g_provinceDns with the IP addresses of DNS servers converted to binary data in network byte order using the function inet_addr(), taking data from the string array g_sProvinceDns (offset in unpacked file: 0x8f44с, size 4608 bytes).

cupsddh executes command "insmod /usr/lib/xpacket.ko" in an attempt to load the kernel module into the kernel. However, the file is not present on 'clean' systems, and the malware does not make any attempt to download it or obtain it in any other way.

Next, data from the file /usr/libamplify.so (as it turns out, this is not a library but one more config file) is loaded into the structure g_AmpResource. The file has the following format: 1st dword is the number of dwords that follow. Apparently, it contains the list of IP addresses for DNS servers that are currently relevant, i.e., those suitable for DNS Amplification type DDoS attacks.

After this, the module creates two threads: CThreadTask and CThreadRecycle. The former executes commands from a queue comprising commands which came from the cupsdd module. The latter removes commands that have been executed. Next, the main thread binds a socket to and enters an endless loop, receiving commands from the cupsdd module and putting the commands received into the above queue.

The following commands are possible:

  • 0x01. Start an attack according to the parameters received. See a more detailed description below.
  • 0x02. Terminate the current attack, setting the relevant flag.
  • 0x03. Update the current configuration in the g_cnfgDoing structure, which is used during an attack. Also, update the current local MAC address, as well as the MAC and IP address of the current gateway in the structure g_statBase.
  • 0x05. The final stage of updating the cupsdd module (described above).

Two main attack modes are possible: normal mode and kernel mode.

Kernel mode

This mode uses pktgen, a kernel-level packet generator built into Linux. Its advantage to the attacker is that traffic is generated with the greatest speed possible for the given network interface. In addition, the packets generated in this way cannot be detected using ordinary sniffers, e.g., the standard tcpdump, since packets are generated at kernel level.

The packet generator is controlled using a set of scripts/configs in the /proc/net/pktgen folder, but the module pktgen must first be loaded into the kernel by calling the command "modprobe pktgen". However, I did not find any such calls. Apparently, the call "insmod /usr/lib/xpacket.ko" is used instead, although, as mentioned above, the file is absent from the system by default. As a result, kernel mode is not operational in this version of the malware.

Nevertheless, the malware attempts to write several files to the /proc/net/pktgen folder, namely:

  1. the file /proc/net/pktgen/kpktgend_%d for each CPU core, where %d is the core number, beginning from 0. The file's contents is as follows:

    add_device eth%d
    max_before_softirq 10000

  2. the file /proc/net/pktgen/eth%d for each CPU core, where %d is the core number, beginning from 0. The file's contents is as follows:

    count 0
    clone_skb 0
    delay 0
    min_pkt_size %d
    max_pkt_size %d
    src_min %s
    src_max %s
    udp_src_min %d
    udp_src_max %d
    dst %s
    udp_dst_min %d
    udp_dst_max %d
    dst_mac %02x:%02x:%02x:%02x:%02x:%02x        //MAC address of the gateway from g_statBase
    is_multi %d
    multi_dst %s        //if there are several addresses to be used in an attack (i.e., if the value in the previous line is not equal to 0), they are set in these lines, the number of which matches the previous parameter
    pkt_type %d
    dns_domain %s
    syn_flag %d
    is_dns_random %d
    dns_type %d
    is_edns %d
    edns_len %d
    is_edns_sec %d

    The values of most pktgen parameters are passed from cupsdd via command parameters.

  3. the file /proc/net/pktgen/pgctrl, which contains the string "start".
Normal attack mode

As in the case of atddd, normal attack mode uses raw sockets.

The following attack types are possible in this mode:

  • CAttackSyn - TCP-SYN flood.
  • CAttackUdp - UDP flood (as in the case of atddd)
  • CAttackDns - DNS flood (as in the case of atddd)
  • CAttackIcmp - ICMP flood (as in the case of atddd)
  • CAttackCc - HTTP flood.
  • CAttackAmp - DNS Amplification.

The last attack type on the list above is different in that packets are sent to vulnerable DNS servers, with the attack target specified as the sender's IP address. As a result, the cybercriminal sends a small packet with a DNS request and the DNS server responds to the attack target with a significantly larger packet. The list of vulnerable DNS servers is stored in the file libamplify.so, which is written to disk following the relevant command from the C&C.

Post Scriptum. BillGates v1.5

This version of the Trojan appeared a little later and is probably currently the latest. Essentially, this is the same cupsdd, only a little 'shaped up'. Overall, there is more logic in the code, plus there are a couple of new functions.

The most significant changes were made to the Gates module, i.e., the file cupsdd. Now it has three operating modes. The choice of mode is based on the folder from which the file is launched. Specifically, if it is launched from /usr/bin/pojie, then monitoring mode is enabled, otherwise the module operates in installation and updating mode, which is later superseded by the mode in which it controls the Bill module.

  1. Installation and updating mode.

    First, the module terminates its process working in monitoring mode, if it exists. Its PID is kept in the file /tmp/moni.lock.
    Next, it reinstalls and re-launches the Bill module.
    Next, if a process working in the 'controlling the Bill module' mode exists, that process is terminated. Its PID is kept in the file /tmp/gates.lock.
    If the flag g_iIsService is set (it is defined in the same way as in the previous version), the module sets itself to run at system startup in the same way as before (in the previous version).
    Next, the module writes its path to the file /tmp/notify.file and then copies itself to the file /usr/bin/pojie. After this, it launches its copy, which is, obviously, set to run in monitoring mode, and then changes its own operating mode to controlling the Bill module.

  2. Monitoring mode.

    Writes the PID of the current process to the file /tmp/moni.lock. Next, it starts two threads - one to monitor the Bill module and the other to monitor the Gates module operating in controlling Bill mode. If one of these processes is currently not running, the relevant file is created and launched again.

  3. Controlling the Bill module mode.

    The actions of the Gates module are exactly the same as they were in the previous version of the Trojan (after installing the Bill module and initializing the relevant variables and structures of the Trojan).

To summarize, in the new version of the Trojan its authors have added a little 'robustness' without making any significant functionality changes.

It is also worth noting that the hard-coded IP address of the C&C server has remained the same ( in this version, but the port number has changed - it is now 36008 instead of 30000 in the previous version.

Cloud Services: Holes in Corporate Network Security

Secure List feed for B2B - Wed, 07/09/2014 - 07:00

The most popular uses of cloud services include: storing image scans of passports and other personal documents; synchronization of password, contact list, and email/message databases; creating sites; storing versions of source codes, etc. When cloud-based data storage service Dropbox announced a patched vulnerability in its link generator, it once again sparked online discussions about how important it is to encrypt confidential data before uploading it to an online storage, even a private one. Well, File encryption (FLE) does indeed protect confidential information stored in the cloud, even if there are vulnerabilities in controlling access to user documents with certain cloud storage services.

It's tempting to think that you can secure yourself against all possible risks by encrypting your data before you upload it to a cloud storage service, or by foregoing cloud services altogether. But is that really true? As it turns out, no, it isn't.

The Internet is full of recommendations on how to "effectively use cloud-based storage services" including advice on how to remotely control a PC, monitor your computer while you are away, manage your torrent downloads, and many other things. In other words, users create all types of loopholes all by themselves. These loopholes can then be easily exploited by a Trojan, a worm, not to mention a cybercriminal, especially in targeted attacks.

So we asked ourselves: how likely is it that a corporate network can be infected via a cloud service?

At the Black Hat 2013 conference, Jacob Williams, Chief Scientist at CSRgroup Computer Security Consultants, gave a presentation on using Dropbox to penetrate a corporate network. While conducting a trial penetration test (pen test), Jacob used the Dropbox thin client installed on a laptop located outside of a corporate network to spread malware to devices within that network.

Jacob first used phishing to infect an employee's computer, then embedded malicious scripts into documents stored in the laptop's cloud-hosted folder. Dropbox automatically updated (synchronized) the infected documents on all the devices attached to the user's account. Dropbox is not unique in this respect: all applications providing access to popular cloud file services have an automatic synchronization feature, including Onedrive (aka Skydrive), Google Disk, Yandex Disk, etc.

When the user opened the infected document on a workstation located within the corporate network, the malicious scripts embedded in the document installed the backdoor DropSmack on that workstation - it was specifically crafted by Jacob for this pen test. As its name suggests, DropSmack's main feature is that it uses the Dropbox cloud file storage service as a channel to manage the backdoor and leak corporate documents through the corporate firewall.

Flow chart of Jacob Williams's experiment

In the pen test, Jacob used a stunningly simple method to penetrate the corporate network - it is an obvious loophole!

We also decided to check if cybercriminals are using Dropbox, OneDrive, Yandex Disk or Google Disk to spread malware for real. We collected information from KSN about instances of malware detected in cloud-based folders belonging to Kaspersky Lab product users, and found out infections like these were detected for very few users: in May this year, only 8,700 people encountered an infection in their cloud-based folder. Among Kaspersky Lab's home product users, such instances account for only 0.42% of all malware detection cases, and 0.24% for corporate product users.

We should point out one important detail: if a piece of malware is uploaded from one device, all clients connected to the infected account will download it to their devices, and they will do so via HTTPS. Even if a security solution detects the malware in the synchronization folder and deletes it, the cloud client will keep downloading it from the cloud in an endless loop.

According to the data we collected, some 30% of malware detected in cloud folders on home computers had penetrated to these computers via synchronization mechanisms. For corporate users this number reaches 50%. Thus, the infection mechanism demonstrated by Jacob Williams in his demonstration malware, does cause infections in real life. Fortunately, we have not (yet) detected targeted attacks launched using cloud-based data storage services.

If we look into the malware we detected in the cloud folders on users' computers, files for Win32, MSIL, VBS, PHP, JS, Excel, Word and Java dominate. It should be noted that there is a small difference between corporate and home users: for corporate users, infected MS Office files occur more often, while home users also face unique threats on their lists in the form of malicious Android applications.

TOP 10 verdicts:


Consumer Corporate 1 Email-Worm.Win32.Runouce.b Email-Worm.Win32.Brontok.dam.a 2 Email-Worm.Win32.Brontok.q Virus.Win32.Sality.gen 3 not-a-virus:AdWare.Win32.RivalGame.kr Virus.Win32.Tenga.a 4 Virus.Win32.Nimnul.a Trojan-Dropper.VBS.Agent.bp 5 Trojan-Clicker.HTML.IFrame.aga Trojan.Win32.Agent.ada 6 Exploit.Win32.CVE-2010-2568.gen Trojan.Win32.MicroFake.ba 7 Virus.Win32.Sality.gen Exploit.Win32.CVE-2010-2568.gen 8 Worm.Win32.AutoRun.dtbv Worm.Win32.AutoRun.dtbv 9 Trojan-Dropper.VBS.Agent.bp Trojan.Win32.Qhost.afes 10 Trojan.Win32.Genome.vqzz Virus.Win32.Nimnul.a

More often than not, virus writers use cloud storage as a place to host their malware rather than a platform to spread them. During the research, we did not encounter a single worm or backdoor (except DropSmack) specifically targeting cloud-based file storages. Naturally, these services try to counter malware which takes up storage room in the cloud. In addition hosting malware affects the service's reputation, although cloud services are not formally responsible for what files their clients upload to the storage. Regular scans of all files contained in the cloud will obviously require a lot of resources that the services would rather use to store data.

As a result of this research, we concluded that there is a relatively low risk of a corporate network being infected via cloud storage: over a period of a year, just 1 out of 1,000 corporate users using cloud services risks infection. It should be remembered, however, that in some cases even a single infected computer in a corporate network can lead to substantial damage.

Here are some measures that can be used to protect corporate networks:

  • Tighten up Firewall/IDS security settings, block access to popular online storage services. The big disadvantage this approach has is that it requires constant and close monitoring of new blacklist candidates as they emerge online.
  • Install a multi-purpose Security Suite. It must incorporate a heuristic and behavior-based antivirus, access restriction features (HIPS), a tool to control the functioning of the operating system (System Watcher or Hypervisor), and a tool to prevent exploitation of vulnerabilities, etc. Once installed, the product must be carefully configured.
  • Remember that even the most sophisticated Security Suite can miss an APT attack. Therefore, attention should be paid to Application Control (it should be configured at Default deny). This is perhaps one of the most reliable tools that will block any unknown software, including malware spread during a targeted attack. The most difficult task arising while deploying Application Control is to configure appropriate rules so that all permitted applications can be launched and updated without problems. To this end, the manufacturers of products which include the Application Control feature have developed dedicated tools: software updates via trusted update programs, preset software whitelists including all possible system and user files, access to huge cloud services and information databases about the entire diversity of whitelisted software.
  • In special cases, Application control should be used to restrict the use of cloud clients within the corporate network. Only trusted employees should be allowed to launch the applications with which to synchronize cloud folders.

As for networks with the most rigorous security requirements, such as those managing power plant operations and water supplies, which guard state secrets or control defense facilities - for all of these we thoroughly recommend not using cloud-based file storage services at all.

Syndicate content