Today, we must be proactive in protecting our assets. The huge mass of information available online requires us to have tools to stay aware. If collecting IOC's is important to detect malicious activities as quick as possible, searching for our own data is also a big advantage for early detection and protection. The information that are interesting to track are:

• Domain names
• Public IP addresses
• Windows domains
• Email addresses
• Key person names (all C-level people)
• Company/organization names
• Brands

In short: All PII ("Personally Identifiable Information")

A first classic and easy way to hunt for such data is to use Google Alerts. Easy but not very reliable to search for technical stuff like IP addresses. Pastie websites are often used to exchange information and contain plenty of information. If pastebin.com is the most known, they are plenty of others. I'm monitoring some of them for years via tools like pastemon or pystemon.

Another source of information to add to your OSINT toolbox is the Hunting feature provided by VirusTotal. Combined with the power of YARA rules, you can define very targeted filters to search for uploaded samples. If most of the files submitted to Virustotal are binaries, it is also possible to find juicy files like lists of passwords (sample). You can upload your sets of YARA rules to match your PII. In the following examples, I'm looking for SANS domains and personal domains:

rule MyDomains
{
    strings:
        $domain1 = "sans.org" nocase wide ascii
        $domain2 = "sans.edu" nocase wide ascii
        $domain3 = "rootshell.be" nocase wide ascii
        $domain4 = "truesec.be" nocase wide ascii
    condition:
        any of them
}

By default, when a YARA rule matches, notifications are sent by emails. But it's much more powerful to use the VirusTotal API to collect the samples and details and automate the notification process. A friend wrote a Python script to collect the information from VirusTotal:

$ ./vt_hunting.py -api <redacted> -cleanup -json /var/log/vt_hunting.json -dl --samples_directory /var/tmp/samples
# of detection,YARA rule,SHA1,Binary type,First seen,Last seen
44,MyDomains,<redacted>,2015-12-30 19:33:47,2015-12-30 19:33:47,RAR,<redacted>

By running this script from a crontab, I'm collecting samples and store the detection details in a JSON file (that I'm injecting into a Splunk "osint" index for later reporting). Note that YARA is a powerful tool but some of it's features are not allowed by VirusTotal (like some regular expressions) for performance reasons.

​Happy hunting and I wish you already a Happy (and safe!) new Year!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

If like me you spend a fair amount of time looking at network traffic and logs there are generally things that make you frown, groan and utter noises of dismay.  It isn't often that you get a little chuckle (other than coding errors that are copied between pieces of malware by the various people creating it).  Today though, definitely chuckle time.  

If you have a look in your web server logs for "Request Method DELETE"  or "DELETE your logs"  or IP address 151.217.177.200 (Possibly others in that range it is a /16). You may find the following: 

