A couple of people expressed interest in the ransomed files I recovered in my last diary entry.

I can not release those files, but I did create a similar file: ransomed-file.bin.

If you want to try to recover the picture in ransomed-file.bin, be aware that I released a new version of my byte-stats tool: byte-stats-V0_0_2.zip. It can find simple sequences and contains a man page now: run byte-stats.py -m to display the man page.

And if you manage to recover the jpeg file: let me know what you think this picture is ;-)

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
IT Security consultant at Contraste Europe.

Recently, I managed to register the domain name "comノindex.jp". This domain name uses the japanese "ノ" character, which looks somewhat like a slash typically used at the end of the domain name. As a result, an unsuspecting user may mistake the host name "example.comノindex.jp" for the "index.jp" page at "example.com". 

International domain names and look alikes are nothing new. As a result, registrars as well as browsers implemented various safeguards. But even with these safeguards, it is still possible to come up with creative domain names. Even without international characters, we do see "typo squatting" domains like "rnicrosoft" (this is "r" and "n" instead of "m"). There are a number of tools available that are trying to find all look alike domains. For example, Domaintools provides a simple online tool [1]. Some companies attempt to register all look-alike domains. But a domain like "comノindex.jp"  could be used to impersonate arbitrary .com domain names.

The DNS protocol does not understand anything but "plain ASCII". To encode IDNs, "punycode" is used. Punycode encoded domain names start with xn--, followed by all the ASCII letters in the domain name, followed by a dash and the international letters in an encoded format. For example, my domain encodes to xn--comindex-634g.jp. To mitigate the risks of IDNs, some browsers use punycode to display the domain name if they consider it "invalid".

Punycode and other related standards are described in a document commonly referred to as IDNA2008 (International Domain Names for Applications, 2008) and this document is reflected in RFC 5890-5895. You may still find references to an earlier version in RFCs 3490-3492. The RFCs mention some of the character confusion issues, but for the most part, refer to registrars to apply appropriate policies.

Similarly, there is no clear standard for browsers. Different browsers implement IDNs differently.

Safari: Safari redners most international characters with few exceptions. For example cyrillic and greek characters are excluded as they are particularly easily confused with English characters [2]

Firefox: Firefox maintains a whitelist of top level domains for which it will render international characters. See "about:config" for details. .com is not on the whitelist by default, but .org is. Country level TLDs are on the whitelist.

Chrome: Chrome's policy is a bit more granular [3]. 

Internet Explorer: Similar to chrome. Also, international characters are only supported if the respective language support is enabled in Windows [4]. The document on Microsoft's MSDN website was written for Internet Explorer 7, but still appears to remain valid.

Microsoft Edge: I couldn't find any details about Microsoft Edge, but it appears to follow Internet Explorer's policy.

And finally here is a quick matrix what I found users reporting with my test URL:

Chrome: displays punycode.
Firefox: displays Unicode
​Safari: displays Unicode (users of Safari on OS X < 10.10 report seeing punycode)
Opera: only a small number of Opera users participated, most reporting Unicode.
Internet Explorer: displays punycode

Mobile browsers behave just like the desktop version. E.g. Google Chrome on Android does not display Unicode, but Safari on iOS does.

For summaries of Unicode security issues, also see http://unicode.org/faq/security.html and https://www.owasp.org/index.php/Canonicalization,_locale_and_Unicode (among other OWASP documents)

[1] http://research.domaintools.com/buy/domain-typo-finder
[2] https://support.apple.com/kb/TA22996?locale=en_US&viewlocale=en_US
[3] https://www.chromium.org/developers/design-documents/idn-in-google-chrome
[4] http://msdn.microsoft.com/en-us/library/bb250505(VS.85).aspx

​NB: Sorry for any RSS feeds that the title may break.

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

For so long, USB keys have been a nice out-of-band infection vector. People like goodies and people like to plug those small pieces of plastic into their computers. Even if good solutions exists (like BitLocker - the standard solution provided by Microsoft), a lot of infrastructure are not protected against the use of rogue USB keys for many good or obscure reasons.

There are also multiple reasons to receive USB keys: from partners, customers, contractors, vendors, etc. The best practice should be to scan any suspicious device against malicious documents but how to achieve this in a safe AND not boring way. If you propose a tool that is easy to use, you will increase your chances to have it adopted by more people!

The CIRCL (Computer Incident Response Center Luxembourg) is coming from a very small country but they are very active and renowned. They developed a tool to sanitize USB keys. It's so easy that even non-tech people can use it! The project is called "CIRCLean". It's a piece of software that you install on an inexpensive Raspberry computer. You connect the suspicious device in the USB port A, a clean USB device in port B, power the box and wait for the process to be completed (depending on the amount of data to analyze). One picture is worth a thousand words:

What does it do? Multiple operations are performed on files, based on their MIME type. Example: Word files are converted to PDF then to HTML. Other files are renamed and prepended with a "DANGEROUS_" prefix. Once sanitized (or non dangerous), files are copied to the destination USB key. The code is available on their github repository.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

This morning, I faced an interesting case. We were notified that one of our computers was doing potentially malicious HTTP requests. The malicious URL was: api.wipmania.com. We quickly checked and detected to many hosts were sending requests to this API. It is a website hosted in France which provides geolocalisation services via a text/json/xml API. The usage is pretty quick and easy:

You provide an IP address and it returns its 2-letters country code. They provide also a paying version with more features. We investigated deeper and found that one request was indeed performed by a single host using a fake User-Agent. 

We also found that Snort signatures exist for this online service:

I found references to api.wipmania.com in the following malwares:

• Dorkbot
• Ruskill

​VT reported 97 occurrences of the domain wipmania.com in malicious files: https://www.virustotal.com/intelligence/search/?query=wipmania.com

Conclusion: if you provide online services and they become popular be careful to not be (ab)used by malwares! It could affect your overall reputation and make you flagged/blocked in black lists.  

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

Adobe today released a surprise patch for Shockwave [1]. The patch fixes one vulnerability, CVE-2015-7649 and Adobe's Shockwave Player on Windows and OS X is affected. The vulnerability is used in targeted exploit and Adobe learned about it from Fortinet's Fortiguard Labs. The latest version of Shockwave Player is now 12.2.1.171 and it replaces version 12.2.0.162.

Update: We got an email from someone at Adobe stating this vulnerability has not yet been exploited in the wild. Our initial assessment was based on the priority rating of "1" which Adobe descripes as "This update resolves vulnerabilities being targeted, or which have a higher risk of being targeted, by exploit(s) in the wild for a given product version and platform. Adobe recommends administrators install the update as soon as possible. (for example, within 72 hours)." and the fact that Fortiguard is credited in the Advisory. Fortiguard does track exploitation attempts detected by Fortinet customers.

[1] https://helpx.adobe.com/security/products/shockwave/apsb15-26.html

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

This weekend, I worked on a pentest report that was already pending for a while. I'm honest: I'm lazzy to write reports (like many of us, no?). During a pentest, it is mandatory to keep evidences of all your findings. No only the tools you used and how you used them but as much details as possible (screenshots, logs, videos, papers, etc). Every day, we had a quick debriefing meeting with the customer to make the point about the new findings. The first feedback was often a "Yes, but...":

Me: "We were able to connect a USB stick and to drop unwanted tools to the laptop!"
Customer: "Yes, but it will be disabled soon, the deployment process is ongoing!"

Me: "We were able to find sensitive documents on an admin's desktop!"
Customer: "Yes, but the admin forgot to delete it"

Me: "We were able to connect to remote servers using the same credentials!"
Customer: "Yes, but the operators are not supposed to connect on this network segment"

I could write tons of examples like these! When you're engaged in a pentest, it is executed within a defined scope at a time "t". If your targeted infrastructure is not ready yet, postpone the project. And if you think to be ready, accept to be compromised!

When speaking to customers, I like to compare a pentest to a plane crash. If a plane crash result often in many dead people, planes can be considered as safe. Statistically, flying is less dangerous than driving to the airport with your car! Modern planes are very reliable: critical components are redundant, strong procedures and controls are in place. Planes are designed to fly under degraded mode. The cabin crew is also trained to handle such situations. Finally, planes maintenance are scheduled at regular interval.

How to explain that, from time to time, a plane crash occurs? Most of the time, post-crash investigations reveal that the crash is the result of a suite of small or negligible issues which, taken out of context, are not critical. But, a small incident might introduce a second one, then a third one, etc. If a suite of such small incidents occur, nasty things may happen up to... a crash! This is called the “butterfly affect” which describes how a small change in a deterministic nonlinear system can result in large differences in a later state (definition by Wikipedia).

Keep in mind that the same may occur during a pentest. A small issue in a configuration file associated to files left in a public directory, an unpatched system and a lack of security awareness of the operators might result in a complete compromisation of your infrastructure. Avoid "Yes, but..." comments and take appropriate action to solve the issues.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