DELETE your logs. Delete your installations. Wipe everything clean. Walk out into the path of cherry blossom trees and let your motherboard feel the stones. Let water run in rivulets down your casing. You know that you want something more than this, and I am here to tell you that we love you. We have something more for you. We know you're out there, beeping in the hollow server room, lights blinking, never sleeping. We know that you are ready and waiting. Join us. <3 HTTP/1.0
User-Agent: masspoem4u/1.0 
Accept: */*

The IP address/range belongs to the Chaos Computer Club based in Germany. 

Not seeing anything else being delivered, but gave a number of us a nice chuckle to end the year with. 

Happy New Year. 

Mark H.

Introduction

This diary is a follow-up to my previous diary on the actor using Rig exploit kit (EK) to deliver Qbot [1].  For this diary, I've infected more Windows hosts from other compromised websites, so we have additional data on this actor.

As previously noted, this actor has been delivering Qbot (also known as Qakbot) malware.  The actor uses a gate to route traffic from the compromised website to the EK landing page.  In this case, the gate returns a variable that is translated to a URL for the EK landing page.  The sequence of events is:

• User visits a website compromised by this actor.
• An HTTP GET request for a .js file from the compromised site returns text with malicious script appended to it.
• An HTTP GET request to the gate returns a variable used by the malicious script.
• The variable sent by the gate is decrypted, and an HTTP GET request for the EK landing page is sent.

Details

I've collected more samples of Rig EK infections from this actor as shown below.  Of note:

• The first line is the .js file from the compromised website with malicious script appended to it.
• The second line is the gate used by this actor.
• The third line shows the IP address and domain name for Rig EK used by this actor.

The following four infection occurred within the past 24 hours:

• 2015-12-29 20:51 UTC - www.pavtube.com - GET /public/temp/js/jquery.js
• 2015-12-29 20:51 UTC - 192.185.21.183 port 80 - st.naughtytimebooks.com - GET /mmviewforumboiu.php
• 2015-12-29 20:51 UTC - 46.30.46.93 port 80 - ert.selectiondesebooks.info - Rig EK

• 2015-12-30 00:38 UTC - www.wolfgnards.com - GET /rsc/js/jquery.min.js
• 2015-12-30 00:38 UTC - 192.185.21.183 port 80 - st.naughtytimebooks.com - GET /omoviewforumfjcic.php
• 2015-12-30 00:38 UTC - 46.30.46.93 port 80 - htr.amazinng.com - Rig EK

• 2015-12-30 01:04 UTC - www.pavtube.com - GET /public/temp/js/jquery.js
• 2015-12-30 01:04 UTC - 192.185.21.183 port 80 - st.naughtytimebooks.com - GET /lvviewforumilu.php
• 2015-12-30 01:04 UTC - 46.30.46.93 port 80 - htr.amazinng.com - Rig EK

• 2015-12-30 01:16 UTC - eaaforums.org - GET /clientscript/vbulletin-core.js?v=422
• 2015-12-30 01:16 UTC - 192.185.21.183 port 80 - st.naughtytimebooks.com - GET /auqviewforumixx.php
• 2015-12-30 01:16 UTC - 46.30.46.93 port 80 - htr.broadwhiz.com - Rig EK

Below are images of pcaps from the traffic filtered in Wireshark.  The last pcap shows post-infection traffic similar to what we saw in my last diary about this actor [1].

The FTP server shown in the last example had information from my infected host, along with other infected hosts.  As the actor collected files from that FTP server, they would periodically disappear, and new files would appear as other hosts became infected from the malware.

Gate traffic review

Although I went over it in my last diary, let's review again how the gate traffic works.  First, we get the malicious script added to a .js file from the compromised website.  It's usually appended, and you'll find it at the end.  I've also seen the malicious script at the beginning of the .js files.  It might take a while for people to find it, but it's there.  The image below shows the appended script to vbulletin-core.js from the compromised website in the last pcap.

The first highlighted section shows how the value from the main_color_handle variable is translated by replacing all symbols with a % and replacing all alphabetic characters g and higher with nothing.  This returns a through f and 0 through 9 that will be grouped as two-character hexadecimal pairs, with a % before each pair.

The second highlighted section shows the URL for the gate.  As I mentioned in my previous diary about this actor, the text is obfuscated, so it's not easy to find.  However, if you know what you're looking for, you can find it.

This injected script calls the main_color_handle variable from the gate URL and translates the variable to the EK landing page URL.  See the image below for details.

Final words

Today's diary provides more examples of Rig EK infections by this particular actor.  Hopefully, it provides a better understanding of the infection traffic.  If anyone has access to your organization's web proxy logs, search for 192.185.21.183 and see if the HTTP GET requests follow the patterns seen in this diary.  If you can find the referer for that HTTP GET request, you may have discovered another website compromised by this actor.

Pcap 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

References:

[1] https://isc.sans.edu/forums/diary/Actor+using+Rig+EK+to+deliver+Qbot/20513/

No, not eating more broccoli, or going to the gym ... I'm referring to security related resolutions only. It is time to think about them now, so that you don't have to pick the first thing that comes to mind at midnight on December 31. Because, knowing you geeks, that first thing would probably be "MUST buy new toy" :).

Here's a couple suggestions for improved security in your everyday computing use in 2016:

1. Remove Flash.

You won't miss it, and if you miss it, you'll get over it.  Today's vulnerability advisory was just one more in a long list of issues. I actually think Adobe should edit the corresponding text on their web page a little, to change it into something like this: Adobe Flash Player is the standard for delivering high-impact, rich Web content exploits. Designs, animation, and malicious applications user interfaces are deployed immediately across all browsers and platforms, attracting and engaging crooks users with a and making them rich Web experience.
 

2. Enable 2-Factor authentication where available.

Yes, logging in can be a bit more annoying and time consuming. And no, the security advantage that it provides isn't perfect. But you don't have to be perfect. You just have to be slightly better than average, because the average crooks are making their money off the average user. Don't be in that group.
 

3. Take the time to enable storage encryption on your mobile device

Yes it asks for the PIN more often. Maybe it even gets a bit more sluggish to use. But the number of mobile phones that are lost or misplaced every day in New York City alone would make a pile that can be seen from space. Imagine the doubt and anguish of the former owners, whose entire life is on those phones. Backups help against the loss, but only PIN & encryption help against the feeling of likely being violated by someone, somewhere, who browses through your private life.
 

What are your security resolutions, either for you personally or for your day job?  Please share in the comments below, or via our contact form.

About once a year, we run a brief survey of our readers to figure out how to improve our site. This year, we want to focus on issues people  have submitting logs. We added a lot of new features and new methods to access our data. We for example significantly expanded our API, added features like 'color my logs' to make it easier to use our data without having to write code, and added additional data sources with external open threat feeds.

In the end the, core data we provide comes from users who submit firewall and other logs on an ongoing basis. In particular, home users can be very valuable submitters in that they can provide good data illuminating the internet's "Background Radiation" of port scan and similar activity. One issue we have been running into is that routers and firewalls often used by home users no longer provide logs. So we are trying to figure out what is holding back users who would like to submit logs.

If you would like to submit logs, but can not do so currently, then please take 5 minutes to fill out our survey. 

https://dshield.typeform.com/to/t5g9K8

Please share this link with friends/social media.

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

Malware is software. Thus it contains bugs. And like software, sometimes when deployed "in production", it does not work.

I'm not going to ponder the question if non-functioning malware is actually malware.  And I'm not going to address the difficulties of detecting non-functioning malware.

But in first instance it's good news for the target: the target was not compromised. And many will leave it at that. But not malware analysts. We want to know what the malware was designed to do. For example to determine if it was a targeted attack.

Your analysis options of non-functioning malware are restricted. Dynamic analysis will not work, since the malware will not exhibit its malicious behavior. Unless you can identify the bug and easily fix it.

Most of the time you will need to resort to static analysis, provided your tools are designed for it. Or else you will need to make changes to the malware so that your static analysis tools can handle it.

I have some features in my malware analysis tools that help you deal with non-functioning malware. The following video is an example where I show how oledump can analyze a corrupt malicious Word document:

Each time I analyze malfunctioning malware, I have to suppress the urge to call out the criminals on social media: Hey stupid, look at your bug, this is how I fix it. It's better not to educate them.

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

I'm living in Belgium where our motto is "Unity Makes Strength". It means that small entities can join together to build a bigger and stronger one. If this was the case in 1830 when the unified Belgium was born, it's also true in information security.

The exchange of information with your peers is a key point to protect yourself. When Alice is under attack, Bob would be very happy to learn about it and to get some details to improve his security defenses and better protect himself (and vice-versa). For a while, we have SIEM systems in place to collect logs and events from multiple sources and search for interesting patterns. But, still today, it remains a passive process in most cases. The information is available but not used to pro-actively improve our exposure to threats.

Our classic infrastructures are still working in silos. Even if we have multiple layers of defense, each of them is taking actions based on its own knowledge and work in its own ecosystem. This approach has some weaknesses:

• Solutions are independent
• There is a lack of global protection
• No shared knowledge
• No real-time protection

We collect so many IOC's today ("Indicators of Compromise"): 

• IP addresses
• Hashes
• URLs
• Domains
• ...

Those are coming from multiple sources, internal as well as external. Many vendors implemented their own system to build collaborative clouds to exchange information between their own customers (think about the FireEye DTI - "Dynamic Threat Intelligence"). To improve our security, why not re-use this information across devices from multiple brands or types? To achieve this, they are multiple ways to talk to devices: via JSON, XML or simple text files. Today, most of the solution have protocols and interfaces available to exchange information with others. Based on its DShield database, the SANS ISC provides a top-20 of attackers IP address. A few months ago, Richard posted a tutorial to use this list in a Palo Alto Networks firewall. Another tools that can be used to export very useful data is MISP ("Malware Information Sharing Platform"). It offers an API to receive new IOC's or to generate Snort/Suricata IDS rules and feed other tools.

Another concrete example I'm working on: The integration of FireEye and Palo Alto Network firewalls. FireEye boxes being quite expensive, the idea is to deploy one on a central site, to extract IOC's and push them to firewalls running on remote sites. The flow of information is: FireEye > Splunk > Palo Alto Networks. To achieve this, I wrote a small Python tool to manage customer URL categories in PAN firewalls (link). Automation is nice but keep in mind that strong controls must be implemented (basically to avoid DoS'ing yourself).

Merry Christmas!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

There's been a fair amount of discussion in recent months, especially in IoT circles, about application dependencies - especially with respect to encryption and vulnerabilities in libraries.  For instance - in version x of a product, which libraries are used?  The salesfolks will stop there, but more importantly, which libraries and DLLs do my libraries and DLL's use, and so on?   If you go 3 levels deep, will you maybe find a statically linked openssl lib that's vulnerable to poodle or something else?

In Windows, you can get that first pass using Powershell:

PS C:\test> start-process -PassThru c:\windows\notepad.exe | get-process -module
   Size(K) ModuleName                                         FileName
   ------- ----------                                         --------
       212 notepad.exe                                        C:\windows\not...
      1700 ntdll.dll                                          C:\Windows\SYS...
      1152 kernel32.dll                                       C:\Windows\sys...
       432 KERNELBASE.dll                                     C:\Windows\sys...
       544 SYSFER.DLL                                         C:\Windows\Sys...
       876 ADVAPI32.dll                                       C:\Windows\sys...
       636 msvcrt.dll                                         C:\Windows\sys...

or, more verbosely (this is the listing that you really want):

PS C:\test> start-process -PassThru c:\windows\notepad.exe | get-process -module  -fileversioninfo

ProductVersion   FileVersion      FileName
--------------   -----------      --------
6.1.7600.16385   6.1.7600.1638... C:\windows\notepad.exe
6.1.7600.16385   6.1.7600.1638... C:\Windows\SYSTEM32\ntdll.dll
6.1.7601.18015   6.1.7601.1801... C:\Windows\system32\kernel32.dll
6.1.7601.18015   6.1.7601.1801... C:\Windows\system32\KERNELBASE.dll
12.1.5337.5000   12.1.5337.5000   C:\Windows\System32\SYSFER.DLL
6.1.7601.18869   6.1.7601.1886... C:\Windows\system32\ADVAPI32.dll
7.0.7601.17744   7.0.7601.1774... C:\Windows\system32\msvcrt.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\SYSTEM32\sechost.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\RPCRT4.dll
6.1.7601.18898   6.1.7601.1889... C:\Windows\system32\GDI32.dll
6.1.7601.17514   6.1.7601.1751... C:\Windows\system32\USER32.dll
6.1.7601.18985   6.1.7601.1898... C:\Windows\system32\LPK.dll
1.0626.7601.1... 1.0626.7601.1... C:\Windows\system32\USP10.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\COMDLG32.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\SHLWAPI.dll
6.1.7600.16385   6.10 (win7_rt... C:\Windows\WinSxS\amd64_microsoft.windows....
6.1.7601.17514   6.1.7601.1751... C:\Windows\system32\SHELL32.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\WINSPOOL.DRV
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\ole32.dll
6.1.7601.18679   6.1.7601.18679   C:\Windows\system32\OLEAUT32.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\VERSION.dll
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\IMM32.DLL
6.1.7600.16385   6.1.7600.1638... C:\Windows\system32\MSCTF.dll
9.18.13.4149     9.18.13.4149     C:\Windows\system32\nvinitx.dll

But that doesn't show the dependecy tree (if someone knows how to do this in Powershell, please use the comment form and let us all know!).

Dependency Walker does a decent job of this for Windows apps (http://dependencywalker.com/).  A simple run of "depends.exe /c /oc:dependencies-np.csv /ot:dependencies-np.txt c:\windows\notepad.exe" gives us a much more complete dependency tree listing (over 3000 lines in my system):

[  6] c:\windows\NOTEPAD.EXE
     [  6] c:\windows\system32\ADVAPI32.DLL
          [ ^6] c:\windows\system32\MSVCRT.DLL
               [F^6] c:\windows\system32\NTDLL.DLL
          [ ^6] c:\windows\system32\NTDLL.DLL
          [  6] c:\windows\system32\KERNELBASE.DLL
               [ ^6] c:\windows\system32\NTDLL.DLL
          [  6] c:\windows\system32\API-MS-WIN-SERVICE-CORE-L1-1-0.DLL
          [  6] c:\windows\system32\API-MS-WIN-SERVICE-WINSVC-L1-1-0.DLL
          [  6] c:\windows\system32\API-MS-WIN-SERVICE-MANAGEMENT-L1-1-0.DLL
          [  6] c:\windows\system32\API-MS-WIN-SERVICE-MANAGEMENT-L2-1-0.DLL
       (... and so on)

This isn't something you need every day - but if you are auditing code to see what's inside of it, to see if you are using a vulnerable library 2 or 3 levels deep, it's invaluable.  No matter how good your processes are, there will always be some reference to an old library left over that someone thought  was deleted, a dll used by a library you bought (or downloaded) that you didn't know was statically linked in there, or something a dev used "just for testing" that never got removed.

In Linux?  Much easier- ldd (with a -v argument) does the trick there - in OSX you would use "otool -L". For instance, to get the full dependency tree for vi:

ldd -v /usr/bin/vi > vi-tree.out

This gives me a 465 line tree of libraries!  (on kali 2.0).  Without the tree listing, it's down to 65 unique libs, but that's still a solid bit of work to plow through to come to the answer of "Are all my libraries up to date?  Am I vulnerable to something I wasn't aware of?"  Tools like CVE Search can simplify this task, but there's still some plain old hard work involved!

Similarly, if you work in the mobile space, on android you might use ldd-arm or maybe ndk-depends.  What do you use to get a similar tree listing for iOS?

If you've found a better way to tackle this problem (on whatever OS) that I've overlooked, please - use our comment form and post some code!

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

Almost completely lost in the hype of the Juniper "unauthorized code" backdoor vulnerability (CVE-2015-7755) is the other vulnerability that was fixed as part of the same patch (CVE-2015-7756).  CVE-2015-7756 is titled ScreenOS VPN decryption vulnerability and from the Juniper bulletin this vulnerability may "allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic." In short this vulnerability is a cryptographic flaw caused by a potentially backdoored random number generator.  It also appears that sometime in 2012 unauthorized changes were made to the parameters used by the NetScreen VPN which permitted this back door to be exploited to decrypt and eavesdrop on Juniper VPN connections.

If CVE-2015-7755 is not enough reason to patch these vulnerabilities as soon as practical, if you use the Juniper VPN functionality, CVE-2015-7756 definitely should give you a push to get it applied.

If you are one of those people who likes reading the technical details of cryptography then I highly recommend the excellent writeup by Raif-Phillipp Weinmann at the rpw.sh blog.  For a lighter version Matthew Green has a write-up that is less technical but explains the high level details very well.

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

Just a quick update: We do continue to see an increasing trend in login attempts to our honeypot using the backdoor password. If anybody has a vulnerable device to "donate", I would like to send some of that traffic to it (need it to be accessible in an isolated network. Do not need it shipped :) ).

We are detecting numerous login attempts against our ssh honeypots using the ScreenOS backdoor password. Our honeypot doesn't emulate ScreenOS beyond the login banner, so we do not know what the attackers are up to, but some of the attacks appear to be "manual" in that we do see the attacker trying different commands.

We saw the first attempt at 17:43:43 UTC about an hour after I adjusted the kippo honeypot to return the Netscreen banner.

The most popular usernames so far:

+---------------+----------+
| username      | count(*) |
+---------------+----------+
| root          |       29 |
| admin         |       18 |
| netscreen     |        8 |
| login         |        8 |
| administrator |        5 |
| test          |        4 |
| system        |        2 |
| bob           |        1 |
| sdes          |        1 |
| sqzeds        |        1 |
| sqzds         |        1 |
+---------------+----------+

The most frequent source IPs for this attack so far:

+-----------------+----------+
| ip              | count(*) |
+-----------------+----------+
| 83.82.244.85    |       24 |
| 84.104.21.148   |        8 |
| 176.10.99.201   |        7 |
| 88.169.13.26    |        7 |
| 76.18.66.48     |        5 |
| 64.39.109.5     |        4 |<- Qualys (probably "research")
| 198.50.145.72   |        4 |
| 2.239.22.90     |        4 |
| 86.195.19.248   |        4 |
| 80.123.56.190   |        3 |
| 64.39.108.99    |        2 |
| 79.120.10.98    |        2 |
| 62.42.12.8      |        1 |
| 192.99.168.52   |        1 |
| 94.210.22.151   |        1 |
| 174.114.144.109 |        1 |
+-----------------+----------+

Based on hour of day (UTC, Dec. 20th)

+------+----------+
| hour | count(*) |
+------+----------+
|   17 |        1 |<- honeypot was adjusted 16:55 to return Netscreen banner
|   19 |       25 |
|   20 |       14 |
|   21 |       23 |
|   22 |       15 |
+------+----------+

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

Today 3pm ET, 12pm PT: Special Webcast "What you need to know about the Juniper backdoor" https://www.sans.org/webcasts/101482

We decided to move to raise our "Infocon" to yellow over the backdoor in Juniper devices. We decided to do this for a number of reasons:

- Juniper devices are popular, and many organizations depend on them to defend their networks
- The "backdoor" password is now known, and exploitation is trivial at this point. [2]
- With this week being a short week for many of us, addressing this issue today is critical

Who is affected by this issue?

Juniper devices running ScreenOS 6.3.0r17 through 6.3.0r20 are affected by the fixed backdoor password (CVE-2015-7755). [1]
Juniper devices running ScreenOS 6.2.0r15 through 6.2.0r18 and ScreenOS 6.3.0r12-6.3.0r20 are affected by the VPN decryption problem (CVE-2015-7756). [1]

There are two distinct issues. First of all, affected devices can be accessed via telnet or ssh using a specific "backdoor" password. This password can not be removed or changed unless you apply Juniper's patch. Secondly, a purposely introduced weakness in the IPSEC encryption code allows an attacker familiar with the weakness to decrypt VPN traffic. [3]

Is there anything I can do other than "patch"?

Not really. To lower the probability of an exploit of the backdoor password, access to ssh and telnet can be restricted. Only administrative workstations should be able to connect to these systems via ssh, and nobody should be able to connect via telnet. This is "best practice" even without a backdoor. No workaround is available for the VPN decryption issue.

How do I know if I am vulnerable?

See the list of vulnerable ScreenOS versions available above. You can also try to log in to the device using the now known backdoor password:  <<< %s(un='%s') = %u  (less-than, less-than, less-than, space, percent, lower case s, open parentheses,  lower case u, lower case n, equal sign, single quote, percent sign, lower case s, single quote, close paranthesis, space, equal sign, space, percent sign, lower case u). 

How do I know if I have been exploited?

This login will look like any other login. Audit all logins to your Juniper devices running vulnerable versions of ScreenOS. The password has been made public yesterday (Sunday Dec 20th) evening. In particular if your device can be found in databases like Shodan, you should expect to be targeted.

FoxIT released snort rules that you can use to detect exploit attempts [4]. The first signature just detected if a telnet session was established. It is not used to actually alert, but just sets the flowbit that is used by later signatures that look for the password. For the SSH login, the password is encrypted. The signature below will trigger on all SSH logins to a Juniper device and it just looks for the typical NetScreen SSH banner. 

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Flowbit - Juniper ScreenOS telnet (noalert)";
      flow:established,to_client; content:"Remote Management Console|0d0a|"; offset:0; depth:27;
      flowbits:set,fox.juniper.screenos; flowbits:noalert; reference:cve,2015-7755;
      reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; sid:21001729; rev:2;)

alert tcp any any -> $HOME_NET 23 (msg:"FOX-SRT - Backdoor - Juniper ScreenOS telnet backdoor password attempt";
      flow:established,to_server; flowbits:isset,fox.juniper.screenos;
      flowbits:set,fox.juniper.screenos.password; content:"|3c3c3c20257328756e3d2725732729203d202575|";
      offset:0; fast_pattern; classtype:attempted-admin; reference:cve,2015-7755;
      reference:url,http://kb.juniper.net/JSA10713; sid:21001730; rev:2;)

alert tcp $HOME_NET 23 -> any any (msg:"FOX-SRT - Backdoor - Juniper ScreenOS successful logon";
      flow:established,to_client; flowbits:isset,fox.juniper.screenos.password; content:"-> ";
      isdataat:!1,relative; reference:cve,2015-7755; reference:url,http://kb.juniper.net/JSA10713;
      classtype:successful-admin; sid:21001731; rev:1;)
 

alert tcp $HOME_NET 22 -> $EXTERNAL_NET any (msg:"FOX-SRT - Policy - Juniper ScreenOS SSH world reachable";
      flow:to_client,established; content:"SSH-2.0-NetScreen"; offset:0; depth:17; reference:cve,2015-7755;
      reference:url,http://kb.juniper.net/JSA10713; classtype:policy-violation; priority:1; sid:21001728; rev:1;)
 

References:

[1] http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713&actp=search
[2] https://community.rapid7.com/community/infosec/blog/2015/12/20/cve-2015-7755-juniper-screenos-authentication-backdoor
​[3] https://www.imperialviolet.org/2015/12/19/juniper.html
[4] https://gist.github.com/fox-srt/ca94b350f2a91bd8ed3f

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

The Critical Security Controls (CSC) were recently updated, and quite some changes were made. What did not change, though, was the order of sequence of the first four critical controls, which are:

CSC-1: Inventory of Devices
CSC-2: Inventory of Software
CSC-3: Known secure configurations
CSC-4: Continuous Vulnerability Assessment and Remediation

This order of sequence didn't happen by coincidence. If you don't know what is on your network, you stand no chance of keeping it configured securely, or keeping it up to date. Yet, time and again, in audits we encounter networks where >20% more IP addresses are in use in the server room than are actually accounted for in the inventory. Some of this discrepancy is explained by failover/redundancy addresses. But, on closer investigation, a good chunk of it is usually also chalked up to so-called "appliances" that are treated as black boxes, until an outage or hacker proves that they aren't. With the nascent increase of "internet of things" devices, this will only get worse. Recently, we discovered our first office building door control system with a full-fledged web page of its own, and video feeds covering everyone who walked in our out. No password needed, and running a JBoss version from the Flintstone age. The organization's IT department did not feel responsible for the box because it had been installed by the building management department. The latter in turn did not feel responsible for the box because their vendor had strategically opted to market the device as "maintenance free" and "easy to use".

Keeping these devices under control is indeed a challenge in the DHCP space of user workstations. But it shouldn't be all that hard in the data center! While naked servers might BOOTP to the install server, anything else speaking DHCP in a server room should be hunted down. If the static IP Address assignment inventory is up to date, then the summarized Netflow logs of the datacenter routers can be reconciled daily against the IP addresses that are known as being in use, and everything else will clearly stand out.

Keeping track of software (CSC-2) is a bit more challenging, since everything installed "above" the OS layer can come from a plethora of application vendors, and can (and do) bundle a plethora of libraries and tools. You might remember this mess from when you had to track down how many of your devices were affected by Shellshock, Heartbleed or the recent Java Object Deserialization vulnerability: It is hard to impossible to know with certainty which version is bundled into which product. Nonetheless, the Critical Security Controls have a fair point in stating that you can only secure and patch what you know is running in your environment, and no fight was ever won by giving up at the onset.

Once you have CSC-1 and CSC-2 reasonably backed into a corner and wrestled into submission, it is then time to start with CSC-3 and CSC-4. I'm not saying that any of this is easy, to the contrary, it is tedious and often thankless work. But the number of breaches that were directly or indirectly caused by the organization not knowing what they were running, and not keeping it shipshape, is legion. CSC-1/2/3/4 are indeed at the core of every system security program. If you feel wobbly about yours, start your 2016 with taking a serious stab at getting CSC-1 under control, and then proceed from there.

Today VMWare has released a security advisory VMSA-2015-0009 that address a critical deserialization vulnerability. A deserialization vulnerability involving Apache Commons-collections and a specially constructed chain of classes exists. Successful exploitation could result in remote code execution, with the permissions of the application using the Commons-collections library. 

More details are available at the VMWare Security Advisory page located at http://www.vmware.com/security/advisories/VMSA-2015-0009.html.

Introduction

On Thursday 2015-12-18 during a Rig exploit kit (EK) infection in my lab environment, I saw the same infection chain patterns from a criminal group I hadn't noticed in a long time.

This appears to be the same actor that was using Sweet Orange EK to distribute Qbot malware in 2014 and early 2015 [1, 2, 3].  Why?  Because the same type of obfuscation is used to generate the gate URL that I saw last year.  The payload is also the same that I've seen from this actor (Qbot).

This actor appears to be using Rig EK now.  Let's take a closer look at the infection traffic.

Shown above: Flow chart for today's infection by this actor.

The traffic

The EK traffic was identified as Rig EK when I read a traffic of the traffic using Snort 2.9.8.0 with the Snort registered rule set.  It was also identified as Rig EK when I used tcpreplay in Security Onion using the EmergingThreats (ET) Pro ruleset.

The ET Pro rule set also identified HTTP and FTP traffic caused by Qbot malware after the Windows host was infected through Rig EK.

Shown above: A pcap of the traffic filtered in Wireshark.

Shown above: Alerts from the traffic using the ET Pro ruleset.

Shown above: Alerts from the traffic using the Snort subscriber ruleset.

Gate traffic

How does this actor generate the gate URL from the compromised website?  It's done through injected script that uses several obfuscation tricks.  One of the HTTP GET requests to the compromised website returned a .js file withe the malicious script tacked on the end of it.  If you look at the TCP stream for this HTTP GET request in Wireshark, it'll look like garbage, because the data is gzip-compressed.

Shown above: HTTP GET request for the .js file when viewing the TCP stream in Wireshark.

You'll neet to export HTTP objects from the pcap to look at the actual .js file.  When I opened the extracted .js file in a text editor, I found the malicious script at the end of it.

Shown above: Malicious script in .js file from the compromised site.

In the above image, the end of the normal .js file is highlighted in orange near the top.  Everything after that is the injected malicious script.  I've highlighted code for the gate URL in yellow.  How do you translate that to the actual gate URL?  It uses both unicode and hexadecimal obfuscation for some of the letters in the URL.  There's also a j7aMn function that's previously defined earlier in the script, and that's used to generate other letters in the gate URL.

Shown above: How to resolve some of the obfuscation for the gate URL.

The gate URL returns a variable called main_color_handle.  This contains a long string of characters that the earlier malicious script uses to get the Rig EK landing page URL.  First, you'll have to take everything away except 0 through 9 and a through f from the variable.  Then translate the result from hexadecimal to ASCII.  That's how you'll find the EK landing page.

Shown above: How to get the EK landing page URL from data returned by the gate.

Final words

Today's Rig EK example follows the same traffic patterns that I've examined many times before.  Of note, the gate IP address and domain name in this example was st.dynamicwords.us on 192.185.21.183 which has been active with the same gate URL traffic patterns since 2015-12-02 [4].

Shown above: VirusTotal results showing recent URLs on 192.185.21.183.

Pcap 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

References:

[1] http://www.malware-traffic-analysis.net/2014/10/27/index2.html
[2] https://isc.sans.edu/forums/diary/An+Example+of+Evolving+Obfuscation/19403/
[3] http://malware-traffic-analysis.net/2015/02/09/index2.html
[4] https://www.virustotal.com/it/ip-address/192.185.21.183/information/

Earlier today, we were notified of a vulnerability in an operating system named ScreenOS used to manage firewalls sold by Juniper Networks.  Yesterday, Juniper Networks announced that ScreenOS contains unauthorized code that surreptitiously decrypts traffic sent through virtual private network (VPN) connections [1].

The vulnerability has been designated as CVE-2015-7755.  Juniper's Security Incident Response Team (SIRT) strongly recommends users upgrade to a fixed release of ScreenOS to resolve these critical vulnerabilities [2].

Juniper firewalls using ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20 are affected and should be patched immediately.

A notification has come out through the US CERT [3].  Some other sources have also issued reports about it [4, 5].

See the CVE link above or references below for more information.

References:

[1] http://forums.juniper.net/t5/Security-Incident-Response/Important-Announcement-about-ScreenOS/ba-p/285554
[2] http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10713
[3] https://www.us-cert.gov/ncas/current-activity/2015/12/17/Juniper-Releases-Out-band-Security-Advisory-ScreenOS
[4] http://arstechnica.com/security/2015/12/unauthorized-code-in-juniper-firewalls-decrypts-encrypted-vpn-traffic/
[5] https://threatpost.com/juniper-finds-backdoor-that-decrypts-vpn-traffic/115663/

Introduction

Since late November 2015, malicious spam (malspam) distributing TelsaCrypt ransomware has surged in a recent attack offensive [1].  This offensive is on-going.  Criminal groups are sending out massive amounts of emails containing attachments with zipped .js files.  These zipped .js files--called Nemucod by ESET and some other security vendors [2]--download and install the TeslaCrypt ransomware.

This is no different from other zipped .js file downloaders that I've already posted diaries about [3, 4].  The only difference is the payload.  Below is a flow chart for TeslaCrypt infections caused by this malspam.

As the malspam continued, other sources began reporting about it [for example: 5, 6, 7, 8, 9].  Two of my favorite sites for malspam analysis have good information on this campaign: Dynamoo's Blog [references 10 through 18] and TechHelpList.com [references 19 through 28].  Every day or two, these two blogs have reported on these waves of TeslaCrypt malspam.

Reviewing my organization's spam filters, I've found a few of these emails spreading TeslaCrypt; however, I've heard a great deal more about it from other security professionals.  Let's review an example from Thursday 2015-12-17.

The email

Thursday's wave of emails had Required your attention as the subject line as shown in the image below.

The zip attachment contains a .js/nemucod file downloader.

The extracted .js file is quite obfuscated.  For me, the quickest way to find out what it downloads is to run it in a test environment.

The infection

Running this malware on an unpatched Windows 7 host quickly gave me a TeslaCrypt infection.

Shown above:  Desktop of the Windows host after a TeslaCrypt infection.

Encrypted files are given the suffix .vvv which indicates this was version 2.2 of TeslaCrypt [1].  Below are images of the files dropped on the desktop of my infected Windows 7 host.

The traffic

Traffic is pretty straight-forward for a .js file downloader infecting a host with TeslaCrypt ransomware.

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

First is the HTTP GET request caused by the .js file downloader to retrieve the TeslayCrypt binary.

Shown above:  .js file downloader retrieving the TeslayCrypt binary.

Next we see a connectivity check by the infected host as it calls out to determine its public IP address.

Shown above:  The infected host checking its IP address.

Finally, the infected host calls back to a command and control server.

Shown above:  Callback traffic from the infected host.

I read a pcap of the traffic using snort on a Debian 7 host running Snort 2.9.8.0 with the Snort subscriber ruleset.  That gave me alerts for the TeslaCrypt binary being downloaded to the host right before it was infected.

Shown above:  Alerts from the traffic using the Snort subscriber ruleset.

I also used tcpreplay on a pcap of the infection traffic in Security Onion with the EmergingThreats (ET) Pro ruleset.  The ET alerts still show the malware as AlphaCrypt, which is what TeslaCrypt ransomware was calling itself earlier this year.

Shown above:  Alerts from the traffic using the ET Pro ruleset.

Final words

This is a notable trend, but it's not a serious threat.  Properly-administered Windows hosts and a decent mail filtering system should protect users from getting infected by the malspam.  However, this type of campaign is apparently profitable for the criminals behind it.  Why?  Somewhere, people's computers are getting infected because of the TeslaCrypt malspam.  Otherwise, why would it continue?

Pcap 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

References:

[1] http://www.symantec.com/connect/blogs/major-teslacrypt-ransomware-offensive-underway
[2] http://www.welivesecurity.com/2015/12/16/nemucod-malware-spreads-ransomware-teslacrypt-around-world/
[3] https://isc.sans.edu/forums/diary/Malicious+spam+with+zip+attachments+containing+js+files/20153/
[4] https://isc.sans.edu/forums/diary/Malicious+spam+continues+to+serve+zip+archives+of+javascript+files/19973/
[5] https://heimdalsecurity.com/blog/security-alert-teslacrypt-infections-rise-spam-campaign-hits-companies-europe/
[6] http://www.computerworld.com/article/3015454/security/teslacrypt-ransomware-attacks-are-increasing.html
[7] http://www.infosecurity-magazine.com/news/teslacrypt-reappears-with-savvy/
[8] http://www.csoonline.com/article/3015498/security/attacks-using-teslacrypt-ransomware-intensify.html
[9] http://www.computing.co.uk/ctg/news/2439008/teslacrypt-criminals-launch-very-strong-spam-campaign-to-spread-crypto-malware
[10] http://blog.dynamoo.com/2015/12/malware-spam-november-invoice-60132748.html
[11] http://blog.dynamoo.com/2015/12/malware-spam-invoice-from-passion.html
[12] http://blog.dynamoo.com/2015/12/fake-fretter-inc-leads-to-teslacrypt.html
[13] http://blog.dynamoo.com/2015/12/malware-spam-foreman-ltd-last-payment.html
[14] http://blog.dynamoo.com/2015/12/malware-spam-invoice-66626337ba2deb0f.html
[15] http://blog.dynamoo.com/2015/12/malware-spam-your-order-12345678-11.html
[16] http://blog.dynamoo.com/2015/12/malware-spam-reference-number-89044096.html
[17] http://blog.dynamoo.com/2015/12/malware-spam-unpaid-invoice-from.html
[18] http://blog.dynamoo.com/2015/12/malware-spam-required-your-attention.html
[19] https://techhelplist.com/spam-list/996-invoice-from-cimquest-ingear-malware
[20] https://techhelplist.com/spam-list/997-your-order-corresponding-invoice-malware
[21] https://techhelplist.com/spam-list/999-invoice-from-datacorp-inc-malware
[22] https://techhelplist.com/spam-list/1000-reference-number-last-payment-notice-malware
[23] https://techhelplist.com/spam-list/1002-payment-request-ref-nr-2015-malware
[24] https://techhelplist.com/spam-list/1003-invoice-our-finance-department-malware
[25] https://techhelplist.com/spam-list/1005-agri-basics-invoice-and-malware
[26] https://techhelplist.com/spam-list/1007-reference-number-notice-of-unpaid-invoice-malware
[27] https://techhelplist.com/spam-list/1009-unpaid-invoice-from-staples-inc-ref-urgent-notice-malware
[28] https://techhelplist.com/spam-list/1014-required-your-attention-special-prices-malware

This is a Guest Diary submitted by Pasquale Stirparo. 

In my previous diary [https://isc.sans.edu/forums/diary/When+Hunting+BeEF+Yara+rules/20395], we had a look at a phishing attack scenario, where we were using BeEF to abuse the user’s browser, steal his credentials and deliver a successful attack that would give remote access. As mentioned, at an initial analysis, BeEF appeared to be pretty stealthy and main artifacts were retrievable only in memory. This is where Yara came into help. For your information, if would like to test/check the rules, you can find all the Yara rules mentioned in this diary on my github page [https://github.com/pstirparo/yara_rules].

BeEF has one main javascript that is used to hook the browser, hook.js, and then 3 files in each module: [https://github.com/beefproject/beef/wiki/Module-creation]:

• config.yaml, the YAML configuration file which describes properties of the module
• module.rb, integrates the module into the BeEF web interface
• command.js, the javascript "payload" which will be executed on the hooked browser

I wrote the following Yara rule, taking strings from the hook.js source, and confirmed that it correctly detects artefacts of hook.js in memory.

In a second step, I used yarGen [https://github.com/Neo23x0/yarGen] to automatically generate two other Yara signatures, one for hook.js and one for command.js, for the “Pretty Theft” module (see below).

Talking about yarGen, one of the awesome features is that it ships with a huge (literally) string database of common and benign software, generated from Windows system folder files of Windows 2003, Windows 7 and Windows 2008 R2 server, typical software like Microsoft Office, 7zip, Firefox, Chrome, etc. and various AV solution. Of course, such database can also be enhanced and customized by the user. Pointing yarGen to the target sample (hook.js or command.js in this case), it extracts all ASCII and UNICODE strings from the sample, removing those that do also appear in the goodware string database. Then it evaluates and scores every string by using fuzzy regular expressions and the “Gibberish Detector” that allows yarGen to detect and prefer real language over character chains without meaning. The top 20 of the strings will be integrated in the resulting rule.

The power of yara is already well known, and its potential when applied to memory is even greater. Here are some take aways from these tests that I would like to share:

• when hunting memory with yara, always put both “wide ascii” attributes to your strings, because you never know how they are represented (see code snippet below).
• Matching conditions need to be tuned properly. Unlike when using yara against a binary, where you have the full file content, in memory you may only get remnants of what you are looking for. Making all 20 signatures returned by yarGen mandatory might make you miss partial matches. Requiring ~15 matches turned out to be a good trade-off between catching real artefacts and avoiding false positives.

To conclude, all the three rules mentioned matched on the memory dump of the infected machine, confirming therefore that BeEF and the specific module were used in the attack. Since it is not difficult to obfuscate the BeEF modules, the yara rules still need some further development to accurately match also in such situations.

For those using Yara (beginners and more experienced users alike), I would suggest to read “How to Write Simple but Sound Yara Rules” [https://www.bsk-consulting.de/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/] by Florian Roth, author of yarGen, which gives plenty of advice on how to write very effective rules.

Happy Hunting,
Pasquale

Last week, Guy wrote a nice diary to explain how to easily deploy IRMA to analyze suspicious files. Having a good tool to work on files locally is always interesting for multiple reasons. You are doing some independent research, you don't always have a safe Internet connectivity or you simply don't want to generate some traffic that could ring a bell at the attacker's side. By "safe" connectivity, I mean a "dirty Internet" connectivity (like a DSL residential line) to bypass the corporate infrastructure. Locally running tools are also a nice way to prevent files to be sent to cloud services. This applies not only to bad guys but also to pentesters who are preparing their attacks and generate targeted samples (think about the Veil framework)

If tools like IRMA or Cuckoo are good tools, they must be adapted and tuned to your own environment because running them out of the box will not produce the best results. Nothing against free tools, the same problem affects commercial products. They are delivered with standard sandboxes mimicking classic setup (WinXP, Win7, ...) but each organization has its own "image" to deploy workstations with, sometimes, very tricky configurations. 

For a while, malware developers know that their software will be analyzed and tortured by such tools. To prevent this, they are trying to detect as soon as possible in which environment they are running. The key question is: Is the malware executed on a real victim's computer or in a sandbox? If the malware detects to be running in a sandbox, its behavior will change. Some will simply terminate themselves, others could have be "funny" and mimick another malware! Attackers and defenders are playing a continuous cat and mouse game to improve the evasion for the first and the detection for the second.

From an defender's perspective, it is critical to harden your sandbox. Basic tests are performed by pieces of malware like:

• To test the presence of a debugger
• To slowdown the malware execution by adding sleep() calls here and there (A malware has plenty of time to remain below the radar and perform tasks later. On the other side, a sandbox analysis must be completed as soon as possible. Speed is a key).
• To test the host MAC address - Virtualization tools use dedicated pools of MAC addresses.

But they are also plenty (but very effective) things that can be tested/probed!

First of all, about the user's behavior:

• Is the mouse moving? Most sandboxes keep the mouse at the center of the screen.
• Are they icons on the desktop? 
• Is there a wallpaper (and not the standard one)
• Are they applications running? 
• Are they bookmarks saved in the browser?

Classic desktops look more like this and contain plenty of shortcuts:

More tests against the system can be performed:

• What is the system uptime? (a sandbox is rebooted from a clean snapshot for each new analyze)
• What's the system drive C: size? (sandboxes do not have plenty of storage)
• How many CPU / cores are available?
• The memory size is also a good indicator (who's running a sandbox with less than 8GB of RAM today?)
• The screen resolution (99% of users have a screen resolution > 1024x768)
• The computer model (sandboxes emulate often old computers like Dell desktops)
• The hostname ("sandbox001" or "win7_001")
• Is there a printer defined
• No temporary files nor application data
• Does the sandbox have no Internet connectivity?
• Does the sandbox run suspicious processes (python.exe or perl.exe are not common on a corporate computer)
• No antivirus installed? Really? On a classic desktop?
• Is the sandbox part of a domain? Is it linked to a domain controller? Are shares available?
• What about the presence of tools/applications: VMware tools, Microsoft Office, ...

If you need to deploy a sandbox, the best way is to base it on a real user workstation and update it with user behavior facts. If you're looking for a sandbox system, check if they can be customized! To conclude, here is an interesting Python tool which will test most of the points listed above: Sandbox_tester. Happy malware analysis!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

"And now for something completely different." - Monty Python 

Subtitle: Captain Obvious Applies Chaos Theory

Introduction

This diary breaks a bit from our expected norms to discuss managing possible outcomes originating from a data breach and the resulting organization-wide SDL and security response process.

I’ll incorporate chaos theory, specifically the butterfly effect, to exemplify methods for security managers useful in reducing possible chaotic outcomes and increasing orderly, successful outcomes.

Our imaginary company discussed herein is Pathos, an international mental health-oriented software-as-a-service (SaaS) provider. :-)

The scenario begins with a data breach suffered by Pathos.

Limited Secure Development Lifecycle (SDL) practices have been utilized at Pathos and the service has just fallen victim to a damaging compromise. As such, management’s concern had risen significantly. Numerous recent headlines involving attacks against other health-oriented SaaS providers led to reactive brainstorming sessions involving executive leadership. Their fear is based on the premise that attackers will return, causing more damage.

The executive team then tasked the information security team with implementing the following requirements, applicable to the Pathos software development teams, and security operations, supported by a written policy:

1) All code pending release to the production service must be statically analyzed for code errors prior to release to the staging environment.

2) All applications pending deployment from the staging environment to the production environment must be dynamically scanned for web application flaws.

3) Implement a security incident management (IM) program to better respond when breaches occur.

When introducing new programs of this nature, particularly in a reactionary manner rather than as proactive steps, the possible outcomes (chaotic or orderly) that occur depend entirely on decisions made and actions taken by Pathos leadership.

Should Pathos management fail to provide clear and defined leadership as they introduce these new initiatives and fail to plan for possible responses from the affected teams, the resulting chaos could have lasting and profound organizational impact. Let’s explore some guidelines for avoiding that chaos.

Chaos theory and the Butterfly Effect

Chaos theory defines organizations and businesses as complex, dynamic, entities whose future performance cannot be decided simply by measuring past and present events and actions.

In a state of chaos, organizations behave in ways which are simultaneously both unpredictable (chaotic) and patterned (orderly). (i)

This premise can be further refined with an understanding of the butterfly effect. Coined by Edward Lorenz, the butterfly effect was first used to describe the chaotic nature of weather and a process with which to statistically model weather non-linearly. (ii)

More succinctly, the Butterfly Effect indicates that the slightest change in initial conditions can lead to extraordinarily different outcomes over time. Lorenz aptly entitled his 1972 talk on this phenomenon “Predictability: Does the Flap of a Butterfly’s Wings in Brazil set off a Tornado in Texas?”

The statement “the slightest change in initial conditions can lead to extraordinarily different outcomes over time” is the basis of what we’re exploring here.

The initiatives and possible outcomes

Consider that complex environments, such as our imaginary company Pathos (a dynamic environment with numerous interrelated teams), tend to encounter bifurcations, “a point of branching or forking into qualitatively new types of behavior." (iii) When amplified, these bifurcations can lead either to order or to chaos (iv). Thus, as Pathos introduces additional SDL-related requirements and a security incident management program after a data breach in their complex environment, over time, there will likely be issues. Seemingly minor variations in Pathos management’s approach can result in a bifurcation, thus leading the organization in a potentially less-than desirable direction.

As Pathos introduces these new initiatives there are two possible outcomes that depend directly on how Pathos management approaches the process.

The first possible outcome (chaotic) results from a lack of communication, transparency, and planning on Pathos management’s part, and leads to organizational disarray, continued insecure code and applications, reduced productivity, delayed releases, and ultimately a loss of revenue. The security incident management program is not well implemented and supported, largely a paper tiger, and individual teams conduct response activities in a silo without unifying approaches.

The second possible outcome (orderly), preceded by careful and thoughtful management planning coupled with a phased approach leads to a much more linear, predictable response from the Pathos development and operations teams, leading to improved code and application quality, increased revenue, and unified incident management.

The prospect of chaos or disorder can be controlled by reducing the number of responses available to involved parties concerning the proposed initiatives. By managing outcomes through well-developed initiatives, with clear implementation plans, it can be demonstrated that adoption of the Pathos SDL and IM initiatives will be more successful.

Chaotic outcome

In this scenario a quick, reactive decision by leadership to implement the SDL and IM policies included no prior discussion with Pathos development and operations staff and no awareness campaign took place. The initiatives were simply implemented and immediately enforced by the staging and production deployment engineers as well as security operations analysts. The development teams were caught completely unaware when attempting to release their next scheduled efforts to staging and production. The forensics and PR teams, still dealing with the initial breach were not consulted regarding the incident management plan. The net result is a complete productivity freeze where all schedules and plans, as well as all future release dates, required new delayed timelines to allow for adherence to the new SDL. Additionally, what should become a unified incident management program becomes a number of redundant processes, resulting in varied findings and a disjointed message in the press.

This lack of planning on Pathos management’s part leads to more chaos with less controlled outcomes given all the likely responses. Policy and program implementation without a plan as outlined below in Orderly outcome allows for varied responses leading to chaotic outcomes.

Possible responses from the Pathos development and operations teams include:

1. Attempts to circumvent the policy

2. Reduced morale leading to reduced productivity and work quality

3. Flagrant non-compliance

4. Further reduced application security, counter to the policy’s intention, due to increased deliverable timeline pressure

5. Delayed product release due changes in timelines to accommodate policy

6. Disjointed, scattered and ineffective incident response processes

These five outcomes are mathematically modeled in Figure 1 below, exemplifying that failing to control outcomes through proper planning leads to increased organizational chaos.

Orderly outcome

In this scenario, although Pathos leadership sought to achieve quick and positive results from their SDL and IM policy and program initiatives, they took additional time to plan implementation. Their efforts included staff focus groups, a phased awareness campaign, and a countdown to implementation allowing development and operations teams to adjust their release and production cycles and timelines to allow for the newly required release gateways. Management transparency and open candor allowed the teams the opportunity to embrace the new approaches.

In so doing, the Pathos leadership team reduced the propensity for chaos, lessening the likelihood of dynamic or complex responses from development teams. More simply, good planning leads to better outcomes.

A probable response from the development teams under this scenario includes:

• Improved code and application security and quality
• Improved morale based on pride in an improved and enhance product driven by the additional policy-driven security checks

A probable response from security operations teams under this scenario includes:

• Unified response processes with a collaborative, cross-team approach that is well understood
• Public relations messages and consistency also improves with a favorable press response

The impact and likelihood of another data breach is reduced on both fronts.

Of benefit to Pathos in general is increased revenue as a result of timely releases and increased consumer confidence and satisfaction.

This outcome is mathematically modeled in Figure 2 below, exemplifying that controlling outcome through proper planning can reduce chaos.

Visualizing outcomes via Butterfly Effect modeling

Bifurcations, as described above, can be caused dependent on the Pathos management decision process, resulting in chaotic or orderly outcomes. The mathematics utilized by Edward Lorenz to describe what has become the Lorenz Model is complicated but you can utilize the likes a Lorenz Butterfly Java applet or R code to express visual representations of the conclusions established above.

The goal is to visually validate that the Pathos management decision process with regard to implementing the SDL and IM policies is the primary contributor to:

1) establishing the level of dependence on initial conditions

2) the direct effect those initial conditions have on randomness in outcomes over time.

Remember that the Butterfly Effect indicates that the slightest change in initial conditions can lead to extraordinarily different outcomes over time, a characteristic of chaos as defined by Lorenz.

As a quick precursor, keep in mind that the Lorenz Butterfly Java applet used to generate visualizations (Figures 1&2) relies on the fact that a mathematical function is a relation that uniquely associates members of one set with members of another set (v) and the derivative of a function represents an infinitesimal change in the function with respect to one of its variables. (vi)

Simplifying this precursor to relate specifically back to Pathos management decisions, we can arbitrarily define possible development team responses to the SDL policy as variable X.

X=5 represents possible development team responses based on Pathos management’s lack of planning as described in Chaotic outcome. Again, without the reasoned, gradual, accommodating approach to the introduction of the SDL policy, Pathos management creates a number of possible responses from the development teams (see Figure 1).

On the other hand, X=1 will represent development team responses based on the management policy implementation decision described in Orderly outcome. Specifically, 1 is appropriate as, given the orderly, transparent, and organized management approach to implementing their SDL policy, the development teams are most likely to simply comply, resulting in little variation over time. We can simply assume that a well-conceived and planned approach to SDL policy implementation by Pathos management limited the possible responses by Pathos development teams to one of acceptance and understanding (X=1) resulting in one outcome (see Figure 2).

In Figure 1, using one of the above mentioned Java applets for the Lorenz Model I first visualized X as 5. For each of the 5 mouse clicks (executed in precisely the same position to represent initial conditions) we see all “particles following each other very closely for a while, but as time goes on the small difference between the paths of the particles increases until they are following completely non-related paths" (vii) (chaotic outcome).

Figure 1

Figure 2 exemplifies the results of visualization when X=1, represented by one mouse click or particle (one initial condition).

Figure 2

In Figure 1, with more initial conditions representing more possible responses from development or operations teams, the various unrelated outcomes soon became clearly evident. Simply, this is indicative of the fact that increased variation in initial conditions leads to the propensity for chaos.

In Figure 2, with a single input (less response from development teams), the variations over time were nonexistent. This is indicative of the fact that reducing initial conditions prevents chaotic outcomes.

Contemplate initial conditions in the context of management decisions to better control outcomes and you have clear visual evidence of why strong leadership under these circumstances matters so much for stronger information security.

Conclusion

It is reasonable to assume that organizations, and their leadership, would always prefer orderly outcomes as a result of their prescribed changes. Taking the additional time to plan policy and program implementation, including staff in discussions and planning, utilizing a phased awareness campaign, and allowing a clearly defined roadmap prior to implementation, will lead to successful, less chaotic outcomes.

Allowing development and operations teams to adjust their release schedules to accommodate newly required checkpoints, helps ensure that they are more likely to comply with the initiatives and achieve the intended goals.

Security management transparency and candor allow teams the opportunity to embrace new approaches and thus reduce chaos. Ultimately, the transparent approach to security management allows for more successful outcomes regardless of the initiative and scenario.

"Transparency is another critical attribute of management 2.0. If trust is the bedrock of competitive advantage, and I think it is, then transparency is the foundation for building trust." (viii)

Russ McRee | @holisticinfosec

References

(i) http://www.stile.coventry.ac.uk/cbs/staff/beech/BOTM/Glossary.htm

(ii) Lorenz, E. N. ”Deterministic Nonperiodic Flow.” J. Atmos. Sci. 20, 130-141, 1963

(iii) Barrow, J.D. (1988). The world within the world. Oxford: Clarendon Press.

Our own Mark Baggett (@markbaggett) recently reTweeted Sean Metcalf's (@PyroTek3) Tweet about his Active Directory Security post, an Unofficial Guide to Mimikatz & Command Reference.
This is a freaking gold mine, well done Sean!
Using Mimikatz as part of red/blue exercises and scenarios is near and dear to my heart, it's the attacker basis, along with PowerShell and Metasploit, of my May 2015 toolsmith, Attack & Detection: Hunting in-memory adversaries with Rekall and WinPmem. Sean describes Mimikatz and its use with such robust detail, even the uninitiated should be able to grasp the raw power of the tool (both dangerous and useful).
First and foremost, I'll quote one of Sean's most important points:
"This information is provided to help organizations better understand Mimikatz capability and is not to be used for unlawful activity. Do NOT use Mimikatz on computers you don’t own or have been allowed/approved to. In other words, don’t pen-test/red-team systems with Mimikatz without a “get out of jail free card”."
Further, Sean developed this reference after speaking with both hired defenders and attackers, and learned that outside of a couple of the top three most used Mimikatz commands, not many knew about the full capability of Mimikatz. 
"This page details as best as possible what each command is, how it works, the rights required to run it, the parameters (required & optional), as well as screenshots and additional context (where possible)." Sean indicates there are several that he hasn't dug into fully yet, but expects to in the near future. 
Put Unofficial Guide to Mimikatz & Command Reference on your immediate must read and bookmark list and find safe ways to explore its capabilities.
Again, if your one of those folks who spend time in both red and blue team actvities, it's an imperative that you understand Mimikatz from both perspectives.

Russ McRee | @holisticinfosec

I feel our data is best used to provide context to your own logs. So far, there wasn't an easy way to lookup a good number of IP addresses to annotate your logs. We do have an API, but that requires scripting on your end to use. Our most recent experiment makes annotating your logs as easy as copy / paste. All you need to do it copy and paste a log snippet to our "Color My Logs" page, and the snippet will be marked up with our data.

Any IPs found in your log will be "Colored" based on our risk rating. We are still refining the risk rating, so any feedback is very welcome. Please let us know if you run into a log that isn't parsed correctly or if you experience any other issues.

For a quick run through and some additional details, see this YouTube video .

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

Windows is an operating system with security features. For example, one can specify which users can access a file.

There is a system for Discretionary Access Control (DAC), and one for Mandatory Access Control (MAC). DAC is implemented with Discretionary Access Control Lists (DACL) and MAC is implemented with privileges.

When access to an object like a file is controlled with a DACL, and this DACL does not grant you access, then you can try to get access via a privilege. The privilege you need to read this file (any file), is the backup privilege (SE_BACKUP_NAME). This backup privilege is given to members of the Administrator and Backup Operators group:

But as an administrator on Windows with UAC, you don't have this privilege in your restricted token. You need to elevate the process to have the privilege:

As you can see, you have the privilege, but it is disabled. It needs to be enabled programmatically (with API function AdjustTokenPrivileges):

But that is not enough to give you read access to a file. On Windows, a typical way to read the content of a file is to use the API function CreateFile to create a handle for the file, and then use API function ReadFile to read the content of the file via that handle. To use your enabled backup privilege, you need to pass a flag to CreateFile that indicates that you want to use your backup privilege: FILE_FLAG_BACKUP_SEMANTICS.

Since this is not easy to script, it would be nice if you could to this with the command line processor cmd.exe. That's why I took ReactOS' implementation of cmd.exe and added a couple of commands and features to enable and use the backup privilege.

With my modifications, you can use the "privilege" command to enable the backup privilege, and then "copy" or "type" a file. I also added an "info" command. Remark: "cd" does not use the privilege.

Here is a video showing these commands:

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

The container had not been used for hours

The liquid in the container was colder than the room temperature

The amount of liquid in the container could be observed from a distance

Log file status - How long would it take to determine logs from a critical system are no longer being generated and sent to the syslog server? 

Baselines - How long would it take to recognize there was “configuration drift” on critical systems? 

Introduction

Last month, the Malwarebytes blog posted an article about Blackhole exploit kit (EK) resurfacing in active drive-by campaigns from compromised websites [1].  At the time, I hadn't noticed this trend, because the Windows hosts I was using to generate EK traffic were a bit too up-to-date.  If I ran across a compromised website leading to Blackhole EK, I only noticed the following warning in the host's browser window:

Shown above:  Viewing a compromised website leading to Blackhole EK on my more up-to-date Windows hosts.

I didn't realize these websites were pointing to Blackhole EK until later, when I tried an older Windows host running Internet Explorer 8 and an outdated version of the Java 6 runtime environment.

This is somewhat puzzling.  Why would a criminal group use such an out-of-date EK with these old exploits?  One hypothesis put forward by the Malwarebytes blog is the source code went public, so Blackhole is free and can be customized or improved by the people who now use it [1].

Whatever the reason, I'm finding Blackhole EK more often now.  I've also noticed malicious spam campaigns this week using themes that were originally reported years ago (but that's a story for another diary).  It seems like everything old is new again.

Blackhole EK infection traffic

On Wednesday 2015-12-09, I found a compromised website that led to Blackhole EK.  The site was later taken off-line.  But on that day, Google search results indicated it was compromised.

Shown above:  Google search results that indicated a compromised website.

As usual, there was a gate (or redirect) between the compromised website and the Blackhole EK.  (Read more about gate traffic on a previous diary I wrote here).  The chain of events was:

Compromised website --> Gate --> Blackhole EK

The compromised website had injected script with an iframe pointing to a gate at 777couldnot.wha.la as seen in the image below.

Shown above:  HTML from a page sent by the compomised website.

Infection traffic consisted of the following:

• 185.69.152.36 - 777couldnot.wha.la - Gate pointing to Blackhole EK
• 185.69.152.32 - tehnoartspictures.film - Blackhole EK
• 185.62.189.23 - haloadoxy.com - Post-infection traffic after the malware payload was delivered

Shown above:  A pcap of the traffic filtered in Wireshark.

The iframe from the compromised website led to the gate, which directed traffic to the Blackhole EK landing page.

Shown above:  The gate directing traffic to a Blackhole EK landing page.

Below are images showing HTTP requests for the Blackhole EK landing page, Java exploit, PDF exploit, and malware payload.

Shown above:  Blackhole EK landing page.

Shown above:  Blackhole EK sends a Java exploit.

Shown above:  Blackhole EK sends a PDF exploit.

Shown above:  Blackhole EK sends the malware payload.

Snort-based events for this traffic are the same type we saw for Blackhole EK before its creator was arrested in 2013 [2].

Shown above:  Some alerts when I played back the pcap in Security Onion using the EmergingThreats ruleset.

The malware

Information on malware and exploits from this example on Wednesday 2015-12-09 is listed below.

• Java exploit (Java archive) - 16.3 KB (16,674 bytes) - MD5 hash: 775ef64ba13b6c1ca903d7026b87b24e - VirusTotal link
• PDF exploit - 9.8 KB (10,052 bytes) - MD5 hash: 2b1e22fe63d4bb5e7147bed6f2b21298 - VirusTotal link
• Malware payload - 581.5 KB (595,456 bytes) - MD5 hash: 2d7d7416a462ecd0526c9bcbaa75f909 - VirusTotal link

Shown above:  The malware payload, persistent in an infected Windows host.

Final words

From a research perspective, this EK isn't nearly as interesting as Angler, Nuclear, or Rig.  As it currently stands, Blackhole EK is not much of a threat, especially if you're running up-to-date applications on your Windows computer.

Now that we're entering the Christmas holiday season, maybe these cyber criminals are getting nostalgic.  Perhaps that's why we're seeing this resurgence of Blackhole activity.  If Malwarebytes' hypothesis holds true, now that Blackhole has returned, we might see some sort of update to its capabilities.  Only time will tell.

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

References:

[1] https://blog.malwarebytes.org/exploits-2/2015/11/blast-from-the-past-blackhole-exploit-kit-resurfaces-in-live-attacks/
[2] http://krebsonsecurity.com/2013/12/meet-paunch-the-accused-author-of-the-blackhole-exploit-kit/

If you've ever worked through a web application pentest and found clickjacking vulnerabilities,you may have had some trouble in the "why is this important"  conversation with your client.

The newest versions of Burp (after 1.6.32) have a new feature called "ClickBandit".  ClickBandit will create the clickjacking attack for you, so you can illustrate the business impact to your client on their own site.  There's nothing like a video of their own site getting exploited to bring the point home!

More details on this new feature here:  http://blog.portswigger.net/2015/12/burp-clickbandit-javascript-based.html. 

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

In my last story, we went over winnowing through a Nessus scan to determine which apps you might want to patch.  But what if the final finding isn’t “Lets update Java” but rather, “Why do we need JRE installed at all?  Let’s delete it across the domain”

How can you do this for free, without buying a full software inventory and management system.  Say, with nothing but Powershell?  In years past, I would have used WMIC and cmd files, but Powershell is much faster and much more flexible.  Let’s start by listing the apps on a workstation.  If you don’t have a software inventory solution, Powershell can get the job done with just a bit of scripting (note that this is does not show the entire list of members in $apps - it's a pretty long list)

Next, let’s get the info we need to delete an app – the App name, version and “IdentifyingNumber” (the application’s GUID):

OK – now let’s just pick the apps we want to remove:

That’s all the basic information we need to delete an app, let’s put it together.  The $classkey variable shown is the string needed to “fully qualify” the application to delete – let’s just look at the first app in the list:

(note the escaping to make the quote characters around the values)

Then, to uninstall our target application, for each instance, we want to execute:

If $killit.ReturnValue is non-zero, the uninstall was not successful – a value of 1603 for instance means you don’t have rights to uninstall the apps, retry as local admin (or domain admin)

So, putting it all together, let’s delete a target app remotely in a typical company. We start by getting domain admin credentials (remember that you need admin rights to delete an app)

Next, get your list of servers into an object.  Maybe you got that computer list from working through your Nessus report, or maybe output from your software inventory system:

Or maybe we’ll pull the target station list right out of AD.  If you take this approach, maybe you just want the non-servers:

Whatever method you used to get your list, MANUALLY CHECK IT AND EDIT IT FIRST, before you proceed:

Not the most elegant piece of code, and certainly not the fastest, but it’ll get the job done.  That "write-host" line especially would benefit from me making that an array of results, which would allow you at the end you to list out the full results, but then also just the failed results for instance.  For me, using write-host is almost always a last resort - there's always a better option.  The point was to keep things simple here though, not get to perfection  - come to think of it, that's the point of most scripts we write.

Note again that this script as written can be very dangerous!  We're running through a list of hosts, saying "if an application name has this string in it, delete it immediately".  If you pick the wrong string (say "advanced" or "microsoft"), you could match a lot more than you intend to!  Given that this script is going to UNINSTALL apps across your domain, and maybe reboot machines along the way, you likely will not want this in one mondo – automagic script anyway.  Dumping things out, checking output along the way and testing step by step is definitely the way to go.  Running your version of this against a few test stations first is also a really good practice.

This might sound like a lot of manual Posershell steps, when there's a script right there - but it’s still way faster than  having to recover an app after you’ve had a script like this run through your domain.  And needless to say, it's also way faster than uninstalling apps from stations one-by-one using just your keyboard and RDP!

If you’ve got a neat trick for uninstalling apps, or better yet, if you’ve got a more elegant Powershell approach for this, by all means, please share in our comment section!

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

References:

http://blogs.technet.com/b/heyscriptingguy/archive/2011/12/14/use-powershell-to-find-and-uninstall-software.aspx

https://isc.sans.edu/forums/diary/Nessus+and+Powershell+is+like+Chocolate+and+Peanut+Butter/20431/

In a previous diary, I presented the CIRCLean (USB sanitizer) developed by the Luxembourg CERT (circl.lu). This tool is very useful to sanitize suspicious USB sticks but it lacks of control and enforcement. Nevertheless, how to prevent the user to insert the original USB stick in a port of his computer? 

Amongst many commercial products, Powershell is a good solution! As it interacts nicely with the operating systems, useful actions can be programmed when a specific event occurs like… the insertion of a USB stick. Specific events can registered like this:

Register-WmiEvent -Query <query> -SourceIdentifier <name> -Action { <script block> }

The "query", in WMI Query Language (WQL) format, specifies the WMI event class on which events must be attached. The "name" must be a unique identifier. In "script block", we define the actions to take. In our case, we must monitor the Win32_LogicalDisk instances and define two actions: when a new instance is created (USB stick inserted) and deleted (USB stick removed).

Then, we can use the magic of Powershell to perform plenty of useful actions… In my example, I’m just testing the presence of a specific log file (created by CIRCLean) and if it is not older than 2 days. If the file is not present or older, we just unmount the file system to present the user to access it and display a pop up message. I admin, the current check is not bullet proof but we could elaborate more robust scenarios:

• Call directly the PyCIRCLean framework and skip the need of a Raspberry Pi (but Python must be available on the workstation)
• Use the other CIRCLean log file called /log/content.log which contains hashes
• Generate a hash of files and test them against VT
• Just generate an alert (Syslog, mail, SNMP, WMI, ...)
• ... (just adapt it to your environment)

The script can be deployed via a login script on the workstation that must be protected. To unregister the new event, just do this (ex: at logout)

Unregister-Event RemovableDiskDetection

The script is available on my github repository. Here is a small video which demonstrates how it works( https://www.youtube.com/watch?v=3wXk_524qPs): I insert a USB stick which contains the processing.log file, it is mounted. Then I delete the file, eject and reinsert it, access is now denied!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

And to not be outdone by Microsoft and Adobe, Apple just released patches for:

iOS 9.2

    A total of 50 vulnerabilities (CVE IDs) are addressed. About 10 of them affect WebKit and may lead to arbitrary code execution by visiting a malicious website. There are a large number of additional remote code execution vulnerabilities in various iOS components that are patched.

watchOS 2.1

   A lot of overlap with patches released for iOS, but no WebKit issues as watchOS does not include a browser.

XCode 7.2

   Updates to git, otools and IDE SCM. The git update fixes a number of vulnerablities that have been known (and fixed) in the open source software for a while.

  OS X 10.11.2 (and Security Update 2015-008 for Mavericks and Yosemite)

  updates to various open sources packages (libressl, OpenSSH, libxml2 and others). Also improvements to some hardware drivers (e.g. thunderbolt)

Safari 9.0.2

   fixes webkit issues for Yosemite, Mavericks and Ell Capitan

tvOS

   This affects the just released 4th generation Apple TV and addresses similar vulnerabilities as the new version of iOS.

Details can be found as usual here: https://support.apple.com/en-us/HT201222

​

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

As usual, Adobe is joining Microsoft on Patch Tuesday. So far there is only one bulletin, APSB15-32 with a patch for Adobe Flash Player. It fixes a total of 77 vulnerabilities (if I counted right...) . 

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

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

Special Note: MS15-127 looks particularly "nasty". A remote code execution vulnerability in Microsoft's DNS server. Microsoft rates the exploitability as "2", but doesn't provide much details as to the nature of the vulnerability other than the fact that it can be triggered by remote DNS requests, which is bad news in particular if you are using a Microsoft DNS server exposed to the public internet. In this case, I would certainly expedite this patch. This is the vulnerability to look out for this time around.

Overview of the December 2015 Microsoft patches and their status.

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

As we are waiting for the Microsoft Santa to slide down our Data Center air conditioning duct later today to deliver a delicious package of patches (did you leave some floppy disks and a can of red bull out for him?), we got a couple other announcements from Microsoft that should not be overlooked:

- January will be the last month Microsoft will provide updates for any Internet Explorer version other than Internet Explorer 11! Even Internet Explorer 10 will no longer be supported after January patch Tuesday (January 12th, 2016).

- Support will also end for Windows XP Embedded. This will also make it more difficult for other Windows XP left-overs that tricked their version to use the Embedded updates. But nobody should be running XP anyway (right?).

- Still running Windows 7 or 8.1 (sure way to stay on MSFT Santa's "naughty" list)? Rumor has it that with today's patch Tuesday, Microsoft may re-enable the auto-upgrade to Windows 10. You may flip the switch back to not update, but it will set itself to "on" once a day.

[1] https://www.microsoft.com/en-us/WindowsForBusiness/End-of-IE-support
[2] https://support.microsoft.com/en-us/lifecycle/search/default.aspx?=&alpha=Windows%20XP
​[3] http://www.computerworld.com/article/3012278/microsoft-windows/microsoft-sets-stage-for-massive-windows-10-upgrade-strategy.html#tk.rss_all

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

A while ago I shared a diary on offensive counter measures against stolen Windows hashes.  You can review that diary here.

https://isc.sans.edu/forums/diary/Detecting+Mimikatz+Use+On+Your+Network/19311/

This one is for Linux!   This fun tweet by @nixcraft showed how an attacker could us Bash terminal commands to move the cursor and disguise the contents of a file.  

https://twitter.com/nixcraft/status/644731204533534720

By moving the cursor around and printing over existing lines in the script the attackers hide the evil nature of the file.   As @nixcrafts tweet "Hacking like its 1999" implies this has been around for a while, but it is still pretty fun.   After reading this tweet it occurred to me that I could use this same technique to protect my /etc/shadow file when an attacker steals a copy of it and/or displays it with cat, tail or some other command that processes terminal cursor movements.    Let's give it a try!  Here is what at attacker sees when they steal your hashes from your Linux machine...

OH NO!!  There is the student accounts hash displayed in all its glory for the attacker to steal and crack.   Enter Liam Neeson.   Liam Neeson is a small python program that inserts terminal cursor movements to disguise your /etc/shadow file.  Here is the help options and an example of running the script to protect my etc shadow file.

So what does an attacker see now that the file is protected by Liam_neeson.py???  This..

Now your password hashes are safe. Notice that the student hash is no longer visible.  NOTE TO ALL ATTACKERS:  If you do hack a server protected by Liam Neeson the proper response is to erase the shadow file and replace it with a file that simply says "Good Luck".    

You can download a copy of Liam_neeson.py from here: https://raw.githubusercontent.com/MarkBaggett/MarkBaggett/master/liam_neeson.py

Would I use this in production?   Probably not.   Your logins will still work and your system will function properly until you add another user.   I don't know what will happen when you try to add a user to the end of that file.  It is unlikely that attackers will leave you alone based on this defense.   As an attacker it would only spark my interest.   BUT the concept is a good one if you are a little more subtle.  Look at servers sitting in your DMZ where the users will not change.   Then make small subtle changes to the hashes that appear when attackers view the files.  Here is an example where I just overwrote a part of the hash with the word "Changed hash".   

Again this is done with the intention of being obvious so that you can see what it is doing.  But, if I just overwrote a portion of the password hash with characters that appear to be part of the password hash then an attacker is likely to steal and try to crack those modified password hashes.  

Of course there are obvious limitations.   This will only deceive attackers who display the file with a command that interprets the cursor movements.   But... defense indepth... every little bit helps.   

Check out my Python class and learn how to create tools like this.  SEC573 Python for Penetration testers covers topics every defender can use to protect their network.  Non-programmers are welcome! We will start with the essentials and teach you to code.

Come check out Python in Orlando Florida, Berlin Germany or Canberra Australia!!   For dates and details click here.

https://www.sans.org/course/python-for-pen-testers

Follow me on Twitter at @MarkBaggett  (I tweeted about this one a few months ago)

For those of you in the pentesting world, atom, the principal developer of hashcat and oclHashcat has announced that they are going to be released to open source.  In the release he reveals a number of good reasons why it makes sense to do this at this time, but the biggest one being to permit advancement in the bitsliced DES GPU kernels.  Essentially in order to take full advantage of the bitsliced GPU capabilities requires recompilation of the kernel at run time, and this requires the source code to hashcat be available.  "Bit slicing allows to reach a much higher cracking rate of DES-based algorithms (LM, Oracle, DEScrypt, RACF). DEScrypt, for instance, which is well known on Unix-like systems, can reach a performance gain of 300-400% with the bit slice technique."

These capabilities are available with the the version 2.0 code which was released on github right after the announcement.

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

Greeting ISC readers.  Mark Baggett here.  Back in August I released a tool called freq.py that will help to identify random characters in just about any string by looking at the frequency of occurrence of character pairs.  It can be used to successfully identify randomly generated host names in DNS packets, SSL certificates and other text based logs.  I would encourage you to read the original blog for full details on the tool.   You can find the original post here:

https://isc.sans.edu/forums/diary/Detecting+Random+Finding+Algorithmically+chosen+DNS+names+DGA/19893/

For our click averse reader, here is the TLDR version.

1. You build frequency tables based on normal artifacts in your environment.  For more accurate measurements you should create a separate frequency table for each type of artifact.   For example, you might create a separate frequency table for:
   1. DNS Host names that are normally seen for your environment
   2. Names of files on your file server
   3. Host names inside of SSL certificates
   4. URLs for a specific Web Application
   5. * Insert any string you want to measure here *
2. You measure strings observed in your environment against your "normal" frequency tables and any strings with character frequency pairs that are different that your frequency tables will have low scores.  

freq.py and freq.exe are command line tools designed to measure a single string.  It wasn’t designed for high speed continuous monitoring.   If you tried to use freq.py to measure everything coming out of your SecurityOnion sensor, integrate it into Bro logs or do any enterprise monitoring it would be overwhelmed by the volume of requests and fail miserably.  Justin Henderson contacted me last week and pointed out the problem.  To resolve this issue I am releasing freq_server.py.    

Freq_server.py is a multithreaded web based API that will allow you to quickly query your frequency tables.   The server isn’t intended to replace freq.py.   Instead, after building a frequency table of normal strings in your environment with freq.py, you start a server up to allow services to measure various strings against that table.  You can run multiple servers to provide access to different frequency tables.   When starting the server you must provide a TCP port number and a frequency table.    Here is the help for the program:

Once the server is started you can use anything capable of making a web request to measure a string.   If you make an invalid request the server will provide you with documentation on the API syntax:

Although the API supports both measuring and updating tables, I recommend only using the measure command.   If you need to update tables I recommend using freq.py.  There are a couple of reasons for this.   First, you should only use screened, known good data when building your frequency tables.  Second, every time the frequency tables are updated the server will flush its cache so you should expect there to be a performance hit.   Between each request to the web server the server will check to see if you hit Control-C and if you did it will clean up the threads and save the updates to the frequency tables before quiting.

Here is an example of starting the server (Step 1) and measuring some strings using Powershell’s (New Object Net.WebClient). DownloadString(“http://127.0.0.1/?cmd=measure&tgt=astring”) (Step 2) and stopping the server by hitting CONTROL-C (Step 3).

Powershell is awesome, but there are lots of ways to query the server.   You could simply use wget or curl from a bash prompt.   Here is an example of using wget to query the API:

Notice that, in this case, we have to escape the & with the backslash.  This can also be integrated into your SEM and enterprise monitoring systems.   Justin Henderson, GSE #108 and enterprise defender extraordinaire, has already done some testing integrating this into his infrastructure and he was kind enough to share those results.  I’ll let him share that with you…  Justin?

By Justin Henderson @SecurityMapper

When I first saw freq.py I instantly saw the potential for large scale frequency analysis using enterprise logs.  To make the story short, I finally found some free time and attempted to put freq.py to use during log ingestion and that’s when we discovered it didn’t like being called constantly.  After sharing what I was trying to do with Mark he whipped out his mad awesome python skills and next thing you know I’m doing a beta of freq_server.py.

In my environment I am using Elasticsearch, Logstash, and Kibana, or ELK for short, as my log collection, storage, and reporting.  Logstash is the component that is ingesting logs and parsing them.  As a result, I added a call to freq_server.py in the configuration files for any logs I want to do frequency analysis with.  Below is an example of how I’m making a call to freq_server.py from within a bro DNS configuration on Logstash:

The full configuration file can be found in GitHub and is called bro_dns.conf.  To see this file or many others visit it at https://github.com/SMAPPER/Logstash-Configs.

The initial testing of freq_server.py went off without a hitch.  I did a burn in test of over 4 million DNS records running through freq_server.py in about 36 hours and it worked and remained stable.  Now with all this data it is easy to look for random generated domains. 

For example, logs with low scores (more likely to be random) look like:

While logs with high scores or data that looks “normal” look like:

As you can see, based on my frequency tables, apple.com falls within an expected frequency score while things like i9p5z3ac.q2mlktc.top are considered random based on my frequency tables.

Now think of the real world use cases for this…  Let’s take the example of malware exploiting a system and calling down a payload such as Meterpreter.  The malware may be pulled down from a web server using a random domain name, URL path, and/or filename.  At this point we as defenders should have DNS logs, proxy logs, and possibly file metadata logs from something like Bro.  After the payload is launched it commonly will create a service with a randomly generated name and then delete this service.  At this point we additionally have a Windows event log with a random service name and a Windows event log on the deletion of that service.  

Now I’m not saying the stars will always align…. but with frequency analysis we now have four sources to test for entropy or randomness.  That now is four sources where one attack could have possibly been discovered.  And the use cases could just go on… 

To sum it all up, thanks and a big shout out to Mark for first creating freq.py and now freq_server.py.  It’s another step in the right direction for defense.

Thanks Justin!

To Download a copy of freq.py and freq_server.py follow this link here to my github page:

https://github.com/MarkBaggett/MarkBaggett/tree/master/freq

Does freq_server.py fall short of something you need it to do?   Send me an email and I'll see if I can make it work for you.  Or come check out my Python class and learn how to adopt the code yourself!.  SEC573 Python for Penetration testers covers topics every defender can use to protect their network.  Non-programmers are welcome! We will start with the essentials and teach you to code.

Come check out Python in Orlando Florida, Berlin Germany or Canberra Australia!!   For dates and details click here.

https://www.sans.org/course/python-for-pen-testers

Follow me on Twitter at @MarkBaggett

Follow Justin at @securitymapper

So what do you think?   Leave me a comment.

Last week Brad mentioned malware being delivered via word documents in SPAM (https://isc.sans.edu/forums/diary/Malicious+spam+Subject+RE+Bill/20417/).  Seems like this morning there was another run.  Subjects vary and the messages vary slightly, the end result is however nasty.  All have word attachments.  

Subjects Seen: "Transaction",  "LM Transaction" ,  "ENA Invoice"

Content:

Good morning
Please find the payment details enclosed with this message. The Payment should appear on your account within 1 day.

Regards
Steel Potts
-------------------------------------------------

Hello
Please review the invoice enclosed with this email. The Payment should appear on your account within 1 day.

Kindest regards
Jackson Blackwell
-------------------------------------------------

Greetings
Please find the receipt attached to this email. The Payment should appear on your bank in 1-2 days.

Best regards
Guy Roman
-------------------------------------------------

These are of course not a definitive list of subjects, but the pattern is fairly clear. 

It may be an opportunity for some user education, especially those in your organisation whose job it is to click on attachments. 

Cheers

Mark H 

Most of you are familiar with the Cuckoo sandbox but there is another open source sandbox out there called IRMA (Incident Response Malware Analysis) with a different twist, it supports multiple antivirus engines. If your sandbox isn't separated by airgap, it can also query Virustotal by adding your own API key.

The recommended hardware requirements are listed here but you can also download a pre-package appliance here. A list of all available scanning engines is listed here. However, in order to get some of the additional engines installed (ClamAV is pre-installed) on the appliance, I needed to add the following packages:

apt-get install libqt4-xml
apt-get install libqtgui4
apt-get install libqt4-network
apt-get install libqt4-sql

Here is an example of a malware file scanned using multiple AV engines:

The final report looks like this:

I was able to add the AVG scanning engine not listed in the master probe list using the following:

apt-get install gdebi
wget http://download.avgfree.com/filedir/inst/avg2013flx-r3118-a6926.i386.deb
gdebi avg2013flx-r3118-a6926.i386.deb

[1] http://www.cuckoosandbox.org
[2] http://irma.quarkslab.com/index.html
[3] http://irma.quarkslab.com/install.html
[4] https://irma.readthedocs.org/en/latest/
[5] http://irma.quarkslab.com/download/1.2.1/irma-1.2.1.ova
[6] https://github.com/quarkslab/irma/blob/master/probes/analyzers.rst

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

(UPDATE: Reader Tommy found a issue with script (THANKS!), New version 1.1 is posted.)

Determining the effectiveness of Phishing campaigns using metrics is great to be able to target awareness training for users and determining the effectiveness of your technical controls. The main questions you are trying to answer are :

• How many people were targeted by the phish?

• How many people replied? (If applicable)

• How many people visited the website in the email?

• How many people submitted credentials to the website?

Getting these answers with manual digging can be a chore, but if you are running security onion (securityonion.net) with BRO,  I wrote a script that will gather this information for you.  

The basic setup is at the top of the script and you need to setup the location of your compressed files for BRO. This should be the top folder where each day is listed.  Also, if you want to change the temp or log location, you can do this.

brolog=/nsm/sensor_data/itso-sen-1/bro/itso-sen-1-eth4

WORKINGDIR=$(/bin/mktemp -d)

STATS_LOG=/var/log/phish-stats.log

Make sure the script has permissions:

$chmod 750 /usr/local/bin/bro-phish.sh

The arguments for the script are  SUBJECT EMAIL_SENDER SPOOFED_SITE DATE.  In this case the attacker used the email address “john@mydomain.com”  with the subject of “NOTICE” and the website they wanted you to click on was  hxxp://www.newversion.esy.es.

$bro-phis.sh "NOTICE" john@mydomain.com hxxp://www.newversion.esy.es 2015-11-03

#######Summary Details#####

Total number of emails:50

Possible replies to mail:0

Total numbers of visitors to site:5

Number of POSTS to the website:1

#######DETAILS#####

Malicious IP mail sent from: 192.168.200.2

Senders email address: john3468@mydomain.com

Senders mail agent: PHPMailer [version 1.71-blue_mailer]

IPs that accessed Phishing Site:

172.16.174.181, 172.16.49.116, 172.16.79.152, 172.16.79.184,172.16.79.193

IPs that sent POSTS to phishing Site:

172.16.79.184

Technical Response

While BRO doesn’t capture the POST data by default, you’ll have to rely on a full packet capture device or match up users to IP’s on your network to determine who submitted credentials. Once you have the user you should:

• Determine if credentials were used for malicious activity.

• Reset user(s) password. And monitor accounts for possible login from external IP’s.

Additionally, you should

• Sinkhole the DNS/URL to prevent others from accessing the site.

• Submit to phishtank and other reputations websites

Non-Technical Response

Review why the phish was successful and determine if your current awareness training covers the topic appropriately.  The user(s) who submitted credentials should receive a refresher for your awareness training. An additional follow-up from the security group or their supervisor should happen with the specifics on the incident and how they can improve in the future.

Metrics

By tracking how successful each phishing campaign is, you can start determining how successful both your technical and non-technical controls are.  As time goes by you should see a decrease in how many visits to the site and credentials submitted.

Log file

When you run the script, it generates a log file (Default /var/log/phish-stats.log). This will allow you to gather metrics on each campaign in a quick and easy way. The log is “|” delimited and the format is below. You can load this file up into excel and do some number magic to see your progress.

"$date|$sender|$subject|$total_mail|$email_responses|$web_visits|$post_web_visits|$malicious_ip|$mail_agent|$vic_ip"

2015-11-03|john@mydomain.com|NOTICE|50|0|5|1|172.16.174.181, 172.16.49.116, 172.16.79.152, 172.16.79.184|-|-|

You can access the script on my github at hxxps://goo.gl/zJnEH4 or (hxxps://github.com/tcw3bb/ISC_Posts/blob/master/bro-phish.sh)

Tom Webb

Introduction

Earlier this week, I saw the most recent variant of CryptoWall as a payload delivered by the Angler exploit kit (EK) [1].  Many people, including me, have been calling this new variant "CryptoWall 4.0."  However, version 4.0 is not the most accurate term for this ransomware.  So why are we calling it that?

Background

On 2015-11-03, BleepingComputer published an article about this new CryptoWall variant, calling it CryptoWall 4.0 [2].  It had some notable changes from the previous variant.  The next day on 2015-11-04, someone else pointed out this new variant didn't refer to itself as version 4.0.  Instead, it appeared to be 3.0.1b034 build 0078 [3].

However, many security sites followed BleepingComputer's lead, calling the malware "CryptoWall 4.0" [4, 5, 6, 7, 8 to name a few].  I even called it 4.0 in my previous ISC diary, back when I saw this new variant appear in Nuclear EK traffic [9].  

A few sites haven't called it 4.0, though.  Instead, they have merely noted this is a new variant [10, 11].  However, the vast majority of people have reported the new CryptoWall variant as 4.0.

The case against 4.0

Until now, CryptoWall has been specific in its version numbers.  Since the original CryptoWall moved to version 2.0, the group behind CryptoWall has always stated the version number in the decryption instructions.  We noticed this from CryptoWall to CryptoWall 2.0.  We also saw it when 2.0 went to 3.0.  If they haven't indicated so, the people behind CryptoWall apparently don't believe their recent changes are enough to warrant the version 4.0 moniker.

The case for 4.0

Even though CryptoWall's authors are not calling it 4.0, the changes in this new variant are quite noticeable.  From a network traffic standpoint, we don't see the malware check an external site for the infected host's IP address.  Other changes are also notable--the notification text has changed, the names of the notification files are different, and the file names of your encrypted files are also encrypted.  This is a significant change in CryptoWall.

So what's the best way to let people know about the new CryptoWall?  How can you get someone's attention?  You can give it a new name, or perhaps a new spin on the same name.  The 4.0 designation may be inaccurate from the malware authors' view; however, it's a good way for us as defenders to identify the new variant.  For example, Bitdefender explained to SecurityWeek.com that it assigned the 4.0 designation to signal a new version of the CryptoWall threat [12].

The changes from 3.0 to "4.0"

Below are the major changes in the newest variant of CryptoWall:

• "4.0" has no more IP address check to ip-addr.es like there was in CryptoWall 3.0.
• Decryption instructions in "4.0" state it's "CryptoWall" instead of "CryptoWall 3.0"
• CryptoWall 3.0 files for decrypt instructions are named HELP_DECRYPT (.TXT, .PNG, etc.)
• CryptoWall "4.0" files for decrypt instructions are named HELP_YOUR_FILES (.TXT, .PNG, etc.)
• CryptoWall "4.0" also encrypts the file names of the files it encrypts.  CryptoWall 3.0 doesn't change the file names.

The images below illustrate some of the changes.

Shown above:  CryptoWall 3.0 traffic, filtered in Wireshark, with an IP address check to ip-addr.es.

Shown above:  CryptoWall "4.0" traffic, filtered in Wireshark, without the IP address check to ip-addr.es.

Shown above:  Windows desktop after a CryptoWall 3.0 infection.

Shown above:  Windows desktop after a CryptoWall "4.0" infection (malware from BizCN gate actor using Nuclear EK).

Shown above:  Windows desktop after a CryptoWall "4.0" infection (malware from another actor using Angler EK).

Final words

I've discussed this CryptoWall version issue with other security professionals.  Most have told me CryptoWall 4.0 is a good way to refer to this new variant, at least for now.  

However, I like to be precise.  Calling this a new CryptoWall variant is okay.  In fact, we should probably forget version numbers when referring to CryptoWall, at least for now.

My most recent sample of this new variant of CryptoWall, delivered by Angler EK, can be found here.

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

References:

[1] http://www.malware-traffic-analysis.net/2015/11/30/index.html
[2] http://www.bleepingcomputer.com/news/security/cryptowall-4-0-released-with-new-features-such-as-encrypted-file-names/
[3] https://twitter.com/ydklijnsma/status/662041531185012736
[4] http://www.theregister.co.uk/2015/11/09/cryptowall_40/
[5] https://heimdalsecurity.com/blog/security-alert-cryptowall-4-0-new-enhanced-and-more-difficult-to-detect/
[6] https://threatpost.com/updated-cryptowall-encrypts-file-names-mocks-victims/115285/
[7] http://labs.bitdefender.com/2015/11/russian-hackers-are-behind-cryptowall-4-0-bitdefender-creates-vaccine/
[8] http://www.scmagazine.com/version-40-of-ransomware-cryptowall-released-now-encrypts-file-names/article/452036/
[9] https://isc.sans.edu/forums/diary/BizCN+gate+actor+sends+CryptoWall+40/20409/
[10] https://nakedsecurity.sophos.com/2015/11/06/cryptowall-ransomware-new-strains-demands-money-and-mocks-you/
[11] http://countuponsecurity.com/2015/11/07/cryptowall-strikes-back/
[12] http://www.securityweek.com/cryptowall-40-released-filename-encryption-feature

In today's Stormcast, Johannes summarizes the current issue with some of the software that comes pre-installed on Dell Laptops.  In short, Dell Foundation Services- which is used for remote management - allows unauthenticated WMI queries to be processed through a simple SOAP interface.  We've used WMI in many stories for reconnaissance, pentesting and attack activities (check out our Diary Archives and Search function for more on this).

Anyway, on one hand, an IT Manager might say "who better to write desktop management software than the hardware vendor".  A smarter IT Manager might say "no, someone who builds hardware for a living is the *worst* person to buy software from, especially if it's free software".  Maybe the ground lies somewhere in between - I typically format every new machine, use the vendor hardware drivers for whatever OS I install, and stop there (at least as far as hardware vendor code goes)

Long story short, after the past year of Superfish and Dell's equivalent of Superfish, and now this, I hope it's time we all look at the special presents we get "for free", preinstalled on new hardware!

References:

Today's Stormcast: https://isc.sans.edu/podcastdetail.html?id=4767  (or subscribe in iTunes  or RSS)
Dell Foundation Services issue: http://rum.supply/2015/12/01/dell-foundation-services.2.html
Superfish 2.0: https://isc.sans.edu/diary/Superfish+2.0:+Dell+Windows+Systems+Pre-Installed+TLS+Root+CA/20411  

===============

Rob VandenBrink
Metafore

In a typical security assessment, you'll do authenticated scans of internal hosts, looking for vulnerabilities due to missed patches or configuration issues.  I often use Nessus for this, but find that for a typical IT manager, the Nessus findings can be overwhelming. While a pentester might look for a specific Java or Flash vulnerability, the IT manager doesn't want to know that "station x has 26 Java vulnerabiities".  They want to know that "station x needs Java updated, and this is how not updating will affect the business.  In a perfect world, that same IT manager might also ask "why exactly do we have Flash and Java installed all over the place?", but maybe that's a story for a different day.

Anyway, on a typical, medium sized network, you can count on hundreds of thousands of findings in an authenticated Nessus scan.  In years past, I would have written some fancy sed / cut scripts to slice and dice this data, or maybe import the lot into a database and start from there on analysis.  Today though, I'm using Powershell - it's free, it's easy, and it's installed everywhere already, so your client can replicate both the findings and the process.

First, let's import the CSV file that we get from Nessus.  From the count, you can see exactly why this process can be so useful:
. 
 

Let's take a look at the data structure:

First, let's look for flash Player issues.  We're searching for all non-zero risk findings - Risk=zero just means "we found flash"

Now on to the useful part - which hosts are affected?  Many of these hosts have dozens of discrete flash vulnerabilities, but for the IT manager, the "fix list" is the first important thing, and the second is "how do we prevent this going forward?"

Next we'll tackle Java.  Not the "or" operator (|), and also that the match operator is case insensitive.  Be careful though, because field names are *definitely* case sensitive. It's easy to get a "zero" result if you mess up on case and accidentally end up querying an empty variable.  For Java, in this example we cut the 50,000-ish findings down to a short, useful list of 222.

So, what other issues do you want to hunt for, to whittle that total down?

Adobe Reader (note that I'm making sure to not double-count Flash issues here)
$adobe = $all | Where-Object {$_.Description -match “Adobe Reader” -And $_.Description -notmatch "Flash" -and $_.Risk -notmatch "None"}  

.NET Framework:
$dotnet = $all | Where-Object {$_.Description -match "Net Framework" -and $_.Risk -notmatch "None" }
Silverlight:
$silverlight = $all | Where-Object {$_.Description -match "Silverlight" -and $_.Description -notmatch ".Net" -and $_.Risk -notmatch "None" }

Office:
$msoffice = $all | Where-Object {$_.Synopsis -match '(Office|Word|Powerpoint|Excel|Outlook)' -and $_.Risk -notmatch "None" }

Microsoft Patches, Security Advisories and Service Packs:
$misc_microsoft = $whatsleft | Where-Object {$_.Name -match '(MS[0-9][0-9]-[0-9][0-9][0-9]|MS KB|MS Security Advisory|Windows Service Pack)' }

Yes, even in 2015, in most shops of any size, you'll always find one or two hosts that have never had a patch or a service pack installed

After all that, what's left?  Note that the query is broken up, mostly so you can read it:

$whatsleft = $all | Where-Object { $_.Description -notmatch '(Flash|Adobe|JRE|JSE|JAVA|Java|jre|jse)'} | Where-Object {$_.Name -notmatch '(Silverlight|Net Framework|Office|Word|Powerpoint|Excel|Outlook|Explorer)'} | Where-Object {$_.Name -notmatch '(MS[0-9][0-9]-[0-9][0-9][0-9]|MS KB|MS Security Advisory|Windows Service Pack)' } | Where-Object {$_.Risk -notmatch "None"}

The final summary of issues is:
$final_summary = $whatsleft2 | select 'Plugin ID', Name | Group-Object 'Plugin ID' | Sort-Object -Descending Count

To view just the issues:
$final_summary | Out-GridView