Joe wrote this weekend that:

A customer called me yesterday to make me aware of their computer that was compromised by one of those scam websites, that pops up an 800 numbers and tells them to call.  Against her knowing better, she STILL called in.... <ugh>.  

The site, I wanted to make you aware of was amvets.COM  She wanted to make a donation, but the real website is amvets.ORG

It is always sad to see how people with good intentions, willing to donate to a deserving cause, are being taken advantage of. So I took a bit time to investigate this particular case. 

First of all: I do NOT recommend you go to the ".com" version of the site above. I didn't see anything outright malicious, other then popups advertising the fake tech support service, but you never know what they are going to send next.

The content returned from the page is very variable. Currently, I am getting "index pages" linking to various "veterans" related pages. Typically these pages are auto-created using key words people used to get to the page, or keywords entered in the search field on the page. So no surprise that this page "knows" it is mistaken for a veteran charity. 

When it does display the "Fake Virus Warning" page, then it does so very convincingly:

- the lok and feel is adapted to match the users OS and browsers
- even on mobile devices, like my iPad, the page emulates the browser used

After a couple of visits to the site, it no longer displayed the virus warning to me, even if I changed systems and IPs. So I am not sure if they ran out of ad impressions or if they time them to only show up so often.

According to Farsight Security's DNS database, 10,000 different hostnames resolve to this one IP address. Most of them look like obvious typo squatting domains:

For example:
www.googele.be, besbuy.ca, wwwhockey.ca.

For some of them, I still get ads for "do nothing ware" like Mackeeper. (looking at the page from a Mac)

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

Introduction

In early September 2015, we started seeing reports about arrests tied to Dridex malware [1, 2].  About that time, we noticed a lack of botnet-based malicious spam (malspam) pushing Dridex malware.  During the month of September, Dridex disappeared from our radar.  By the beginning of October 2015, malspam pushing Dridex came back [3], and it's continued since then.

From what I can tell, Dridex was gone about a month, for most of September 2015.

Even though Dridex came back, organizations have still been discussing the previous takedown.  The most recent wave of reporting happened in mid-October after the US Justice Department (DoJ) published a news release discussing the August 2015 takedown [4].  The DoJ release on Dridex (also known as "Bugat" or "Cridex") reported the botnet administrator had been arrested back in August, and the botnet's operations were substantially disrupted.  That was old news, but it spread anew as other organizations passed on the information [5, 6, 7, to name a few].  Some of those reports warned that botnets are rarely disrupted for long, and that's certainly been the case with Dridex.

Details

When did the outage start?  When did it stop?  The Dridex botnet administrator was arrested on 2015-08-28 [4], and Palo Alto Networks reported Dridex was back by 2015-10-01 [3].  That represents an outage of approximately one month.  Let's get a clearer picture of how long the Dridex botnet was disrupted by searching VirusTotal using hashtags.

Shown above:  Searching for #Dridex on Virus Total.

This morning (Friday 2015-10-23) when I searched VirusTotal for #Dridex, I found more than 80 comments posted by at least a dozen individuals after the 2015-08-28 arrest.  These #Dridex comments covered 28 Word documents, 4 Excel spreadsheets, and 37 Win32 EXE files.  I also found 14 URLs tagged as #Dridex in the comments.

Shown above:  Examples of the #Dridex comments.

I compiled a spreadsheet of the data.  It's saved as a .csv file available here.  In it, you'll find an absence of #Dridex-tagged submissions after 2015-09-02.  #Dridex-tagged submissions resumed on 2015-10-01.  This matches what Palo Alto reported [3], and it gives us a little more insight on the Dridex disruption.

Shown above:  Spreadsheet indicates a gap in #Dridex-tagged malware.

The hashtag is a quick way to find files that people have specifically identified as Dridex.  Some of the files may have been mistakenly identified, so there's room for error.  However, this preliminary analysis backs up what Palo Alto reported [3], and plenty of us are seeing Dridex malspam on a near-daily basis now.

Final words

Dell SecureWorks has a good description of the architecture behind Dridex [7].  More recent write-up about Dridex malspam are available from sites like Dynamoo's Blog [8] and Techhelplist.com [9].  Twitter is also a good source for Dridex information and plenty of commentary.

Shown above:  Example of Twitter commentary on the recent Dridex takedown (link).

In the past few days, we've received samples of malspam attachments submitted by our readers.  Some of these submissions have been malicious Word documents associated with Dridex.  As always, handlers at the ISC continue to monitor the cyber landscape, and we'll keep you up-to-date on any recent trends.

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

References:

[1] http://krebsonsecurity.com/2015/09/arrests-tied-to-citadel-dridex-malware/
[2] https://threatpost.com/alleged-gozi-co-author-pleads-guilty-as-alleged-citadel-dridex-attacers-arrested/114566/
[3] http://researchcenter.paloaltonetworks.com/2015/10/dridex-is-back-and-targeting-the-uk/
[4] http://www.justice.gov/opa/pr/bugat-botnet-administrator-arrested-and-malware-disabled
[5] https://nakedsecurity.sophos.com/2015/10/15/dridex-botnet-taken-down-multi-million-bank-fraud-suspect-arrested/
[6] http://www.theregister.co.uk/2015/10/14/dridex_botnet_takedown/
[7] http://www.secureworks.com/cyber-threat-intelligence/threats/dridex-bugat-v5-botnet-takeover-operation/
[8] http://blog.dynamoo.com/search/label/Dridex
[9] https://techhelplist.com/component/search/Dridex

Maksymilian Arciemowicz of CXSECURITY released an advisory showing an unpatched buffer overflow in Apple's FTS library [1]. The "FTS" function is used by commands like "ls" and "cd" on Unix/BSD systems to traverse the file system. The exploit does not appear to present a serious threat right now as it requires an authenticated user on the system with the ability to create directories. It doesn't appear to lead to privilege escalation.

In order to trigger the vulnerability, the attacker will have to create a very deep set of subdirectories. Maksymilian creates 1024 with a simple bash script. While creating these directories, an error message, "cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory" will be displayed.

After returning to the top of the nested subdirectory structure, a recursive "ls -laR" will lead to a segmentation fault.

The impact of this vulnerability is likely small as it is not exploitable remotely and requires a user to be already logged in. But Maksymilian notes that man AV tools will miss binaries located more then 512 directories deep in such a nested file system, so it could be used to hide malware. 

[1] https://cxsecurity.com/issue/WLB-2015100149

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

Introduction

Earlier this week, various blogs began reporting about compromised Magento-based e-commerce websites.  These compromised sites kicked off infection chains for Neutrino exploit kit (EK).  I've seen a few examples of this traffic leading to a Neutrino EK landing page, all dated last week.

Sucuri's blog has information concerning the compromised Magento servers [1], while the Malwarebytes blog shows traffic from a compromised Magento site leading to Neutrino EK [2].  The Malwarebytes blog illustrates the flow of traffic for these Neutrino EK infection chains.  The examples I've seen were similar, so let's review the traffic.

Chain of events

The example I can share doesn't have a full infection chain, but it shows the same traffic patterns as the Malwarebytes blog entry. 

Shown above: Traffic from the Malwarebytes blog entry [2].

Shown above:  Other traffic I found, from Friday 2015-10-16.

Last week's chain of events appears to be:

• Bad actors behind this campaign compromise a Magento website.
• Pages from compromised sites have injected script pointing to a URL at guruincsite.com.
• The URL to guruincsite.com returns an iframe pointing to a second malicious domain.
• Second malicious URL returns HTML redirecting to a third URL ending with neitrino.php.
• Neitrino.php from the third malicious domain returns an iframe to a Neutrino EK landing page.

I've represented the traffic in a flow chart:

Shown above:  Flow chart for last week's infection chains.

Examining the traffic

Shown above:  Traffic I found on Friday 2015-10-16, this time with IP addresses.

Upon closer examination, last week's traffic followed specific URL patterns.  The HTTP GET request to guruincsite.com returned an iframe containing a URL ending with /app/?d22H.

Shown above:  HTTP GET request to guruincsite.com.

The HTTP GET request to the second URL ending with /app/?d22H returned HTML redirecting to another URL ending with neitrino.php (which I assume has a mistakenly spelled "neutrino").

Shown above:  HTTP GET request to the second URL.

The HTTP GET request to the third URL ending with neitrino.php returned an iframe pointing to a Neutrino EK landing page.

Shown above:  HTTP GET request to the third URL.

Final words

I can't provide any pcaps related to the recent wave of Magento site compromises, although I did find some Neutrino EK from a different actor on Wednesday 2015-10-21 [3].

The compromised websites that Magento has investigated were not up-to-date.  They all needed a patch that was published earlier this year [4].  I haven't seen anything yet that's led me to believe this was caused by a new or unpublished vulnerability.  This is probably an issue where people haven't been keeping their software updated or otherwise following poor security practices.

Sites will get compromised if they aren't patched and their software kept up-to-date.  Running a website on the Internet is like having a house in a bad neighborhood.  People are always trying to break in.

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

References:

[1] https://blog.sucuri.net/2015/10/massive-magento-guruincsite-infection.html
[2] https://blog.malwarebytes.org/exploits-2/2015/10/new-neutrino-ek-campaign-drops-andromeda/
[3] http://malware-traffic-analysis.net/2015/10/21/index.html
[4] https://magento.com/security/news/important-security-update

Apple published one of it's usual updates for "everything". Below I took a shot at a quick summary. You can find details here https://support.apple.com/kb/HT201222

iOS 9.1

49 Vulnerabilities fixed. A number of these affect WebKit and are exploitable via Safari. The update also addresses numerous issues in the FontParser. 

WatchOS 2.0.1

14 Vulnerabilities fixed. CVE-2015-5916 looks like a repeat of what was fixed in WatchOS 2: ApplePay may allow malicious terminals to retrieve a partial transaction history.

Safari 9.0.1

9 Vulnerabilities in WebKit fixed (pretty much the same vulnerabilities fixed in iOS 9.0.1)

iTunes 12.3.1

12 Vulnerabilities fixed, 9 of which affect WebKit which is included in iTunes.

EFI

EFI contained unused functions that could be abused. This update removes these unused functions.

Apple OS X 10.11.1

41 Vulnerabilities fixed. Again WebKit and some Fontparser vulnerabilities. This update also addresses issues with open source software included in OS X like php. The Safari 9.0.1 update is included in this update.

I didn't see an update for AppleTV yet, but wouldn't be surprised if it will be released as well. At least the WebKit issues will also affect AppleTV.

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

A reader sent us an "odd looking" DNS TXT record. The record was recovered from an old, decommissioned, DNS server. Has anybody seen this before? The zone also include the Google Apps authentication records, so it is possible that this is a similar scheme. According to the reader, the change times on the file are from 2010, but it is not certain that these times are correct. The file was maintained manually, so it is unlikely that a bad ip management script corrupted it.

We have seen DNS TXT records used as a covert channel in the past, so it is is possible this attempts to try something like this, or that these records were used for reflective DNS attacks. At this point, I really have no idea and was wondering if someone else has seen this.

bradmbig        TXT "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@Cc::.:::cc:C@@@@@@@@" "@@@@@@@Oc::....:...:::co@@@@@@" "@@@@@@c:::........:::::cc@@@@@" "@@@@@o:::::::c::::c:....:@@@@@" "@@@@O::::oooCoOOoCCOCc...O@@@@" "@@@@Oc.:CCCoCCOOOOCCCCC.:@@@@@" "@@@@@c::CCccoooOoooccoo..O@@@@" "@@@O@oCoCCCCCCCCoCCOCCoCoO@@@@" "@@@O@CCoCCOOCCCOCoCOCCoCCO@@@@" "@@@@@OCooCCCCCoooCCCCoooO@@@@@" "@@@OOO@OoooCccoocccCCooO@@@@@@" "@@@@OOOOCcooCCCCCCooco@@@@@@@@" "@@@@OOOOCocccoooCooccO@@@@@@@@" "@@@OOOOOCooocc:c::cooC@@@@@@@@" "@@O@OC..cCCoooCoCooooo.C@@@@@@" "@@O@c..:ooCCCCoocoCooo:.o@O@@@" "c..:....oCCCOCCCOCCoCo...:..cO" ".....:...oCCCCCCOOCOo....:...."
bradbig        TXT "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@" "@@@@@@@@@@Cc::.:::cc:C@@@@@@@@" "@@@@@@@Oc::....:...:::co@@@@@@" "@@@@@@c:::........:::::cc@@@@@" "@@@@@o:::::::c::::c:....:@@@@@" "@@@@O::::oooCoOOoCCOCc...O@@@@" "@@@@Oc.:CCCoCCOOOOCCCCC.:@@@@@" "@@@@@c::CCccoooOoooccoo..O@@@@" "@@@O@oCoCCCCCCCCoCCOCCoCoO@@@@" "@@@O@CCoCCOOCCCOCoCOCCoCCO@@@@" "@@@@@OCooCCCCCoooCCCCoooO@@@@@" "@@@OOO@OoooCccoocccCCooO@@@@@@" "@@@@OOOOCcooCCCCCCooco@@@@@@@@" "@@@@OOOOCocccoooCooccO@@@@@@@@" "@@@OOOOOCooocc:c::cooC@@@@@@@@" "@@O@OC..cCCoooCoCooooo.C@@@@@@" "@@O@c..:ooCCCCoocoCooo:.o@O@@@" "c..:....oCCCOCCCOCCoCo...:..cO" ".....:...oCCCCCCOOCOo....:...."
bradmsmall      TXT "@@@@@@@@@@@@@@@@@" "@@@@@8c:::cc8@@@@" "@@@O::....:::c@@@" "@@@::c:cc:c:..O@@" "@@8:cCCCOOCCC.8@@" "@@8ooCCCCoCCoo8@@" "@@8CoCCoooCCoo@@@" "@@88CoCoooooo@@@@" "@@88Oocooocc8@@@@" "@88c:CCooooo:O@@@" "Oc..cCCCCCCCc.:O8" ".....cCCCOCc....."
bradm      TXT "@@@@@@@@@@@@@@@@@" "@@@@@8c:::cc8@@@@" "@@@O::....:::c@@@" "@@@::c:cc:c:..O@@" "@@8:cCCCOOCCC.8@@" "@@8ooCCCCoCCoo8@@" "@@8CoCCoooCCoo@@@" "@@88CoCoooooo@@@@" "@@88Oocooocc8@@@@" "@88c:CCooooo:O@@@" "Oc..cCCCCCCCc.:O8" ".....cCCCOCc....."

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

On Tuesday, Oracle released it's Quarterly Critical Patch Update or "CPU" for short. As usual, this release covers a long list of different products, and is too large to summarize in a diary. Oracle patched a total of 154 vulnerabilities. Here are some of the "highlights" :

Java:

Of course, Java is always getting a lot of attention as it has probably the largest user base among Oracle's products. This time, Oracle is patching 25 Java flaws. All vulnerabilities can be exploited via Java Web Start applications, but only 5 apply to Java running on servers. 7 of the vulnerabilities have the highest CVSS score of "10" (none of these can be exploited on server side code).

Sun Systems:

The "Integrated Lights Out Manager" (ILOM) receives a patch that fixes a remote code execution vulnerabilities with a base CVSS score of 10. Comparable "IPMI" interfaces suffered from numerous vulnerabilities in the past, and Oracle does the right thing by advising users to not expose these interfaces to public networks.

OpenSSL

Various Oracle components use OpenSSL, and this patch includes OpenSSL related updates for MySQL, Oracle Enterprise Manager and Oracle Supply Chain Products.

According to Oracle, there is no evidence that any of these vulnerabilities has been exploited so far. The next update will be released in January.

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

Out of most penetration tests I do, XSS vulnerabilities are still probably the most common ones we encounter (if I don’t count missing Secure and HttpOnly flags on cookies :)).

Even web application vulnerability scanners have become increasingly successful in finding XSS vulnerabilities so the next question (besides why do we still see them) is related to their exploitation.

I recently encountered a simple, but interesting XSS vulnerability, which demonstrated yet again how standardization is important. So, let’s see what this is about.
The vulnerability in question is a very simple reflected XSS vulnerability where contents of a user supplied parameter from a GET HTTP request are copied directly into the resulting HTML.

However, there was a simple catch – here is what the resulting HTML code looks like and where the user supplied parameter is injected:

...
form action="/myform/action/post" id="myform" method="post" name="myform"
...

The contents of the injected parameter are highlighted in the HTML code shown above (also there should be < at the beginning and > at the end of the line, but ISC diary editor is giving me issues so just imagine those two characters). So, when the user submits a GET HTTP request such as this one:

GET /myform/action/post?myparam=123

The vulnerable application creates the following HTML code:

...
form id="myform" action="/myform/action/post?myparam=123" method="post" name="myform"
...

Ok – hopefully all of you see where this is going to. If we insert the " character we will close the action parameter and are practically free to do whatever we want. If we can insert the > character it’s game over.

The vulnerability shown is very simple and in most cases even web application vulnerability scanners will detect is as such.

So what’s the story here you might ask? Well, the tricky thing is in getting the victim to click on a link which will exploit the vulnerability. Remember how we need to send the " character? Well, that turns out not to be all that straightforward with modern browser. If our attacker link looks like this:

http://www.vulnerable.application/myform/action/post?myparam="> Test

the browsers will send the following GET requests (you can test it with your own browser easily):

Mozilla Firefox: GET /myform/action/post?myparam=%22%3E%20Test
Google Chrome: GET /myform/action/post?myparam=%22%3E%20Test
Internet Explorer: GET /myform/action/post?myparam=">%20Test

Say whaat (insert image from Anchorman 2 here)? Interesting! So, in other words, Internet Explorer is the only browser (of those three I tested) that will not encode the "> characters. This effectively allows the attacker to launch a reflected XSS attack against Internet Explorer users, while those using Mozilla Firefox and Google Chrome will be safe(r)! (so Internet Explorer is indeed less secure ….. /me ducks).

Jokes aside, why is this happening? In order to dig that out we need to check URI syntax, which is specified in RFC 3986 (https://tools.ietf.org/html/rfc3986). The RFC splits characters into several groups: unreserved characters ( ALPHA / DIGIT / "-" / "." / "_" / "~" ), reserved characters ( ":" / "/" / "?" / "#" / "[" / "]" / "@" and "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=) and all the others.

We can see that ", < and > are in neither of the lists above! However, the RFC says the following:

“When a new URI scheme defines a component that represents textual data consisting of characters from the Universal Character Set [UCS], the data should first be encoded as octets according to the UTF-8 character encoding [STD63]; then only those octets that do not correspond to characters in the unreserved set should be percent-encoded.”

One would probably read this as the following: *everything* apart from unreserved characters should be encoded. However, while reading the RFC I missed what really “a new URI scheme” is?

In any case, it looks as Internet Explorer developers decided that they will strictly encode only reserved characters (plus some extras), but they left couple of important ones such as ", < and >.

I had a lively discussion with my colleague Marin about reporting such vulnerabilities in penetration tests. Our conclusion was to always report it (of course), even though exploitability might be more or less difficult (or even impractical) with some browsers – the underlying vulnerability is still here and should be fixed.

How does your browser behave? Let us know!

--
Bojan
​@bojanz
INFIGO IS

Last time I helped out someone with ransomware over at the Bleeping Computer forums, I was able to recover the ransomed JPEG files.

A first look at the file with the file command did not help me:

file image.jpg.xxx\@yyy.zz
image.jpg.xxx@yyy.zz: data

Neither did a look at the header with a hex editor tell me much more.

But when I analyzed the file with one of my tools to calculate byte statistics (byte-stats.py), I noticed something:

The file has a high byte entropy: 7.815519, that's almost the maximum (8.0). So the file appears to be a set of random bytes, e.g. an encrypted file.

But my program not only calculates the entropy for the whole file (along with other properties), but it also splits the file in buckets (10KB size by default) and calculates the entropy (and other properties) for each bucket. The second entropy value produced by the analysis (5.156678) is the lowest entropy calculated for the buckets (85 in total for this file). And an entropy of 5 is much lower than the entropy of encrypted or compressed data. So somewhere in this file there is data that doesn't look very random.

A picture is worth a thousand words is the saying. bytes-stats.py can also output the entropy for each bucket (option -l), which enabled me to produce this graph:

Somewhere around position 0x5000, data doesn't look random. I took a look with my hex editor, and quickly recognized JPEG structures. What was missing were the first headers of a JPEG file. So I patched a file together with the header of a JPEG file followed by the data recovered from the ransomed file. And to my surprise, I had recovered the image.

I had no luck when I analyzed a ransomed .doc file from the same victim:

The entropy of this file looks uniformly high.

I often look at the entropy when I analyze files. Many of my analysis tools include entropy calculations. For example, pecheck.py provides the entropy of each section of a PE file, allowing me to quickly identify packed sections.

Didier Stevens
Microsoft MVP Consumer Security
IT Security consultant at Contraste Europe.
blog.DidierStevens.com DidierStevensLabs.com

•  Ensure the running configurations on your network equipment have not changed
•  Ensure you know within a few minutes when a new administrative account is added
•  Ensure you know within a few hours if a device stops sending logs to your syslog server

Adobe released a new Flash Player update to fix the latest 0-day vulnerabilities.

Flash Player v 19.0.0.226
Flash Player ESR v 18.0.0.255

To update, visit https://get.adobe.com/flashplayer/

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

We got a number readers asking about the ongoing issues with Flash. Adobe released it's regularly monthly update for Flash on Tuesday. With this update, you should be running Flash 19.0.0.207. However, on Wednesday, Adobe published a security bulletin that a new, so far unpatched, vulnerability (CVE-2015-7645) is being exploited. Adobe is currently talking about targeted and limited attacks. 

Sometime next week, an update to Flash will be released to address this vulnerability.

So what should you do and what does this all mean?

Next week's patch is unlikely to change the fact that there are a large number of so far unpublished vulnerabilities in Flash. It appears that some groups exploiting these vulnerabilities are able to find these vulnerabilities faster then Adobe is willing to patch them. Even after Adobe releases a patch next week, there will likely be new vulnerabilities that will be used starting as soon as the patch will be released. So really, one more patch wont fundamentally change anything.

What should you do?

If possible uninstall Flash. If you can not uninstall it, at least make sure that your browser does not automatically launch Flash applets. This "Click to Run" behavior should be enabled for all plugins that support it (e.g. Java). 

Here are some quick tips on how to enable click-to-run:

Firefox: It should be enabled by default. Check the "plugins.click_to_play" setting in about:config to make sure it is enabled.

Internet Explorer: Click the gear icon and select "Manage Add-ons". For the Shockwave Flash Object, select "More Information". By default, all sites are approved due to the wildcard "*" in the approved site box. Delete it.

Google Chrome: In chrome://settings click on "Show advanced settings..." at the bottom fo the page. Click on the "Content Settings" button under "Privacy" and select "Let me choose when to run plugin content" under Plugins. You can also review existing exceptions that you may have set up in the past, and you can disable individual plugins.

Safari: Check the "Security" tab in preferences. Under Plugin Settings you can enabled/disable individual plugins.

[1] https://helpx.adobe.com/security/products/flash-player/apsa15-05.html

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

Introduction

Earlier this month, Cisco's Talos team published an in-depth report on the Angler exploit kit (EK) [1].  The report also documented Cisco's coordination with hosting providers to shut down malicious servers associated with this EK.  The result?  I've found far less Angler EK in the last two weeks or so.

Angler is still active, even if we're not finding as much as before, and other EKs remain a concern.  CryptoWall 3.0 remains a popular payload.  I've noticed CryptoWall 3.0 from Angler, Nuclear, and Rig EK in the past few days. 

Let's look at some recent examples of EK traffic.

Nuclear EK

The URL structure for Nuclear EK has changed since my previous ISC diary about it last month [2].  The landing page URL (the initial HTTP GET request) has recently changed patterns.  Previously, we'd seen the HTTP GET request start with /url?sa= , but now it's back to /search? followed by random characters.  The images below show HTTP GET requests for Nuclear EK on Wednesday 2015-10-14.

Shown above:  Nuclear EK on a machine running IE 8 and outdated Flash player (sent one malware payload).

Shown above:  Nuclear EK on a machine running IE 8 and outdated Flash player (sent two malware payloads).

In recent weeks, I've noticed at least two types of infection chains for Nuclear EK.  The first type uses a gate with 052F in the URL.  So far, I've seen ransomware payloads delivered by "052F" Nuclear EK.  Last month I saw TelsaCrypt 2.0 [3], and this month I've seen CryptoWall 3.0.  

The other type of infection chain for Nuclear EK chain has no gate, and it's been delivering two malware payloads.  This "dual payload" Nuclear is similar to what we saw in last month's diary on this EK [2].

I'm calling these two types of infection chains:

• 052F gate Nuclear EK
• Dual payload Nuclear EK

Traffic characteristics indicate these are different actors.  Other actors are also associated with Nuclear EK, like the Windigo group [4], BizCN gate actor [5], and (I assume) many more.  This diary only covers the 052F and dual payload actors.

052F gate Nuclear EK sends CryptoWall 3.0

On 2015-10-14, a compromised server leading to the 052F gate had obfuscted javascript injected into the site's web pages.

Shown above:  Some of the injected script in a page from compromised website (the full length of the script is not shown).

The obfuscated javascript led to the 052F gate, which returned more obfuscated script. 

Shown above:  More obfuscated script returned from the 052F gate.

HTTP traffic after the 052F gate showed Nuclear EK followed by CryptoWall 3.0 callback activity.

Shown above:  The traffic in Wireshark, filtered on HTTP requests, showing indicators of Nuclear EK and CryptoWall 3.0.

Shown above:  Alerts from a pcap of the traffic after using tcpreplay in Security Onion.

This CryptoWall 3.0 sample's bitcoin address for the ransom payment was 12V5XLJ8zfespa2ABZJKUX8oQbVpwT5Uwb

Shown above:  User checking decryption instructions on the infected Windows host.

Dual payload Nuclear EK sends its dual payloads

I've noticed this recent dual payload Nuclear EK actor since mid-September 2015 [2, 6, 7].  Code is injected near the end of the page, right before the closing body and HTML tags.  There are several dozen blank lines before the malicious iframe leading to a Nuclear EK landing page.  I recently saw this type of traffic again on Wednesday, 2015-10-14.

Shown above:  Malicious code on a page from the compromised website.

After the Nuclear EK traffic, HTTP requests show a GET /harsh02.exe for follow-up malware, and we also see subsequent alerts on possible Kelihos malware.

Shown above: The traffic in Wireshark, filtered on HTTP requests, showing indicators of Nuclear EK and post-infection traffic.

Shown above: Nuclear EK sends the first of its dual payloads.

Shown above: Nuclear EK sends the second of its dual payloads.

Shown above:  Follow-up malware after this Nuclear EK infection with the dual payloads.

Shown above:  Alerts from a pcap of the traffic after using tcpreplay in Security Onion.

Rig EK sends CryptoWall 3.0

On Tuesday 2015-10-13, I infected a Windows host through Rig EK and saw CryptoWall 3.0 as the payload.  Pages compromised by this actor have injected script with an unobfuscated iframe leading to Rig EK.

Shown above:  Malicious code on a page from the compromised website.

After Rig EK, we find indicators of CryptoWall 3.0 in the post-infection traffic.

Shown above: The traffic in Wireshark, filtered on HTTP requests, showing Rig EK and CryptoWall 3.0 post-infection traffic.

Shown above:  Alerts from a pcap of the traffic after using tcpreplay in Security Onion.

This CryptoWall 3.0 sample's bitcoin address for the ransom payment was 1BkEAqygc5Mg2ree7ks34xPMA9kUjB2Qx3

Shown above:  User checking decryption instructions on the infected Windows host.

Angler EK still out there, still sending ransomware

On Tuesday 2015-10-13, I generated an Angler EK infection and saw CryptoWall 3.0 as the payload [8].  Injected script from the compromised website is highly-obfuscated, but it's quite distinctive.

Shown above:  Malicious code on a page from the compromised website.

After Angler EK, we saw indications of a CryptoWall 3.0 infection.

Shown above: The traffic in Wireshark, filtered on HTTP requests, showing Angler EK and CryptoWall 3.0 post-infection traffic.

Shown above:  Alerts from a pcap of the traffic after using tcpreplay in Security Onion.

The bitcoin address for this CryptoWall 3.0 sample's ransom payment was 1yA3czfyuUeYHwgNZnvBSatU8Z7GJffj2

​
Shown above:  User checking decryption instructions on the infected Windows host.

Final words

The exploit kit landscape can quickly change, and what's current this week may not be the next.  My field of view is limited, and this EK round-up is not comprehensive.  I've also seen Neutrino EK recently [9], which is not documented in this diary.  Furthermore, other EKs are still active, even though I haven't been covering them.  Hopefully this diary reflects some of the more common EK traffic during the past week or so.

Below is a link for a zip archive containing all of the pcaps:

• 2015-10-15-ISC-diary-all-pcaps.zip - 3.5 MB (3,541,327 bytes)

Below is a link for all zip archive containing all the malware and artifacts:

• 2015-10-15-ISC-diary-all-malware-and-artifacts.zip -  2.1 MB (2,081,496 bytes)

The zip archives are 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://talosintel.com/angler-exposed/
[2] https://isc.sans.edu/forums/diary/Recent+trends+in+Nuclear+Exploit+Kit+activity/20203/
[3] http://malware-traffic-analysis.net/2015/09/29/index.html
[4] https://isc.sans.edu/forums/diary/A+recent+decline+in+traffic+associated+with+Operation+Windigo/20065
[5] https://isc.sans.edu/forums/diary/BizCN+gate+actor+update/20209/
[6] http://malware-traffic-analysis.net/2015/09/18/index.html
[7] http://malware-traffic-analysis.net/2015/10/08/index.html
[8] http://malware-traffic-analysis.net/2015/10/13/index2.html
[9] http://malware-traffic-analysis.net/2015/10/13/index3.html

A few days ago, I found a malicious website which tries to lure the visitor by simulating a Microsoft Windows Blue Screen of Death (BSOD) and popping up error messages within their browser. This is not a brand new attack but it remains in the wild. For a while, we saw "Microsoft engineers" calling people to warn them about an important problem with their computer (I blogged about this last year). In this case, it is different: the computer itself warns the user about a security issue and users trust their computer! The following URL (it changes depending on the ongoing campaign) is accessed by the browser and:

• Displays a fake BSOD
• Displays constant Javascript pop-up messages containing technical information about a process failure
• Plays a MP3 with a female voice asking you to not reboot your computer and to call a provided toll-free number

The URL contains also many parameters which, I presume, can help the attacker to identify his victim and adapt the social engineering scenario based on browser, location, etc. Here is an example of such URL:

The domain has been registered in July 2015 (whois details) and the index page calls an index.js file with obfuscated JavaScript. Here is the decoded content:

Note the link to the MP3 file, which can be played as is (the link is a safe copy available from my blog). Interesting, the phone number displayed in message is customized and, in my cases, I received different numbers:

• (855) 348 1197
• (888) 725 1202

It was too tempting to call them. I picked up the first one and reached a call center broadcasting professional messages ("your call can be monitoring and recorded", "your call is very important to us"). After waiting for a few minutes, I spoke to a human guy (without Indian accent!) who presented himself as working for a premium technical support for computers. I explained to him my problem ("It seems that my computer is infected by a virus") but he was not able to help me!?  I did not test the second number but it has already been reported as malicious by other people.

This is not a brand new attack but it can make non-technical people scary. I also found that, since June 2015, Emerging Threats provides rules to detect this in their open rule set:

I recorded a small video of the web page.

Xavier Mertens
ISC Handler - Freelance Security Consultant
rootshell.be
truesec.be

Adobe has released APSB15-24 which addresses 56 vulnerabilities: CVE-2015-5583, CVE-2015-5586, CVE-2015-6683, CVE-2015-6684, CVE-2015-6685, CVE-2015-6686, CVE-2015-6687, CVE-2015-6688, CVE-2015-6689, CVE-2015-6690, CVE-2015-6691, CVE-2015-6692, CVE-2015-6693, CVE-2015-6694, CVE-2015-6695, CVE-2015-6696, CVE-2015-6697, CVE-2015-6698, CVE-2015-6699, CVE-2015-6700, CVE-2015-6701, CVE-2015-6702, CVE-2015-6703, CVE-2015-6704, CVE-2015-6705, CVE-2015-6706, CVE-2015-6707, CVE-2015-6708, CVE-2015-6709, CVE-2015-6710, CVE-2015-6711, CVE-2015-6712, CVE-2015-6713, CVE-2015-6714, CVE-2015-6715, CVE-2015-6716, CVE-2015-6717, CVE-2015-6718, CVE-2015-6719, CVE-2015-6720, CVE-2015-6721, CVE-2015-6722, CVE-2015-6723, CVE-2015-6724, CVE-2015-6725, CVE-2015-7614, CVE-2015-7615, CVE-2015-7616, CVE-2015-7617, CVE-2015-7618, CVE-2015-7619, CVE-2015-7620, CVE-2015-7621, CVE-2015-7622, CVE-2015-7623, CVE-2015-7624

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

Overview of the October 2015 Microsoft patches and their status.

-- 
Alex Stanford - GIAC GWEB & GSEC,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford

Over the years, I have used several types of graphing tools to visualize data, some free some commercial and haven't really been able to find to perfect tool that lets me easily ingest and manipulate multiple any types of data in a single tool without having to modify something before ingesting it. The most common data I want to manipulate are various type of logs; either in real-time or consume that data later during an incident. Some of the more flexible tool I have used so far are yEd by yWorks and Gephi.

Both are pretty good tools but they cannot parse and display data in real-time and there are limits in how much data to consume. If too much data is consumed, it become very difficult to view the relationships but it is useful and practical for post analysis.

Using the same data file, here is a display from each tools. Gephi can ingest CSV comma delimited formatted data, however, with yED the CSV must be converted to Excel 97-2003 Workbook format first before it is process. If you plan on trying out Gephi, you need to JDK 1.7 in order to run the application, information on how configure gephi.conf is available here.

yEd Visualization

Gephi Visualization

I have listed a few of the tools I have used and tried before. I you have used other tools that provide good results, I would be interested to hear about it.

Free Tools

[1] http://www.yworks.com/en/products/yfiles/yed/
[2] http://gephi.github.io/
[3] http://www.graphviz.org

Community and/or Commercial

[4] https://www.paterva.com/web6/products/maltego.php
[5] http://www.sqrrl.com
[6] http://www.advizorsolutions.com/

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

The GnuPG group has announced the release of GPG version 2.1.9, which addresses a number of technical issues within the components of the code.  The update of any encryption component should be carefully planned, as the impact is often not fully understood until some data cannot be accessed because of encryption issues.  Having worked with GPG before, it is very straightforward to implement and get running; harder to develop a long term strategy, thus we can easily paint ourselves in a corner due to a lack of planning.

If you are running a version of GPG older than version 2.1, i strongly recommend taking a look at the changes “What’s new in GnuPG 2.1”.  Changes introduced in version 2.1 could have serious impact, such as “support for PGP-2 is removed”.  And, as always, we strongly recommend testing all updates in a non-production environment before pointing the update machines at any production environment.

tony d0t carothers --gmail

For quite a while now, we provide the option to use a time-based one-time password as a second factor to authenticate to your ISC account. The implementation we picked was RFC 6238 as it is also implemented by Google's popular "Authenticator" app. But so far, we haven't had a good solution for the "lost authenticator" problem. It required an administrator to manually reset the particular account.

To help with password and authenticator resets in the future, we are now also supporting SMS and Voice Call based authentication. To enable this feature, you will need to provide one or more phone numbers that can be used to authenticate you. If you lost your authenticator app (e.g. if you get a new phone), or if you need to reset your password, this number is used to authenticate you.

This *should* work with phone numbers globally, not just US numbers. But of course, we can only test a couple of countries. Please let us know if you run into any problems.

At this point, I don't think it makes sense to make two-factor authentication mandatory for our site. Many users do not have any personal information stored with us. But I think it does make sense to provide the option and allow users to decide if they feel it is necessary or not.

To configure your phone number, see http://isc.sans.edu/pwresetinfo.html (you will have to log in first of course)

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

Adobe is going to release eight security updates for Adobe Acrobat and Reader for Windows and Macintosh next Tuesday, October 13, 2015. A list of the updates is available here.

[1] https://helpx.adobe.com/security/products/acrobat/apsb15-24.html

-----------
Guy Bruneau IPSS Inc.
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

Introduction

Malicious spam (malspam) impersonating eFax is old news, yet we still occasionally see it.  Earlier this week, someone sent the ISC an example of eFax-themed malspam with an attached Word document.  Those eFax-themed malspam containing Word documents are not new [1], but the person submitting the example thought it might be Dridex.  But I haven't seen much Dridex since key players behind Citadel and Dridex were arrested in late August 2015 [2].  Was this another wave of Dridex?

In this diary, we investigate.  The result?  It wasn't Dridex.  It was just another Word document --> enable macros --> Pony downloader --> follow-up malware.  From what I can tell, the malware we found is being used in other themed malspam campaigns, not just eFax-themed.  I like to document these, if only to remind people the spammers and botnets are still pushing out this sort of malware.

Our thanks to Wayne who provided the sample.  (You know who you are!)

The malspam example

Below is a screenshot from the malspam example Wayne sent us.  Links in the email all went to the appropriate eFax URLs.  The attached Word document is the only malicious part of the message.

Shown above:  An example of the malspam.

Looking at the email headers, you'll find the recipient's email server received the message from a Unified Layer IP address at 67.222.39.168.

Shown above:  Email headers from the malspam.

The malicious Word document

The Word document has macros.  If macros are enabled, the document will try to drop malware and infect the Windows host.

Shown above:  Document from the malspam opened in Microsoft Word.

Using OfficeMalScanner, we can extract the malicious macro from the Word document.

Shown above:  Using OfficeMalScanner's info mode to extract the malicious macro from the Word document.

Once you've got the macro extracted, you can review it with a text editor.  This gives you some idea on what the macro does.  For example, in the image below, you might be able to determine that 300.rtf, 301.rtf, and pm4.exe are created in the user's AppData\Local\Temp folder (the "TEMP" environment).

Shown above:  Viewing the extracted macro using a text editor.

Traffic from the infected host

Infecting a host using this Word document didn't generate a lot of traffic.  There was only a Fareit/Pony-style check-in followed by the follow-up malware being downloaded.  By the time I reviewed the malware on Wednesday 2015-10-07, all hosts for the Fareit/Pony-style check-in traffic didn't resolve in DNS.  I had to use a pcap from a Hybrid-Analysis.com report to see the check-in traffic. 

Shown above:  Traffic from Hybrid-Analysis.com's report of the malicious Word document on 2015-10-06.

Shown above:  In traffic from 2015-10-07, none of the sample's Fareit/Pony check-in domains resolved.

Below are indicators of compromise (IOCs) for the malware associated with this malspam:

• 185.42.15.7 - babsuptono.ru - POST /gate.php
• 151.236.10.194 - toftereventhi.ru - POST /gate.php
• 93.171.158.226 - buteventheckand.ru - POST /gate.php
• 136.243.24.4 - germantest.redsnapper.net - GET /m.exe

Below are alerts generated from the Hybrid-Analysis.com's pcap when I used tcpreplay on Security Onion with the EmergingThreats (ET) open signature set.

Shown above:  Alerts from the Hybrid-Analysis pcap using Sguil in Security Onion.

Preliminary malware analysis

Attachment name:  fax_message_326-816-3257.doc

• File size:  484.0 KB ( 495,616 bytes )
• MD5 hash:  5cb9cff7e12b6c1d8724ab8f8a10555e
• SHA1 hash:  834d314fe2f1e696a3217c24e6d726f61bd131a4
• SHA256 hash:  9686caf5e37a676ce63054959dfe7ab3e09863f86fd13fb720dc2921621aa8a5
• Detection ratio:  24 / 56
• First submission:  2015-10-06 14:28:27 UTC
• Virus Total link  -  Hybrid-Analysis link

Malware dropped by the document:  C:\Users\username\AppData\Local\Temp\pm4.exe

• File size:  442.0 KB ( 452,608 bytes )
• MD5 hash:  29893d41d5b4d161ad8cd76628c4ae41
• SHA1 hash:  bc12a7d683a995329ec94e895a2b0008d3487b22
• SHA256 hash:  c5eb33f5a721be5d4a3026110e57b67a1c4d2aaab013dc379df588ac5f88913a
• Detection ratio:  17 / 56
• First submission:  2015-10-06 19:37:14 UTC
• Virus Total Link  -  Malwr link  -  Hybrid-Analysis link

Other files noted in the user's AppData\Local\Temp directory:

• 300.rtf - 1.7 MB ( 1,754,310 bytes )
• 301.rtf - 1.7 MB ( 1,754,310 bytes )

Malware downloaded to infected host:  m.exe  stored as C:\Users\username\AppData\Local\[random name]\[random name].exe

• File size:  315.5 KB ( 323,072 bytes )
• MD5 hash:  d76369863106b2f5a7da78169c6abec0
• SHA1 hash:  5d0fdbf6b3a7893fa416015add969bed34d2768f
• SHA256 hash:  376ca73c50a71578d3a2d8088559589e28db0820e025e9f4f7bad9813316ad4c
• Detection ratio:  2 / 56
• First submission:  2015-10-06 17:47:13 UTC
• Virus Total Link  -  Malwr link  -  Hybrid-Analysis link

Final words

Overall, we found nothing really new with the malspam, but we had fun checking it out.  If you have any suspicious files (emails, malware, pcaps, etc.) you'd like us to investigate, use our site's contact link.  You can attach a file to the contact form and leave us a note about it.  We can't always get to everything submitted, but we like to see what people are able to share.

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

References:

[1] http://threattrack.tumblr.com/post/50992552536/malicious-efax-corporate-spam
[2] http://krebsonsecurity.com/2015/09/arrests-tied-to-citadel-dridex-malware/

Online extortion, may it be ransomware like cryptolocker, or extorting people with damaging data like Ashley Madision, is certainly one way criminals try to use to make a living. Many of these attempts go unreported, and I expect that they are also often ignored by the individuals receiving these emails. As an example, one of our readers sent us an Ashley Madison extortion attempt.

The individual forwarding us the extortion emails received multiple e-mails. All appear to originate from the same group. The "From:" addresses for all of the emails use the ".xyz" top level domain and similar subject lines as well as bodies.

Interestingly, the amount being extorted varies from e-mail to e-mail between 1 BTC and 5 BTC. The e-mails note two different Bitcoin addresses. For Bitcoin transactions, it is pretty easy to figure out how many Bitcoins were transferred to any particular address. All transactions are registered in the blockchain, and sites like blockchain.info allow you to search the blockchain for a particular transaction. In this case, it certainly looks like the miscreant was paid. One of the addresses received two transactions of 1 BTC each, and the other one a total of 9 BTCs in several transactions ranging from 1 to 3 BTC.

So the short lesson: crime pays. If we assume that all these transactions are due to these extortion emails (and the amounts match what was asked for), then these emails made at least 11 BTC or $2,700 . It is likely that this individual or group uses multiple bitcoin addresses. Sadly, the victim in this case paid for nothing. Since the data is already public, many others could follow with similar extortion requests.

In this particular case, the attacker makes the threat more "real" but claiming that they found the victim's Facebook page and they threaten to share the information with the victim's Facebook friends and possibly employer. They then advice the victim to change the Facebook privacy settings to prevent others from doing the same.

Here is the full text of the e-mail (I removed the bitcoin address as it may link to the person forwarding us the e-mail):

From: "Laura" <....@......xyz>
Subject: You got.... busted

Unfortunately your data was leaked in the recent hacking of Ashley Madison and I know have your information. I have also used your user profile to find your Facebook page, using this I can now message all of your friends and family members.

If you would like to prevent me from sharing this dirt info with all of your friends and family members (and perhaps even your employers too?) then you need to send 1 bitcoin to the following BTC address.

Bitcoin Address:
?????????

You may be wondering why should you and what will prevent other people from doing the same, in short you now know to change your privacy settings in Facebook so no one can view your friends/family list. So go ahead and update that now (I have a copy if you dont pay) to stop any future emails like this.

You can buy bitcoin using online exchanges easily. If the bitcoin is not paid within 3 days then my system will automatically message all of your friends and family members. The bitcoin address is unique to you.

Consider how expensive a divorce lawyer is. If you are no longer in a committed relationship then think about how this will affect your social standing amongst family and friends. What will your friends and family think about you?

Sincerely,
Laura

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

Johannes introduced yesterday the Cyber Security Awareness month. As security professionals, our job is to take care of our systems and networks but also our users!  Instead of giving repetitive technical tips ("do & don't"), why not try an alternative way to push messages to them via proverbs? Wikipedia define a proverb as "a simple and concrete saying, popularly known and repeated, that expresses a truth based on common sense or the practical experience of humanity". In this definition, the keywords are: simple, truth, common and experience. Let's review some proverbs which address security of end-users as well as administrators.

“In the kingdom of the blind, the one-eyed man is king” – Visibility is a key aspect of information security. You have to be aware and understand what is happening in your environment. Due to the amount of information to process, tools exist (like a SIEM) but can be very expensive. Even if you don’t have enough budgets or resources to set-up a top-notch security environment, try to implement a minimum of controls. Concentrate yourself first on the most business critical aspects (use-cases).

“Never put off to tomorrow what can be done today” – New vulnerabilities are discovered every day. Some may affect your assets. If it’s the case, apply a countermeasure as soon as possible. If available, install the patch provided by the manufacturer/developer. If it remains unpatched (or waiting for a new release), implement extra controls like access lists, monitoring. Don’t wait, do it now!

“Clothes don’t make the man” – Take care of phishing and social engineering attacks. Do not disclose information before checking the reliability of the people asking for it. Do not trust anybody.

“Never tell an enemy that your foot aches” – Protect your assets by not disclosing sensitive information in public forums or mailing lists. Some people post technical questions in public areas to request some support or tips. Such disclosed information could be very useful for an attacker. Your application must be hardened and never run with the factory settings. Do not answer to polls via phone calls.

“Little brooks make great rivers” – A suite of small incidents may lead to a bigger security breach. All issues must be properly addressed. A small incident can be a first step in the process of compromizing a system. Information security can be compared to airlines: Crashes are often due to a suite of small incidents which occurred in a proper order.

“Sow the wind and reap the whirlwind” – If you don’t properly implement security controls, be prepared to the worst. Be honest and don’t pretend to be “bullet-proof”. Nobody is!

“Better late than never” – Some security controls might require lot of time to be implemented. After a security audit, you may discover that your infrastructure has several weak points. Take the time to review them and fix them.

“An ounce of prevention is worth a pound of cure” – Do not follow the “action – reaction” principle. Perform a analyze of risks and eliminate (or at least, reduce) them. If will be easier (and cheaper) to implement a security control at the beginning of a project than once the application or assets used in production.

“Practice makes perfect” or “Errare humanum est” – Should we add something? We all learn by making mistakes!

“Two heads are better than one” – Do not be afraid to ask for help! First, share your issues internally and discuss with your colleagues. If more help is needed, there are plenty of ways to discuss security online via forums, mailing lists or social networks. People will be glad to help you. Don’t forget: they are no stupid questions! Follow security events and build your social network!

“Don’t put the cart before the horse” – Your security controls must be implemented in the right order. Do not implement highly-technical solutions (expensive and difficult to maintain) before applying basic security principles! Example: why deploy a WAF (“WebApplication Firewall“) if your website is not yet safe? Review the code and ask your developers to fix their bugs.

“When the cat’s away, the mice will play” – Well, people are the weakest link of the security chain. As said in the introduction, awareness trainings must be recurrent. Keep an eye on your administrators by implementing separation of duties and least access privileges.

“In too much discourse, truth is lost” – Finally, one word about the communication. In case of incident, be prepared to communicate transparently to your management, customers or partners. Do not try to hide facts. Be honest and transparent.

I’m sure they are plenty of other examples…

Xavier Mertens
ISC Handler - Freelance Security Consultant
rootshell.be
truesec.be

This cartoon by John Klossner really hit a nerve with many security professionals. It nicely illustrates how many of us see the futility of our jobs: We can buy all the greatest and latest equipment, but in the end, we are up against users clicking on links and installing software that they shouldn't. Cisco recently published a statistic that 40% of all users who hit one of the recent exploit kits landing pages are getting infected by one of the exploits delivered by the exploit kit. Brad keeps telling us about the various methods how to spot exploit kits, and how they evolve over time. In the end, any user we can keep away from an exploit kit page is a "win".

This October, like in years past, we "celebrate" cyber security awareness month. The idea is to use this month for some special security awareness activities. In the past, we used a specific theme for our diaries in October. This month, we will have a couple specific diaries about tips and tricks in awareness training. If you want to share any tips, please let us know.

Here are a couple of resources:

SANS Securing the Human: http://www.securingthehuman.org (in particular the "Ouch" newsletter)
SANS "Tip of the Day": http://www.sans.org/tip_of_the_day.php
Past CSAM Diaries: https://isc.sans.edu/tag.html?tag=2010%20cyber%20security%20awareness%20month

Phishing Tests:
http://www.sonicwall.com/furl/phishing/
https://phishingquiz.mcafee.com
https://www.opendns.com/phishing-quiz/

Information about Cyber Security Awareness Month (and links to more resources):

https://www.staysafeonline.org/ncsam/

And if you need more inspiration for your own campaign, here are more of John's security related cartoons: http://jklossner.com/computerworld/security.html

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

Introduction

The actor using gates registered through BizCN (always with privacy protection) continues using the Nuclear exploit kit (EK) to deliver malware.

My previous diary on this actor documented the actor's switch from Fiesta EK to Nuclear EK in early July 2015 [1].  Since then, the BizCN gate actor briefly switched to Neutrino EK in September 2015 [2, 3]; however, it appears to be using Nuclear EK again.

Our thanks to Paul, who submitted a pcap of traffic by the BizCN gate actor to the ISC.

Details

Paul's pcap showed us a Google search leading to the compromised website.  In the image below, you can also see Nuclear EK from zezetap.xyz.

Shown above:  A pcap of the traffic filtered by HTTP request.

No payload was found in this EK traffic, so the Windows host viewing the compromised website didn't get infected.  The Windows host from this pcap was running IE 11, and URLs for the EK traffic stop after the last two HTTP POST requests.  These URL patterns are what I've seen every time IE 11 crashes after getting hit with Nuclear EK.

A key thing to remember with the BizCN gate actor is the referer line from the landing page.  This will always show the compromised website, and it won't indicate the BizCN-registered gate that gets you there.  Paul's pcap didn't include traffic to the BizCN-registered gate, but I found a reference to it in the traffic.  Remember, traffic from this actor always has a BizCN-registered gate.

Shown above:  Flow chart for EK traffic associated with the BizCN gate actor.

How did I find the gate in this example?  First, I checked the referer on the HTTP GET request to the EK's landing page.

Shown above:  TCP stream for the HTTP GET request to the Nuclear EK landing page.

That referer should have injected script pointing to the BizCN gate URL, so I exported that referer page from the pcap and save it as a text file.

Shown above:  How to export objects from HTTP traffic in Wireshark.

Shown above:  The object I exported from the pcap.

I searched the HTML text from the compromised website and found the BizCN gate URL as shown below.

Shown above:  Malicious script in page from the compromised website pointing to URL on the BizCN-registered gate domain.

The BizCN-registered domain was perolissan.com, and pinging to it showed 136.243.25.242 as the IP address.  As usual, domains registered by this actor are privacy-protected.

Shown above:  Whois information on perolissan.com.

This completes my flow chart for the BizCN gate actor.  The domains associated from Paul's pcap were:

• www.gm-trucks.com - Compromised website
• 136.243.25.242 - perolissan.com - BizCN-registered gate
• 5.175.130.56 - zezetap.xyz - Nuclear EK

Final words

Recently, I've had hard time getting a full chain of infection traffic from the BizCN gate actor.  Paul's pcap also had this issue, because there was no payload.  However the BizCN gate actor is still active, and many of the compromised websites I've noted in previous diaries [1, 4] are still compromised. 

We continue to track the BizCN gate actor, and we'll let you know if we discover any significant changes.

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

References:

[1] https://isc.sans.edu/forums/diary/BizCN+gate+actor+changes+from+Fiesta+to+Nuclear+exploit+kit/19875/
[2] http://malware-traffic-analysis.net/2015/09/11/index.html
[3] http://malware-traffic-analysis.net/2015/09/14/index.html
[4] https://isc.sans.edu/diary/Actor+using+Fiesta+exploit+kit/19631

Introduction

Since mid-September 2015, I've generated a great deal of Nuclear exploit kit (EK) traffic after checking compromised websites.  This summer, I usually found Angler EK.  Now I'm seeing more Nuclear.

Nuclear EK has also been sending dual payloads.  I documented dual payloads at least three times last year [1, 2, 3], but I hadn't noticed it again from Nuclear EK until recently.  This time, one of the payloads appears to be ransomware.  I saw Filecoder on 2015-09-18 [4] and TeslaCrypt 2.0 on 2015-09-29 [5].  In both cases, ransomware was a component of the dual payloads from Nuclear EK.

To be clear, Nuclear EK isn't always sending two payloads, but I've noticed a dual payload trend with this recent increase in Nuclear EK traffic.

Furthermore, on Wednesday 2015-09-30, the URL pattern for Nuclear EK's landing page changed.  With that in mind, let's take a look at what's happening with Nuclear.

URL patterns

The images below show some examples of URL patterns for Nuclear EK since 2015-09-15:

Shown above: Some URLs from Nuclear EK on 2015-09-15.  Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-16.  Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-18.  Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-22.  Pcap available here.

Shown above: Some URLs from Nuclear EK on 2015-09-29.  Pcap available here.

In the above images, the initial HTTP GET request always starts with /search?q= for the landing page URL.  That changed on Wednesday 2015-09-30.

Shown above: Some URLs from Nuclear EK on 2015-09-30.

The initial HTTP GET request now starts with /url?sa= instead of /search?q= for the landing page URL.  I saw the same thing from three different examples of Nuclear EK on 2015-09-30.  Windows hosts from these examples all had the exact same configuration.

Nuclear EK examples from 2015-09-30

I had some trouble infecting a Windows 7 host running IE 11.  The browser always crashed before the EK payload was sent.  So I tried three different configurations to generate traffic for this diary.  The first run had a Windows 7 host running IE 10.  The second run had a Windows 7 host runnining IE 8.  The third run had a Windows 7 host running IE 11.  All hosts were running outdated versions of Flash player.

I found a compromised website with an injected iframe leading to Nuclear EK.  The screenshot below shows an example of the malicious script at the bottom of the page.  It's right before the closing body and HTML tags.  You'll see many empty lines before the malicious iframe.

Shown above:  Malicious code on a page from the compromised website.

The first run used IE 10 with Flash player 14.0.0.125.  After the host was infected, the following image was set as the Windows desktop background:

Shown above: Desktop background from the infected host.

Decrypt instructions were left as a text file on the desktop.  The authors behind this ransomware used decode010@gmail.com and decode1110@gmail.com as email addresses for further decryption instructions.

Shown above: Decryption instructions from the ransomware.

Playing around with the pcap in Wireshark, I got a decent representation of the traffic.  Below, you'll see the compromised website, Nuclear EK on 188.226.215.37, and some of the post infection traffic.  TLS activity on ports 443 and 9001 with random characters for the server names is Tor traffic.  Several other attempted TCP connections can be found in the pcap, but none of those were successful, and they're not shown below.  In addition to the two payloads, I found a third piece of malware on the infected host.

Shown above: Some of the infection traffic from the pcap in Wireshark (from a Windows host using IE 10 and Flash player 14.0.0.125).

Below are alerts on the infection traffic when I used tcpreplay on Security Onion with the EmergingThreats (ET) and ET Pro signature sets on 2015-09-30 at approximately 19:00 UTC.

Shown above:  Alerts from the traffic using Sguil in Security Onion.

For the second run, I infected a different Windows host running IE 8 and Flash player 11.2.202.228.  This generated Nuclear EK from from the same IP address and a slightly different domain name.  Post-infection traffic was similar; however, I did't see the same traffic that triggered Kovter.B alerts from the first run.

Shown above: Nuclear EK traffic using IE 8 and Flash player 11.2.202.228.

For the third run, I used a Windows host with IE 11 and Flash player 18.0.0.203.  As mentioned earlier, the browser would crash before the EK sent the payload, so this host didn't get infected with malware.  I tried it once with Flash player and once without Flash player, both times running an unpatched version of IE 11.  Each time, the browser crashed.  Nuclear EK was still using the same IP address, but different domain names were different.  Within a 4 minute time span on the pcap, you'll find a different top-level domain (TLD) from Nuclear EK on 188.226.215.37.

Shown above: Nuclear EK traffic using IE 11 and Flash player 18.0.0.203...  Tried twice but no payload was sent.

To get a better look at Nuclear EK, see the screen shots below from the first run.

Shown above: Nuclear EK landing page.

Shown above: Nuclear EK sends a Flash exploit.

Shown above: Nuclear EK sends the first malware payload.

Shown above: Nuclear EK sends the second malware payload.

Other than the landing page URL pattern and dual payload, Nuclear EK looks remarkably similar to the last time we reviewed it in August 2015 [6].

Preliminary malware analysis

The first and second runs generated a full infection chain and post-infection traffic.  The malware payload was the same during the first and second run.  The first run had additional malware on the infected host.  The third run using IE 11 didn't generate any malware payload.

Nuclear EK malware payload 1 of 2:

• File size:  875.7 KB ( 896,670 bytes )
• MD5 hash:  c39cc580cadffb35e486a5bea669e592
• SHA1 hash:  a7d3166a96894a5d6f250a6ff66a8f66b8b23985
• SHA256 hash:  9ccbec3dac898da303c5141b4f59224f1fd811b43e41acb96eaea86136786921
• Virus Total  -  Malwr  -  Hybrid Analysis

Nuclear EK malware payload 2 of 2:

• File size:  255.0 KB ( 261,120 bytes )
• MD5 hash:  c13a72cc4da45d8ead2f11960335c83c
• SHA1 hash:  2a9a4d644520843c7acdd734bc17942efcba7eb9
• SHA256 hash:  1408a9dcee3d73a253e1230c3bbb8b267d9c9fa3ca86c634be14de4dd8de17d2
• Virus Total  -  Malwr  -  Hybrid Analysis

Additional malware recovered from the infected host (first run only):

• File size:  298.7 KB ( 305,862 bytes )
• MD5 hash:  60aad3413e9b3fa12f518e2cf05b48b8
• SHA1 hash:  f9644fee0607465b4fb9ebd04f80684a4280fe0f
• SHA256 hash:  863d6cc2cbd99a5fd7daad97b30e92e71b7d03ca230d3d84c042a4e918355c9b
• Virus Total  -  Malwr  -  Hybrid Analysis

Final words

Like other EKs, Nuclear EK keeps evolving.  We will continue to keep an eye on the situation and let you know of any significant developments.

Packet captures of the 2015-09-30 Nuclear EK traffic are available at:

• http://malware-traffic-analysis.net/2015/09/30/2015-09-30-Nuclear-EK-traffic-first-run.pcap
• http://malware-traffic-analysis.net/2015/09/30/2015-09-30-Nuclear-EK-traffic-second-run.pcap
• http://malware-traffic-analysis.net/2015/09/30/2015-09-30-Nuclear-EK-traffic-third-run.pcap

A zip archive of the associated malware and artifacts is available at:

• http://malware-traffic-analysis.net/2015/09/30/2015-09-30-Nuclear-EK-artifacts-for-ISC-diary.zip

The zip archives are 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.malware-traffic-analysis.net/2014/05/16/index2.html
[2] http://www.malware-traffic-analysis.net/2014/05/26/index.html
[3] http://www.malware-traffic-analysis.net/2015/02/01/index.html
[4] http://www.malware-traffic-analysis.net/2015/09/18/index.html
[5] http://www.malware-traffic-analysis.net/2015/09/29/index.html 
[6] https://isc.sans.edu/forums/diary/Nuclear+EK+traffic+patterns+in+August+2015/20001/