The email message sent to the bank employee claimed that the sender received a wire transfer from the recipient's organization and that the sender wanted to confirm that the payment went through without issues. The victim was encouraged to click a link that many people would consider safe, in part because it began with "https://www.google.com/". How would you examine the nature of this email?

Examining MSG and EML Files on Linux

One way to analyze the suspicious message saved as an Outlook .msg file is to start with the MSGConvert tool by Matijs van Zuijlen. This utility can convert .msg files into the more open multipart MIME formatted .eml files, whose structure is defined by RFC 822. MSGConvert works well on Linux. If you are using a recently-updated REMnux system, MSGConvert is already installed and you can invoke it using the "msgconvert" command. If using another distro, you can install the tool using the command "cpan -i Email::Outlook::Message".

Once MSGConvert produces the .eml file, you can examine some of its aspects using a text editor, though this approach won't provide you with visibility into some aspects of the file's contents. A better alternative is to use the emldump.py utility by Didier Stevens, which can deconstruct an .eml file into sub-components and extract the contents, like this:

In the example above, invoking emldump.py without any parameters showed the structure of the .eml file. The "-d" parameter directed the tool to dump the item that was designated using the "-s" parameter.

The suspicious email message included plain text and RTF-formatted components with matching contents. This is typical of many messages sent nowadays: The sender's email client uses RTF to represent formatting and also attaches the text version of the message for email client that cannot display RTF content.

In the case of the email message described here, it is unclear whether it was used as part of a mass-scale or a targeted attack, which is one of the reasons I'm not showing its contents here. However, the message resembled the style of the note posted on one public forum, which looked like this:

"Recently I received BPay transfer from you. I need to verify if it is sent correctly. This contact was in the transaction beneficiary info. Here is the full details of the payment:"

Automatic Redirect via Google

The malicious link embedded in the email message was designed make the victim believe that the destination of the URL was hosted on google.com and was, therefore, safe. In reality, the link was designed to redirect to a .zip file hosted on Dropbox. The URL was carefully structured to utilize the automatic redirection capability of google.com. It began like this:

https://www.google.com/url?q=https%3A%2F%2Fwww.dropbox.com...

However, a simple form of this URL would be insufficient to trigger an automatic redirect. Instead Google would have presented the victim with the following message:

So that the victim didn't encounter this notice, the attacker added the "usg=" parameter to the malicious URL. Though the details of this parameter to Google's search URL are undocumented, it appears to contain a hash or a checksum of the URL specified in the "q=" parameter. If "usg=" is missing or its contents don't match the URL in the query, then Google doesn't automatically redirect and presents the notice above. A proper value supplied within this parameter causes google.com to automatically redirect to the specified URL. Google uses this mechanism to direct visitors to their desired destination when they click a link on the search results page.

No one outside Google seems to know the algorithm for computing "usg=" contents. To derive the proper value, the attacker must have had to wait for Google to index contents his or her Dropbox, so that Google's servers precomputed the hash/checksum. However, adversaries can get Google to compute the "usg" hash quickly. For instance, the miscreant can email the desired destination URL to his/her own Gmail account, and then access Gmail using basic HTML view. For some reason, when accessed this way, Gmail converts the URL embedded in the email to the Google-redirected form, which includes the proper "usg" hash.

Armed with the proper "usg" hash, the attacker would have known how to craft the URL that automatically redirected the victim.The potential of using "usg=" for automatic malicious redirects has been known for several years, though at the time it was not clear how attackers could quickly obtain "usg" hash values.

Google is aware of the potential for using its search engine for redirection and doesn't consider this a vulnerability. Google's position is that URLs are "not a reliable security indicator, and can be tampered with in many ways; so, we invest in technologies to detect and alert users about phishing and abuse, but we generally hold that a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk."

As the incident discussed in this diary shows, adversaries employ google.com for redirection nonetheless, apparently with some success. Moreover, Gmail's ability to provide attackers with an easy way for computing "usg" hashes weakens the safeguards that Google erected to defend against the abuse of its redirection feature. (I reported the Gmail-related scenario to Google, so the company can assess the potential for its misuse.)

As of this writing, it is no longer possible to download the malicious zip file discussed in the email above, because Dropbox presents the following message:

Error (429) This account's public links are generating too much traffic and have been temporarily disabled!

Tracking Email Using Google Analytics

The malicious message contained an embedded 1-pixel image that was designed to track whether, when and where the recipient opened the message. This web bug was linked to the attacker's Google Analytics account. To accomplish this, the embedded HTML code began like this:

img src="http://www.google-analytics.com/collect?v=1&tid=...

The "tid=" parameter contained the sender's Google Analytics tracking ID. The "cid=" parameter identified the message recipient using the person's email address. As the result, Google Analytics provided the adversary with the insights necessary to track the effectiveness and context of the initial attack vector.

In this incident, the attacker was using mainstream tools to deliver malicious payload and keep an eye on the overall campaign with the help of Google search engine's redirects, Google Analytics and Dropbox. These tools provide adversaries with powerful and scalable capabilities at the affordable price of zero dollars.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.

After last week's story, hopefully you've got your "problem" users accounts identified.  With that worked out, let's see about finding problem applications.

We all need a handle on what applications are installed on workstations for a number of reasons

• to make sure that when upgrade time comes, that nobody gets left behind
• that older apps that have security vulnerabilities or have limited function get taken care of - old versions of putty or Java for instance
• that users don't install applications that the organization hasn't paid for
• and finally, it's a decent shot at finding installed malware that your AV product might have missed.

First, let's look at the powershell command to list installed software.  This is a rough equivalent of control panel / programs, or "wmic product list"

Get-WmiObject -Class Win32_Product -computername

If you run this, you'll see that this is *really* verbose (I won't show the output), and the list view is not so useful.  Let's trim it down to Vendor, Product Name and Version:

Get-WmiObject -Class Win32_Product -computername . | select vendor, name, version | format-table

or, to make the display more useful, replace "format-table" with "out-gridview" or "output-csv" as we discussed last week:

But that just gives us programs that use the Microsoft installer process to install (msi's and similar packages).  How about single exe type apps, things like putty.exe, sed.exe and so on?  We can address those file by file:

get-childitem sed.exe | fl

Name           : sed.exe
Length         : 186880
CreationTime   : 9/4/2012 1:33:52 PM
LastWriteTime  : 3/31/2009 3:32:34 PM
LastAccessTime : 9/4/2012 1:33:52 PM
VersionInfo    : File:             C:\sed.exe
                 InternalName:     sed
                 OriginalFilename: sed
                 FileVersion:      10.0.7063.0
                 FileDescription:  SUA Utility
                 Product:          Microsoftr Windowsr Oper
                 ProductVersion:   10.0.7063.0
                 Debug:            False
                 Patched:          False
                 PreRelease:       False
                 PrivateBuild:     True
                 SpecialBuild:     False
                 Language:         English (United States)

But we want a table view, and again just a few of those fields.  The name, the original name (to account for users renaming EXE files), the file and application versions, and maybe the publisher.  Some of these are a bit tricky to get, as they're lower down in the heirarchy of the object, but it's very do-able:

get-childitem ssh.exe | format-list name,creationtime,lastwritetime,@{label="ProductVersion";expression={$_.versioninfo.productversion}},@{label="FileVersion";expression={$_.versioninfo.fileversion}},@{label="Original FileName";expression={$_.versioninfo.originalfilename}}

Name              : ssh.exe
CreationTime      : 5/30/2011 4:50:57 PM
LastWriteTime     : 8/6/2013 6:12:44 PM
ProductVersion    : Release 0.63
FileVersion       : Release 0.63
Original FileName : PuTTY

OOOPS - looks like I'm a rev back on putty!  - note that I renamed putty to ssh, but the file metadata remembers the original name for me

This also works for more legitimate apps (excel is shown here):

get-childitem excel.exe | format-list

    Directory: C:\Program Files (x86)\Microsoft Office\Office14

Name           : excel.exe
Length         : 20400288
CreationTime   : 5/22/2015 7:11:54 PM
LastWriteTime  : 5/22/2015 7:11:54 PM
LastAccessTime : 6/11/2015 3:58:19 PM
VersionInfo    : File:             C:\Program Files (x86)\Microsoft
                 Office\Office14\excel.exe
                 InternalName:     Excel
                 OriginalFilename: Excel.exe
                 FileVersion:      14.0.7151.5001
                 FileDescription:  Microsoft Excel
                 Product:          Microsoft Office 2010
                 ProductVersion:   14.0.7151.5001
                 Debug:            False
                 Patched:          False
                 PreRelease:       False
                 PrivateBuild:     False
                 SpecialBuild:     False
                 Language:         Language Neutral

Great, you say, how is inventorying things one file at a time useful?  Let's use get-childitem recursively and pull all the EXE's in one shot.  This is a reasonable way to grab everything.  With that in a spreadsheet or database, you'll likely want to delete duplicates entries (multiples for MS Office for instance), then after a closer look, store that as a baseline to track for changes at a later date.

get-childitem c:\*.exe -recurse | format-table name,creationtime,lastwritetime,@{label="ProductVersion";expression={$_.versioninfo.productversion}},@{label="FileVersion";expression={$_.versioninfo.fileversion}},@{label="Original FileName";expression={$_.versioninfo.originalfilename}},@{label="Product";expression={$_.versioninfo.product}}

Or, better yet, using a slightly different script and outputting to CSV - so you can more easily read it in excel or dump it to a database:

Get-ChildItem -Path c:\utils\*.exe -Recurse |`
foreach{
$Item = $_
$Filename = $_.Name
$Ver = $_.versioninfo.productversion
$filever = $_.versioninfo.fileversion
$Age = $_.CreationTime
$originalname = $_.versioninfo.originalfilename
$product=$_.versioninfo.product

$Path | Select-Object `
    @{n="Name";e={$Filename}},`
    @{n="FilePath";e={$Item}},`
    @{n="Original Name";e={$originalname}},`
    @{n="Created";e={$Age}},`
    @{n="Product Ver";e={$product}},`
    @{n="File Ver";e={$filever}}`
}| Export-Csv d:\sans\Results.csv -NoTypeInformation

Note that not all values are populated in the metadata for every file - that's just the way it is when you're processing standalone files like this.

Using this approach, you can see that with maybe an afternoon of scripting effort, you can set up a system that you might otherwise pay thousands or tens of thousands of dollars for - assuming that you're OK running your software inventory system from the CLI.  For me, running my inventory from the CLI would be prefered, but I guess you figured that out !

Have you found a trick to process information like this more efficiently?  Got a better script to collect this info more simply?  Please, share using our comment form!

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

I'm sure most of you are familiar with the EICAR (European Institute for Computer Antivirus Research) test file. Your anti-virus application should detect the EICAR test file the same way it detects malicious files. But it is a test file, so of course, the EICAR file is not malicious.

If you have doubts that an anti-virus application is working correctly, you use the EICAR test file. If the file is not detected, there is a problem.

If you have doubts that anti-virus alerts are properly delivered to your SIEM, you use the EICAR test file.

There are many examples where the EICAR test file comes in handy.

But using the EICAR test file has become more difficult over the years, because there are more and more security applications and devices that detect it. For example, downloading the EICAR test file in a corporate environment will often fail, because the anti-virus on your proxy will detect and block it.

That's why I decided many years ago to create a program that writes the EICAR test file to disk when it is executed. The anti-virus program should not detect the EICAR test string inside my program (per the EICAR test file convention), but they should detect it when it's written to disk. My program, EICARgen, worked fine for many years, but this has changed since a couple of years. Now many anti-virus programs detect EICARgen as a dropper (malware that writes its payload to disk).

I developed a new version: now when EICARgen is executed, nothing happens. It will only write the EICAR test file to disk when you pass it the proper argument: EICARgen write.

And now I come to the point of this diary entry. This new version of EICARgen is not only able to write the EICAR test file to disk, but also a couple of container files that contain the EICAR test file: a ZIP file, a PDF file and an Excel file. This is useful to test the settings of your anti-virus. For example, if your anti-virus is configured to scan the content of ZIP files, then you can use EICARgen to test this: EICARgen.exe zip eicar.zip.

I also have a video of EICARgen in action.

Please write a comment if you have other examples of file formats that you use when testing your anti-virus. Or if you have an idea for a file format to add to EICARgen.

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

This week Computerworld [1] published a story about the US Navy still paying Microsoft millions to support Windows XP when support ended April 8, 2014 [2] and soon Windows server 2003 will follow suit next month July 14, 2015.

Unless you are paying Microsoft to continue using legacy systems like WinXP, it is obvious that you would need to pay support to get patches and continue protecting you network against vulnerabilities that are no longer publically release to defend against potential compromised. This brings the cycle of modernizing custom applications used to support critical system that have been written on older platform and should have been part of a program to modernize, test and upgrade in time, to save million in support which I think in the end should save money. As an example, the Navy is paying a "[...] contract that could be worth up to $30.8 million and extend into 2017."[1]

Are you still supporting WinXP because of legacy applications and is there a plan to migrate them over Win7/Win8? If not, how are you protecting these clients against exploitation?

[1] http://www.computerworld.com/article/2939435/government-it/us-navy-paid-millions-to-stay-on-windows-xp.html
[2] https://www.microsoft.com/en-in/windows/enterprise/end-of-support.aspx

-----------

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

Cisco today released a security advisory announcing that some of Cisco's IronPort "virtual appliance" products contain "multiple default SSH keys". To quote:

A vulnerability in the remote support functionality of Cisco WSAv, Cisco ESAv, and Cisco SMAv Software
could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user.

Oh, good thing it's only "root". You had me worried there for a second :).  Interestingly, there was a somewhat similar Cisco advisory one year ago (on CUCDM) where also a default SSH key was present, and equally led to root privileges. Searching for "default credentials" on Cisco's advisory web site shows that for the past several years, the presence of backdoor and default users continues to be a recurring issue:

To Cisco's credit, they seem to have found today's SSH key problem on their own, before it was abused, so maybe this is a sign of better times to come, and evidence that after all these years, someone at Cisco has actually started to systematically audit their entire code base for the presence of default credentials. Or maybe it just was a lucky find, and the "stellar" 10 year track record of default credential security bulletins will continue for another decade?  Time will tell...

The goal of a penetration test is to report all identified vulnerabilities to the customer. Of course, every penetration tester puts most of his effort into finding critical security vulnerabilities: SQL injection, XSS and similar, which have the most impact for the tested web application (and, indeed, it does not hurt a penetration tester’s ego when such a vulnerability is identified :)

However, I strongly push towards reporting of every single vulnerability, no matter how harmless it might appear (and my penetration team coworkers sometimes complain about this, but let’s prove them wrong).

Here we’ll take a look at how two seemingly low risk vulnerabilities can be combined into a more dangerous one.

Accepting parameters in GET and POST requests

When processing parameters/responses received from the client, most of the today’s web applications rely on POST HTTP requests. This is a preferred way of sending client-related input/output from the browser since it will not be visible in web server’s (or proxy’s) logs. One of the tests I normally do is to check if the application accepts same parameters in GET HTTP requests. Let’s take a look at this.

The “official” request looks like this:

POST /page HTTP/1.1
Host: my.example.local
… (other headers)

parameter=value&secret=secret_value

Now we can try to issue the same request as a GET HTTP request:

GET /page?parameter=value&secret=secret_value HTTP/1.1
Host: my.example.local
… (other headers)

If this worked it means that the tested web application (the tested page/script) accepts parameters from any request. While this by itself is not really a security vulnerability, it is not a perfect way for receiving and processing parameters as we will see below. Additionally, keep in mind that this makes an attacker’s job a bit easier – instead of working with POST HTTP requests he can simply put everything into GET HTTP request (yeah, it works for the defenders as well since we’ll see what he put into the request).

A seemingly harmless XSS vulnerability

While further testing this application we found an XSS vulnerability. For sake of simplicity let’s say it’s an anonymous application that has no login forms. However, since the application depends on a certain workflow, and since the XSS vulnerability was found in the 3rd step of the workflow, it does require a valid session cookie (a JSESSIONID cookie).

What does this mean? It means that the attacker cannot exploit the XSS vulnerability: if the request to the vulnerable page is made without a valid JSESSIONID cookie, the application simply redirects the user to the front page (the first step of the workflow). Even if the victim now again clicked on the malicious link, it still wouldn’t work because the tested application checks the workflow phase/step and if it is not correct again simply redirects the user to the front page.

Ahh, such a disappointment after finding a very nice XSS vulnerability: the attacker can really exploit only himself and that’s no fun at all. Or is there another way?

Taking this a bit further

Remember how we figured out that the application accepts parameters in both GET and POST HTTP requests above?
Let’s see what else can be submitted through such requests. The cookie, which is crucial to the behavior of the tested application is a simple JSESSIONID cookie that looks like this:

Cookie: JSESSIONID=560308266F93351159D8D20732C637FA

Since the cookie is normally sent as part of a header, the attacker cannot get the victim’s browser to set the cookie for the target web application, at least not without exploiting another vulnerability – such as an XSS vulnerability – but remember that we cannot exploit it without a valid cookie. Catch 22 isn’t it?

But, let’s not lose hope. What if we try to submit the cookie as a parameter in a GET or POST HTTP request? Such a request would look like this:

GET /page?JSESSIONID=560308266F93351159D8D20732C637FA¶meter=value&secret=secret_value HTTP/1.1
Host: my.example.local
… (other headers)

Bingo! This worked – the tested web application happily took and parsed all submitted parameters, even the JSESSIONID parameter that should be normally delivered as a cookie. The developers probably wanted to be as flexible as possible.

Combining the vulnerabilities into an exploit

So, the attacker can now deploy the following attack:

• Create a new session where he navigates to the required screen. The application now “knows” that the JSESSIONID cookie that was given to the attacker relates to a session that is at the vulnerable screen.
• Create a malicious URL that exploits the XSS vulnerability. Append the JSESSIONID parameter that contains the attacker’s cookie value to the malicious URL. This URL will work because the vulnerable web application will verify the session state and see that the user is accessing a valid screen in the workflow.
• Send the malicious URL to the victim, wait and profit.

Finally, last thing to discuss is maybe what we exploit with the XSS vulnerability in the first place: typically the attacker tries to steal cookies in order to gain access to the victim’s session. Since here sessions are irrelevant, the attacker will not use XSS to steal cookies but instead to change what the web page displays to the victim. This can be used for all sorts of phishing exploits and, depending on the URL and context of the attack, can be even more devastating than stealing the sessions.

--
Bojan
@bojanz
​INFIGO IS

Powershell has gotten a lot of attention lately as a pentester's tool of choice, since it has access to pretty much every low-level system function in the Microsoft ecosystem, and the AV industry isn't dealing well with that yet (aside from ignoring powershell completely that is).

But what about day-to-day system administration?  Really, the possibilities for admins are just as limitless as for pentesters - that's what Powershell was invented for after all !

A simple call like "get-aduser -filter * -properties * "  can get you everything you want on domain user accounts.  However, most sysadmins will look at this and give me the TLDR response - it's just too much information to process effectively.

But how about filtering that- let's find all users who aren't required to reset their passwords?

Or who don't have passwords at all?

How about have never reset their passwords (ie - haven't changed the initial password set at creation):
get-aduser -filter * -properties * | select samaccountname,passwordlastset

Operationally - let's add to the list - say folks who've had their accounts locked.  This might be a "reset password on Friday, can't remember on Monday" symptom, but might also  be someone brute forcing that account on the corporate website or VPN  (hint - 2-factor authentication does wonders for those!)

get-aduser -filter * -properties * | select samaccountname,passwordlastset,lockedout

You can use the above to also find out who's left the organization.  If you're like lots of IT groups, maybe HR isn't so timely in letting you know about departures!  Let's dig to see who hasn't logged in in 4 weeks.  8 weeks?  12 weeks?   Best call HR with this list in-hand to see if these folks are on longer term leave, or if they've moved on or maybe just stopped showing up for work?

get-aduser -filter * -properties * | select samaccountname,lastlogondate

At this point it becomes obvious that you want to sort these lists.  You can go directly to a GUI view, where you can sort an play with the data as needed:

get-aduser -filter * -properties * | select samaccountname,passwordlastset | out-gridview

I find the CSV output, which can  then be imported to excel - to be the most useful.  If for regulatory (or other) reasons, you then need to save those files to demonstrate that you do audit yourself, and that you compare your audits to previous data, this can be a real help

The list that I use most often is below (change the field order as needed):

get-aduser -filter * -properties * | select samaccountname, name, enabled, scriptpath, passwordlastset, passwordexpired, passwordneverexpires, passwordnotrequired, lockedout, lastlogondate, cannotchangepassword, accountexiprationdate | export-csv "c:\pathspec\account-problems-yy-mm-dd.csv"

This imports directly into Excel (or any other spreadsheet), where you can slice and dice to your heart's content.

In closing, let me acknowledge Jason Fossen and SANS SEC 505 for re-kindling my enthusiasm for Powershell !  If you want to dig deeper into Powershell with a security slant, I'll be posting on this topic for a while, stay tuned.  But if you want 6 days solid of concentrated powershell+windows goodness, take a look at SEC 505!

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

XOR DDOS Trojan Trouble

I have struggled over the past recent months with a clients environment becoming infected and reinfected with an XOR DDOS trojan.  The disruption and reinfection rates were costly at times.  The client in question is a small business with limited resources.  Since the systems would get reinfected, a baited system was eventually put into place to determine the incoming vector.  It was not proven, but believed that ssh brute force was the incoming vector of attack.  Once the attackers were onto the server, a root kit trojan was used.  A very intelligent one.  I highly recommend that anyone that gets nabbed by this trojan or one like it reinstall your operating system as soon as possible and execute my prevention steps outlined below.

However, there are some circumstances that require mitigation before available resources can be used for reinstall/replacement and prevention measures.  The client was in a situation where taking the system offline was not an immediate option.  I placed some really great links below. [1] [2] [3]   They review, analyze and fully confirm what we were experiencing was the same.  There were some minor differences.   However, they never really offered a short term mitigation path to follow.  Only somewhere in a comment on a forum (possibly one of the three articles below), did someone make a suggestion to change the file/directory attributes to assist in mitigation.  It was only a suggestion with no further follow-up.  Mitigation of this trojan was difficult as it was intelligent enough to always restart when it was killed, which included help from crontab entries every three minutes.  It was also observed the executable sometimes was hidden very well in the process table.

Basic MO

The victim server was CentOS 6.5 system with a basic LAMP setup, that offered ssh and VSFTP services.  Iptables was in use, but NOT SELinux.  It is my untested claim that SELinux likely would have prevented this trojan from taking hold.   I am not an SELinux user/expert so I was unable to take time to add it to this environment.   

The original malware was discovered in /lib/libgcc4.so .  This exe was perpetuated via cron in /etc/crontab every three minutes.  
( */3 * * * * root /etc/cron.hourly/udev.sh )
If crontab gets cleaned and an executable is still running, then the crontab will be repopulated on Friday night around midnight.  (remember that sometimes the exe was hidden well and was overlooked)

The malware creates random string startup scripts and places them in /etc/init.d/* .  You need only to execute ls -lrt /etc/init.d/* to discover some evidence.  Along with the use of the top utility, you can determine how many are running.  If the startups are deleted, then more executables and startup scripts will be created and begin to run as well.

The malware itself was used as a DDOS agent.  It took commands from a C&C.  The IP addresses it would communicate with were available from the strings output of the executable.  When the malware agent was called into action, the entire server and local pipe was saturated and consequently cut off from service.

Mitigation

The following steps were taken for mitigation.   The only thing that prevented the recreation of the malware was the use of the chattr command.   Adding the immutable bit to the /etc/init.d and /lib directories were helpful in preventing the malware from repopulating.  I put together the following for loop script and added the following IP addresses to IP tables to drop all communication.    The for loop consists of clean up of four running processes.  I used ls and top to determine the for loop arguments and PID's used in the kill command.   I through the following into a script called runit.sh and executed it.

For loop:
for f in zyjuzaaame lcmowpgenr belmyowxlc aqewcdyppt
do
   mv /etc/init.d/$f /tmp/ddos/
   rm -f /etc/cron.hourly/udev.sh
   rm -f /var/run/udev.pid
   mv /lib/libgcc4.so /tmp/ddos/libgcc4.so.$f
   chattr -R +i /lib
   chattr -R +i /etc/init.d
   kill -9 19897 19890 19888 19891
done

IP Addresses to drop all traffic:   103.25.9.228  103.25.9.229

Prevention

I now keep the immutable bit set on /lib on a clean system.  It turn it off before patching and software installs, in the event the /lib directory is needed for updating.  

I also recommend installing fail2ban and configuring it to watch many of your services.  I have it currently watching apache logs, ssh, vsftp, webmail, etc.   It really seems to be hitting the mark for prevention.   There is a whitelist feature to ignore traffic from a given IP or IP range.   This helps to keep the annoying customers from becoming a nag.

If you have experienced anything like the above, then please feel free to share.  This analysis is only scratching the surface.  The links below do a much deeper dive on this piece of malware.  

 
[1] https://www.fireeye.com/blog/threat-research/2015/02/anatomy_of_a_brutef.html
[2] https://blog.avast.com/2015/01/06/linux-ddos-trojan-hiding-itself-with-an-embedded-rootkit/#more-33072
[3] http://blog.malwaremustdie.org/2014/09/mmd-0028-2014-fuzzy-reversing-new-china.html


-Kevin
--
ISC Handler on Duty

Brute forcing SMTP credentials is hardly new. But I have seen a couple of odd patterns lately in one of my mail servers, and was wondering if anybody has any insight into these patterns. For this diary, I am using logs starting May 31st until today.

First, the overall patterns shows very strong spikes with 2000-3000 attempts per hour. These "spikes" usually come from many different IP addresses, so they are likely caused by a botnet probing my system. The last spike on June 19th was caused by about 400 different IP addresses (I am running fail2ban, and they are blocked after a couple of attempts).

The usernames are where it gets a bit more interesting. Here is a list of the top 20:

   6096 leonelfetuscrosby
   3595 dan
   3399 ix444ejxvwda050
   2763 
    176 
     83 ncoppen
     82 info
     56 spam
     53 admin
     47 sales
     34 abuse
     28 paul
     28 pager
     26 test
     23 support
     21 awilloughby
     20 webmaster
     18 hr
     18 d573697
     17 help

The part that is of some concern is that a couple of the users are actual users of the server. The "ranking" goes somewhat by the amount of e-mail created by the user in general, so it is possible that spamers do try usernames they already have in their database against mail servers used by their domain. I don't capture passwords, but the number of attempts for most of the usernames is small, so I assume only a couple of passwords are used. The first and third name are odd as they look "random". Could they be used to detect if the mail server responds differently for users that do not exist?

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

There was a vulnerability released earlier this week that has quite the potential to be a biggie. It is worth noting mainly because Ubuntu is quite prevalent and the propensity to patch systems is quite low, or at least slow. Ubuntu is also used as part of the underlying infrastructure for many a VPS provider. 

The issue was discovered by Philip Pettersson and the details can be found here --> http://seclists.org/oss-sec/2015/q2/717

What it boils down to is an issue in overlayfs and permissions checking.  
One use for overlayfs is to present a writable files system when the underlying file system is read only.  When a file needs to be writable it is copied from the lower directory (real file system) to the upper file system where it can be modified.  Philip worked out that the permission needed is that of the original file owner rather than the user triggering the copy_up.  

The POC shows a number of things that can be done using this vulnerability.  

The patch is out, so that should be the first choice. If you can't patch you may be able to blocklist the module on your system (modify /etc/modprobe.d/blocklist or /etc/modprobe.d/blocklist.conf) on your system.  

POC: https://www.exploit-db.com/exploits/37292/  and 37293

Mark H - Shearwater

The last couple of days, a paper with details about XARA vulnerabilities in OS X and iOS is getting a lot of attention [1]. If you haven't seen the term "XARA" before, then this is probably because cross-application-resource-access was normal in the past. Different applications has access to each other's data as long as the same user ran them. But more recently, operating systems like OS X and iOS made attempts to "sandbox" applications and isolate applications from each other even if the same user is running them.

These sand boxes were supposed to prevent a single malicious application from compromising the entire system. 

iOS uses sand-boxed applications exclusively as it limits application installs to the app store. In OS X, applications downloaded from the app store have to implement sand-boxing. But users are still able to download arbitrary applications that do not use sand-boxing. For example, one reason there are no effective anti-malware applications for iOS is that there is no way to load an application that would have privileges to inspect other applications.

However, applications still need to talk to each other, and developers use various methods offered by the operating system to send data to each other. This paper does outline how some of these methods can be used to access other applications beyond there intended scope.

To explain this with an example, I am going to use the "Keychain" access that has caused probably the most headlines. For others, and for more details, please refer to the original paper.

If an application would like to store a password in the iOS or OS X keychain, it needs to create a new entry. The application will check if an entry with it's name already exists. There are two options:

- The value does not yet exist (first time user sets up a password in this application)

In this case, the application will create a new entry. It has the option to secure it by only providing some applications access to the value. For example, if we would publish several applications, then we could allow all of our applications to access this entry. 

- The value already exists (the user already configured a password)

In this case, if the application has access to the entry, it can overwrite it or read it. If another application happened to use the same name, then the entry should be locked if that other application implemented the keychain entry correctly.

However, a malicious application, if run ahead of the victim application, can setup a password entry with the same name as the victim application IF the victim did not configure a password yet. The malicious application would then create an entry that is open to the victim application and of course remains open to the malicious application.

As mentioned before, Keychain is just one of the features suffering from problems with cross application resource access. For the most part, this has to be fixed by the operating system, and may require modifying APIs, which may not be backward compatible. Next, application developers may be able to add some mitigation, but it is not clear which methods will work for the different XARA abuse cases.

As a normal end user, the only thing you can do is be careful as to what applications you install. For iOS, Apple can add additional checklist items to its application review process, but the authors of the paper did manage to publish a proof of concept application.

For jail broken iOS devices, or for OS X users installing non-sand boxed applications, this vulnerability does not present any new risks. Mobile malware in particular is still rather uncommon.

[1] https://drive.google.com/file/d/0BxxXk1d3yyuZOFlsdkNMSGswSGs/view

(note that the paper is hosted on a shared Google drive and your Google user name may be visible to the authors)

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

Introduction

Botnets continually send out malicious spam (malspam).  As mentioned in previous diaries, we see botnet-based malspam delivering Dridex and Dyre malware almost every day [1, 2].  Recently, someone sent us a malicious Word document from what appeared to be Dridex malspam on Tuesday 2015-06-16.  (Thanks, Wayne... You know who you are!)  Unfortunately, while investigating the malware, I could not generate the full range of infection traffic.  Otherwise, the traffic follows the same general patterns we've previously seen with Dridex [1].

Examples of the malspam

Dridex has been using Microsoft Word documents and Excel spreadsheets designed to infect a computer if macros are enabled, which matches the infection vector used by this malspam.  Shown below are two examples of the malspam from Tuesday 2015-06-16.  Both examples claim the recipient has made an error in tax forms.  This wave of malspam used a Word document for the malicious attachment.  As seen before with botnet-based malspam, the emails have different senders, subject lines, attachment names, and message text.  Due to these many differences, people usually have a hard time blocking it from their mail servers.

Examples of the Word documents

The image below shows an example of a Word document sent on 2015-06-16.  File names consist of random characters.  Random characters are also seen in the "Authors" and "Last saved by" fields.

Macros are not enabled in the default installation for Microsoft Office.  To infect a computer, most people will have to enable macros after the document is opened, as shown below.

Traffic

Below is a screenshot of Wireshark displaying traffic seen from an infected host.

Traffic seems typical of Dridex we've seen the past couple of months.  Last month, the follow-up executable was retrieved from a pastebin.com URL over HTTP.  This time, the follow-up executable was retrieved from a dropbox.com URL using HTTPS.

The attempted TCP connections shown below would normally result in SSL traffic, but the servers did not respond.  That's probably an issue for this particular sample or possibly my environment's connection to the Internet.

• 5.144.130.35 port 80 - dolphin2000.ir - GET /tmp/89172387.txt
• 5.144.130.35 port 80 - dolphin2000.ir - GET /tmp/lns.txt
• 1.1.5.4 - Echo (ping) request
• www.dropbox.com - GET /s/2djqlpaqdudzlrx/iol.exe?dl=1 (https)
• 5.9.99.35 port 80 - savepic.su - GET /7230030.png
• 5.9.99.35 port 80 - savepic.su - GET /images/notfound.png
• 176.9.143.115 port 2443 - attempted TCP connection
• 185.12.94.48 port 7443 - attempted TCP connection
• 193.13.142.11 port 8443 - attempted TCP connection
• 176.9.143.115 port 2443 - attempted TCP connection
• 185.12.94.48 port 7443 - attempted TCP connection

Reviewing the traffic in Security Onion using the Emerging Threats and ET PRO signature sets shows a few Snort events, as shown in the image below.  There's nothing Dridex-specific in the events, and I've seen savepic.su used before with malspam using Chanitor to send Vawtrak [3, 4].  At first, I wasn't certain this was Dridex, but the VirusTotal entry for the downloaded EXE indicates this is probably Dridex [5].

Malware

The following artifacts were retrieved from the infected Windows host:

• C:\Users\username\AppData\Local\Temp\21807.bat
• C:\Users\username\AppData\Local\Temp\21807.ps1
• C:\Users\username\AppData\Local\Temp\21807.vbs
• C:\Users\username\AppData\Local\Temp\8.exe
• C:\Users\username\AppData\Local\Temp\444.jpg

The file 8.exe is an executable that deletes itself shortly after it is executed.

Final words

Botnet-based malspam is something we see almost every day.  A quick Google search on Dridex returns several articles with good insight into this malware.  However, traffic from Dridex and other botnets continually evolve.  What's current one week could be out-of-date the next.

If you run across any interesting malspam, feel free to use our contact form and send us a copy.  We might not be able to investigate all submissions; however, we're always interested in the samples.

Traffic and the associated malware for this diary can be found at:

• http://malware-traffic-analysis.net/2015/06/16/2015-06-16-possible-Dridex-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/16/2015-06-16-possible-Dridex-malware.zip

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

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

References:

[1] https://isc.sans.edu/diary/Recent+Dridex+activity/19687
[2] https://isc.sans.edu/diary/UpatreDyre+the+daily+grind+of+botnetbased+malspam/19657
[3] http://malware-traffic-analysis.net/2015/03/24/index2.html
[4] http://www.rackspace.com/blog/malicious-email-campaign-spreads-vawtrak-malware/
[5] https://www.virustotal.com/en/file/1ea2548ae6060765f125ed6173eeabf167eb53d70adde6f2c293b179526909ca/analysis/

Citizenlabs recently reported on a CVE-2014-4114 campaign against pro-democracy / pro-Tibetian groups in Hong Kong.  The attacks happening should not surprise anyone, nor that the attacks were sophisticated.  The vulnerability itself was patched with MS14-060 and has been used by APT and crime groups for sometime.  Trend Micro wrote a good write-up of the issue here.

What is interesting is what, in effect, is an anti-virus bypass that was employed by the actors.  This bypass was discussed in this report (disclaimer, from my day job).  In short, when CVE-2014-4114 exploit code was put into a .ppsx file generated by the exploit kit, it triggered AV.  When the same file was saved as a .pps file, those same AV engines stop detecting it.  The ppsx file format (Powerpoint slideshow format / XML) is the more modern format.  The .pps format was used in Office 97-2003 using the OLE format.  Even though AV engines stop detecting the malicious document, the exploit code ran without issue.

The first takeaway is, obviously, patch your systems and it is surprising how many targeted political organizations seem vulnerable to exploits that have had patches out for months.

The second is, the same malicious code may be represented differently in different file types and its important to get coverage of those other formats to ensure complete protection.

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

Many web application firewalls do block odd user agents. However, decent vulnerability scanners will try to evade these simple protections by trying to emulate the user agent string of commonly used browsers. To figure out if I can distinguish bad from good, I compared some of the logs from our honeypots to logs from a normal web server (isc.sans.edu). Many of the top user agents hitting the honeypot are hardly seen on normal web sites, allowing me to identify possible vulnerability scanners.

First: There are a number of legitimate scripts that poll our data on isc.sans.edu. While for example "Python" is used by many vulnerability scanners, we do have a good number of python scripts using our APIs. I tried to eliminate some of these requests. 

Odd legitimate user agents:

First lets start with a couple of odd user agents from our normal site:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.247) Gecko/20100101 Firefox/17.247

Yes, the string "User-Agent:" is part of the user agent string. The version of Firefox is also old... (if legit at all. I don't have Firefox 17 around to verify). This user agent string is used by a web site uptime monitoring service. I assume the developer didn't quite understand how to set the user agent, and ended up with the extra "User-Agent:" text.

Mozilla/5.0 (compatible; MJ12bot/v1.4.5; http://www.majestic12.co.uk/bot.php?+)

I don't see any actual attacks from "Majestic", but they are certainly an aggressive bot. As explained on their site, you can download the bot and the goal is to build a distributed network of bot spidering web based content.

Vulnerability Scanners

The following user agent strings are much more common in our honeypot then in our normal web site, indicating that these user agents are used by vulnerability scanners. However, these are (in some cases) legitimate user agents.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0

An old version of Firefox. The #1 user agent right now in our honeypot. Firefox/8.0 does not show up in the top 1,000 user agents used on isc.sans.edu.

Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0

#2 in our honeypot. Sure... there may be some people browsing the internet using Firefox 37 (a recent version) on Ubuntu. But certainly not your #2 most common browser. On our real system, this user agent comes in as #220. 

masscan/1.0 (https://github.com/robertdavidgraham/masscan)

#3 in our honeypot is masscan. Of course this is a safe to block vulnerability scanner.

Opera/9.80 (X11; Linux x86_64) Presto/2.12.388 Version/12.16

After some obvious bots (e.g Baidu), we got Opera, a browser that doesn't show up at all in the top 100 user agents used on our ISC website. 

So what can you do with this information?

- Some blocking on the web application firewall is probably a good idea for tools like masscan. You may want to allow them if they are used by legitimate pentesters or vulnerability scans that you use to test your web applications. 

- If some of these user agents have legit uses, but are more often used maliciously, use them for your log reviews. See what kind of requests you see more likely from odd (usually outdated) user agents . Many tools use a current user agent when they are created, but then the user agent is never updated so they end up with outdated user agent strings that start to "stick out" as most of your users upgrade. 

- Decent web application firewalls will look for other artifacts, like header order, to verify the user agent. We also see user agents like Googlebot abused (see a prior diary about identifying fake google bots) .

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

If you are at SANSFIRE 2015 in Hilton Baltimore, don't forget to join us today at 7:15 PM EDT for the SANS Internet Storm Center state of the internet panel!

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

RFC 7540 has been out for a month now. What should we expect with this new version?

1. New frame: HTTP/2 implements a binary protocol with the following frame structure:

• Length: The length of the frame payload expressed as an unsigned 24-bit integer.  Values greater than 2^14 must not be sent unless the receiver has set a larger value for SETTINGS_MAX_FRAME_SIZE parameter.
• Type: The 8-bit type of the frame.  It determines the format and semantics of the frame.  Implementations must ignore and discard any frame that has a type that is unknow. The following types are defined:
  • Length: The length of the frame payload expressed as an unsigned 24 bit integer. Values greater than 2^14 must not be sent unless the receiver has set a larger value for       SETTINGS_MAX_FRAME_SIZE.
  • Type:  The 8-bit type of the frame.  The frame type determines the format and semantics of the frame.  Implementations MUST ignore and discard any frame that has a type that is unknown. The following types are allowed:
  • Data: Type 0x0, used to transmit regular data in a connection.
  • Headers: Type 0x1, used to open a stream and additionally carries a header block fragment.
  • Priority: Type 0x2, specifies the sender-advised priority of a stream
  • RST_STREAM: Type 0x3, allows for immediate termination of a stream.  RST_STREAM is sent to request cancellation of a stream or to indicate that an error condition has occurred
  • Settings: Type 0x4, used to transmit configuration parameters that affect how endpoints communicate, such as preferences and constraints on peer behavior.  The settings frame is also used to acknowledge the receipt of those parameters.
  • PUSH_PROMISE: Type 0x5, used to notify the peer endpoint in advance of streams the sender intends to initiate.
  • PING: Type 0x6, used as a mechanism for measuring a minimal round-trip time from the sender, as well as determining whether an idle connection is still functional.
  • GOAWAY: 0x7, used to initiate shutdown of a connection or to signal serious error conditions.  GOAWAY allows an endpoint to gracefully stop accepting new streams while still finishing processing of previously established streams.
  • WINDOW_UPDATE: type=0x8, used to implement flow control.
  • Continuation: type=0x9, used to continue a sequence of header block fragments.  Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set.
• Flags: an 8-bit field reserved for boolean flags specific to the frame type
• R: A reserved 1-bit field.
• Stream Identifier:  A stream identifier expressed as an unsigned 31-bit integer.  The value 0x0 is reserved for frames that are associated with the connection as a whole as opposed to an individual stream.

2. Security:

• Implementations of HTTP/2 MUST use TLS version 1.2 or higher for HTTP/2 over TLS.  The general TLS usage guidance in RFC 7525 should be followed.
• The TLS implementation MUST support the Server Name Indication (SNI) extension to TLS.  HTTP/2 clients MUST indicate the target domain name when negotiating TLS.

3. Browser support: The following list resume browser support for HTTP/2 at this time:

• Chrome supports HTTP/2 by default, as of version 41.
• Google Chrome Canary supports HTTP/2 by default, as of version 43
• Chrome for iOS supports HTTP/2 by default, as of version 41
• Firefox supports HTTP/2 which has been enabled by default, as of version 36.
• Internet Explorer supports HTTP/2 in version 11, but only for Windows 10 beta, and is enabled by default.
• Opera supports HTTP/2 by default, as of version 28.
• Safari supports HTTP/2 in version 8.1, but only for OS X v10.11 and iOS 9.

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

An OpenSSL security advisory issued earlier today on Thursday 2015-06-11 [1].  According to the advisory users should upgrade OpenSSL to fix vulnerabliities that could be exploited by a Logjam attack [2].

The issue affects all current OpenSSL versions: 1.0.2, 1.0.1, 1.0.0 and 0.9.8.

• OpenSSL 1.0.2 users should upgrade to 1.0.2b
• OpenSSL 1.0.1 users should upgrade to 1.0.1n
• OpenSSL 1.0.0 users should upgrade to 1.0.0s
• OpenSSL 0.9.8 users should upgrade to 0.9.8zg

Related vulnerabilities from the announcement:

• CVE-2014-8176
• CVE-2015-1788
• CVE-2015-1789
• CVE-2015-1790
• CVE-2015-1791
• CVE-2015-1792

Of note, support for OpenSSL versions 1.0.0 and 0.9.8 will cease at the end of the year on 2015-12-31.  No security updates for 1.0.0 and 0.9.8 will be provided after that.  Users are advised to upgrade to the latest versions of 1.0.1 or 1.0.2.

References:

[1] http://openssl.org/news/secadv_20150611.txt
[2] https://weakdh.org/

Introduction

Since Monday 2015-05-25 (a bit more than 2 weeks ago), we've seen a significant amount of CryptoWall 3.0 ransomware from malicious spam (malspam) and the Angler exploit kit (EK).

A malspam campaign pushing CryptoWall 3.0 started as early as Monday 2015-05-25, but it has increased significantly since Monday 2015-06-08.  The CryptoWall 3.0 push from Angler EK appears to have started around the same time.  Both campaigns (malspam and Angler EK) were active as recently as Wednesday 2015-06-10.  

The timing of these campaigns indicates they might be related and possibly initiated by the same actor.

Below is a flow chart show the paths to infection from each of these campaigns:

Shown above: Path 1 shows the infection chain from the malspam - Path 2 shows the infection chain from Angler EK.

CryptoWall 3.0 from malspam

This campaign has been using Yahoo email addresses to send the malspam.  So far, all the attachments have been named my_resume.zip.  The first week of this campaign, material extracted from the zip attachments were all HTML files named my_resume.svg.  At that time, the CryptoWall 3.0 ransomware was downloaded from a compromised server.  This week, the extracted HTML file names use random numbers, with names like resume4210.html or resume9647.html.  Furthermore, the CryptoWall is now hosted on various docs.google.com URLs.

Shown above: some of the emails seen starting on 2015-05-25 through 2015-06-08.

Shown above: examples of the malicious spam.

Opening the attachment and extracting the malicious file gives you an HTML document.  An example is shown below:

 
Shown above: an example of the HTML file inside the zip attachments from the malspam.

Here are some of the URLs from the unzip-ed HTML files on Wednesday 2015-06-10:

• arosit.dk - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=288
• arosit.dk - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=296
• arosit.dk - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=490
• arosit.dk - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=609
• boerie.co - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=161
• boerie.co - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=191
• boerie.co - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=579
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=177
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=317
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=586
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=623
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=861
• interestingengineering.net - GET /wp-content/plugins/revslider/temp/update_extract/resume/resume.php?id=873

If you open one of these HTML files, your browser will generate traffic to a compromised server:

Shown above: Traffic from an HTTP GET request to one of the compromised servers.

The return traffic is gzip compressed, so you won't see it in the TCP stream from Wireshark.  Exporting the text from Wireshark shows HTML that points to a shared document from a Google server:

Shown above: HTML returned after the GET request pointing to docs.google.com.

Here are some of docs.google.com URLs we saw from the traffic on Wednesday 2015-06-10:

• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztV2ZrMGZTWFRnLU0
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztUmFCOGlteHdncWs
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztTnEzNnFfZktRZUk
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztdVU2RXZSeUlla00
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztczFQSWo4TWFtVnc
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztcklyU2dKdXRJdlE
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztcDEyZEg0QkZuYms
• (https) docs.google.com - GET /uc?export=download&id=0BzNnVzs5RTztaTNtOTJyd1hCejg
• (https) docs.google.com - GET /uc?export=download&id=0B-HWsX8wPhPFZDk2dms3c2plZk0
• (https) docs.google.com - GET /uc?export=download&id=0B-HWsX8wPhPFVTNpNTJneHJKazQ
• (https) docs.google.com - GET /uc?export=download&id=0B-HWsX8wPhPFQzJsSmYtdERrZ1k

Examining the traffic in Wireshark, you'll find see a chain of events leading from the compromised server to docs.google.com:

Shown above: Wireshark display one of the GET requests to a compromised server.

Run the downloaded malware on a Windows host, and you'll find traffic that's typical for CryptoWall 3.0.

Shown above: Wireshark display on some of the CrytpoWall 3.0 traffic.

The bitcoin address for ransom payment by this malware sample is 16REtGSobiQZoprFnXZBR2mSWvRyUSJ3ag.  It's the same bitcoin address from a previous sample found on Thursday 2015-06-04, when we were first notified of this particular malspam [1].  We also saw the same bitcoin address used on Tuesday 2015-06-09 [2] associated with another wave of malspam the following week.

​
Shown above: Decrypt instructions from the CryptoWall 3.0 sample.

CryptoWall 3.0 from Angler EK

We first noticed Angler EK pushing CryptoWall 3.0 on Tuesday 2015-05-26 [3].  I posted a diary about it on Thursday 2015-05-28 [4].  This was the first time I'd seen version 3.0 of CryptoWall sent by Angler.  I seen previous versions of CryptoWall from Angler, but not 3.0 until this campaign.

My last documented instance of Angler EK sending CryptoWall 3.0 happened on Tuesday 2015-06-09 [5].  We're still seeing examples where CryptoWall 3.0 came from Angler as recently as Wednesday, 2015-06-10.

In each case I've documented, the bitcoin address for the ransom payment was 16Z6sidfLrfNoxJNu4qM5zhRttJEUD3XoB.

Angler EK is still being used by other groups to send different malware payloads.  However, the appearance of CryptoWall 3.0 in Angler since 2015-06-26 using the same bitcoin address indicates this is a separate campaign by a specific actor.

This week, compromised websites that redirected to Angler had code injected into their web pages, much like the example below:

Shown above: Malicious code injected into a page from a compromised web server (points to Angler EK).

A fellow security professional notified me this is a common injection technique used on WordPress sites that have been redirecting traffic to Angler EK.

The image below shows the 2015-06-09 Angler EK traffic and CryptoWall 3.0 post-infection activity as seen in Wireshark:

Shown above: Wireshark display on Angler EK and the post-infection traffic by CryptoWall 3.0.

Final Words

The timing of these two campaigns, along with their consistent use of the same bitcoin addresses for the ransom payment, suggest they are related.  They may have been initiated by the same actor.  This is a significant trend in our current threat landscape.  We will continue to monitor this activity and report any significant changes in the situation.

Update - Thursday 2015-06-11 at 01:13 UTC

I generated more Angler EK traffic on 2015-06-11 at 00:09 UTC.  This time, I got a sample using a different bitcoin address than I'd seen from previous Angler-based CryptoWall 3.0 payloads.  This bitcoin address, 12LE1yNak3ZuNTLa95KYR2CQSKb6rZnELb, began transactions during the same timeframe as other samples associated with this campaign.

At this point, I'm not 100 percent certain it's the same actor behind all this CryptoWall 3.0 we've been seeing lately.  However, my gut feeling tells me this activity is all related to the same actor or group.  The timing is too much of a coincidence.

Traffic and the associated malware can be found at:

• http://malware-traffic-analysis.net/2015/06/11/2015-06-10-CryptoWall-3.0-from-malspam-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/11/2015-06-11-CryptoWall-3.0-from-Angler-EK-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/11/2015-06-11-CryptoWall-3.0-malware.zip

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

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

References:

[1] http://malware-traffic-analysis.net/2015/06/04/index.html
[2] http://malware-traffic-analysis.net/2015/06/09/index2.html
[3] http://malware-traffic-analysis.net/2015/05/26/index.html
[4] https://isc.sans.edu/diary/Angler+exploit+kit+pushing+CryptoWall+30/19737
[5] http://malware-traffic-analysis.net/2015/06/09/index.html

Thanks to Rob for reminding me of IPv4 auction websites again. I looked at them a couple years ago, but there was very little real activity at the time. Looks like that has changed now. ARIN is essentially out of IPv4 space, and very restrictive in handing out any addition addresses. It has gotten very hard, if not impossible, to obtain a larger block of IPv4 space. So no surprise that markets for IPv4 space are coming up. 

These markets are not in line with registrar policies [1]. If someone receives an IP address assignment, then they don't technically "own" the addresses. Once they are no longer needed, they are supposed to be returned to ARIN to be handed to the next applicant in line. But there has been little enforcement, and there have always been grey areas. For example, a company may buy another company, and in the process obtain access to that companies IP address space. Later, assets other then the IP address space could be sold off, leaving the buy with the rights to the IP address space.

Here are some of the sites offering IP address space (I am not endorsing them, and have no idea how "real" they are):

- ipv4auctions.com. Currently three offers for space up to a /20 at $7-$10 per address. There are a couple of bids.
- ebay.com. There are a number of auctions with IP addresses for sale and for rent. Looks like they are going for about the same price as the addresses at ipv4auctions.com [2]

Some sites have dones so in the past, but already shut down (e.g. tradeipv4.com). In other cases, the nanog mailing list was used to offer IP address space, or IP addresses were purchased as part of bankruptcy auctions [3]

[1] http://www.internetsociety.org/internet-society-open-letter-transfer-internet-protocol-addresses
[2] http://www.ebay.com/itm/IP-Address-22-Routable-IP-Block-Four-Class-C-For-Sale-or-Rent-/181769443467?pt=LH_DefaultDomain_0&hash=item2a524d988b
​[3] http://www.maximumpc.com/borders-sells-65536-ipv4-addresses-for-12-each/​

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

Shared hardware has always been a weakness of virtualization products. In some cases side channel attacks can be exploited to collect information from other virtual machines, or bugs in drivers can be exploited to fully escape a virtual machines, like recently with floppy disk drivers. [1] [2]

The latest variation of this is an attack against VMWare Workstation taking advantage of "COM1". This serial port is configured by default and used for printer sharing. Using printer sharing, the user can access a printer connected to the host [3].

To implement this feature, VMWare uses "vprintproxy.exe". This executable receives the file to be printed from the guest, and passes it to the host's printer.  The guest uses the serial port COM1 to send data vprintproxy.exe. The data is sent to vprintproxy.exe as an "Enhanced Metafile Spool Format" file, or "EMFSPOOL" file for short. Sadly, vprintproxy.exe does not parse these files safely, and crafted files can lead to exploits against vprintproxy.exe, which runs as whatever user started VMWare. 

This is a threat to VMWare Workstation. In particular if you are using VMWare Workstation to analyze malicious code, you should be extra careful. VMWare released a patch yesterday, but you may have missed it among other patch Tuesday issues.

[1] http://arstechnica.com/security/2015/05/extremely-serious-virtual-machine-bug-threatens-cloud-providers-everywhere/
[2] https://eprint.iacr.org/2014/248.pdf
[3] https://docs.google.com/document/d/1sIYgqrytPK-CFWfqDntraA_Fwi2Ov-YBgMtl5hdrYd4/preview?sle=true#heading=h.dv8d1g4lp83q

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

Overview of the June 2015 Microsoft Patches and their status.

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

Most of the time, if a web application gets compromised, we hear about vulnerabilities like cross site scripting or SQL injection being used to gain access. However, many high profile web application defacements don't need tools like sqlmap or BeEF. Instead, the attacker just logs in as an administrator. The log in may not necessarily use the web application at all, but it may affect the infrastructure the application relies on:

Operating System

It may be as easy as a default login to the system. A weak password, or a password collected via phishing. Your best defence in this case is to limit how many individuals have access to the system, to use non-password based authentication schemes (two-factor... ), and to restrict logins to trusted networks. Nobody should be able to log in to your server via ssh using nothing but a password from anywhere in the world. A missing patch apparently lead to the large OPM breach.

Cloud Admin Consoles (private or public)

Same as above. But sadly, also often overlooked. Many cloud providers will offer two factor authentication. And your backups should certainly not be hosted in the same "cloud" as the live systems. Private cloud admin interfaces are usually a bit easier to secure and isolate. But that doesn't mean it is actually done. I do see many papers about the latest Virtual Machine Escape technique. But the technique I see used in the wild the most is far less advanced: Log in to the admin console and download the server you are interested in compromising. "Secure" code hosting company Code Spaces no longer exists as a result of a breach of its Amazon cloud accounts.

Content Delivery Networks (CDNs)

Most large sites use CDNs to deal with traffic spikes, and to defend against common denial of service attacks. What else does an attacker need but credentials to log into the CDNs admin console to alter your site "at will". Did I mention two-factor authentication already? The Army.mil account has been attributed to a compromise of a CDN admin account.

Domain Name Registrars

This may be the most common route used to deface large, otherwise secure, web applications. But a defacement isn't what you should be scared about most. What about someone adding MX records and intercepting your e-mail? What about someone adding a record for "login.example.com" to use in a very plausible phishing attack? A lot has been written about DNS spoofing and cache poisoning. But why use a difficult technique like this if all you need to do is logging in. The list of recent attacks using this technique is rather long and includes household names like Craigslist, NY Times, Twitter and more.

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

I know we’ve talked about NoScript here before, however it is something worth discussing on a regular basis, as it is a simple, solid product that works.  Whenever I build a new desktop or laptop, one of the first things that goes in is Firefox and NoScript as a solid browser combo to continue safely building out and running a system.  The choice of browser software is probably more a matter of personal choice, but a solid security addon for the browser is a must these days, and I have found NoScript to be a solid addon for Firefox.  It is stable, updated constantly (for which I am reminded on a regular basis when I open Firefox) and a product with a very long, proven track record.  One of the solid aspects of NoScript has been the ‘always block by default’ approach, ‘deny all/permit by exception’ philosophy that stops all scripts, and allows me to permit only the content I want or need.

Take a look at NoScript, let us know what you think in the comments, as well as any other addon musts for browsers.  

tony d0t carothers --gmail

Building automation Networks are very common today for intelligent buildings. They interconnect several type of devices like escalators, elevators, power circuits, heating, ventilating and air conditioning (HVAC) to the main control center. Since those devices are in the same location as computers and all other corporate devices, some companies place them in same network segments with all other user's devices. This could lead to a serious security problem, as it is wide known that many industrial protocols does not require the clients to authenticate for issuing commands or requesting data. If companies combine BACnet devices inside network segments with regular users, they will be able to attack the BACnet devices with no difficult. Only new version of those protocols are beginning to support authentication, confidentiality and integrity. It's important to follow the Purdue security model and separate building automation network devices from all other segments of the corporate network(check https://ics.sans.org/resources/ics-security-resource-poster):

BACnet is one of those industrial protocols. With the new version release of nmap, there is a new script that is able to check for devices supporting the BACnet protocol stack and gathers all possible information from it (vendor id, vendor name, instance number, firmware, application software, object name, model name, description and location).

Usage is pretty simple: since we need to target the BACnet port, a UDP scan must be launched to port 47808 of the target network segments where we are interested to locate BACnet devices (e.g. 10.90.1.0/24). The command to launch the script is nmap --script bacnet-info -sU -p 47808 10.90.1.0/24. If any BACnet device is located, you will see something analog to the following text:

47808/udp open  bacnet
| bacnet-discover:
|   Vendor ID: BACnet Stack at SourceForge (260)
|   Vendor Name: BACnet Stack at SourceForge
|   Instance Number: 260001
|   Firmware: 0.8.2
|   Application Software: 1.0
|   Object Name: SimpleServer
|   Model Name: GNU
|   Description: server
|_  Location: USA

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

Fyodor has announced the release of Nmap 6.49BETA1.This version will have hundreds of improvement, including:
 

•  Integrated all of the latest OS detection and version/service detection submissions (including IPv6)
•  Infrastructure improvements: an official bug tracker
•  Added options --data and --data-string to send custom payloads in scan packet data.
•  25 new NSE scripts (total is now 494):

      o  bacnet-info gets device information from SCADA/ICS devices via BACnet (Building Automation and Control Networks)

      o   docker-version detects and fingerprints Docker
      o   enip-info gets device information from SCADA/ICS devices via EtherNet/IP
      o   fcrdns performs a Forward-confirmed Reverse DNS lookup and reports anomalous results
      o   http-avaya-ipoffice-users enumerates users in Avaya IP Office 7.x systems.
      o   http-cisco-anyconnect gets version and tunnel information from Cisco SSL VPNs
      o   http-crossdomainxml detects overly permissive crossdomain policies and finds trusted domain names available for purchase
      o   http-shellshock detects web applications vulnerable to Shellshock (CVE-2014-6271).
      o   http-vuln-cve2006-3392 exploits a file disclosure vulnerability in Webmin.
      o   http-vuln-cve2014-2126, http-vuln-cve2014-2127, http-vuln-cve2014-2128 and http-vuln-cve2014-2129 detect specific vulnerabilities              in Cisco AnyConnect SSL VPNs
      o   http-vuln-cve2015-1427 detects Elasticsearch servers vulnerable to remote code execution.
      o   http-vuln-cve2015-1635 detects Microsoft Windows systems vulnerable to MS15-034
      o   http-vuln-misfortune-cookie detects the "Misfortune Cookie"    vulnerability in Allegro RomPager 4.07, commonly used in SOHO                    routers for TR-069 access.
      o   http-wordpress-plugins was renamed http-wordpress-enum and extended to enumerate both plugins and themes of Wordpress                       installations and their versions. http-wordpress-enum is now http-wordpress-users.
      o   mikrotik-routeros-brute performs password auditing attacks against Mikrotik's RouterOS API.
      o   omron-info gets device information from Omron PLCs via the FINS service.
      o   s7-info gets device information from Siemens PLCs via the S7 service, tunneled over ISO-TSAP on TCP port 102.
      o   snmp-info gets the enterprise number and other information from the snmpEngineID in an SNMPv3 response packet.
      o   ssl-ccs-injection detects whether a server is vulnerable to the SSL/TLS CCS Injection vulnerability (CVE-2014-0224)
      o   ssl-poodle detects the POODLE bug in SSLv3 (CVE-2014-3566)
      o   supermicro-ipmi-conf exploits Supermicro IPMI/BMC controllers.
      o   targets-ipv6-map4to6 generates target IPv6 addresses which correspond to IPv4 addresses mapped within a particular IPv6 subnet.
      o   targets-ipv6-wordlist generates target IPv6 addresses from a wordlist made of hexadecimal characters

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

http://seclists.org/nmap-announce/2015/2

Introduction

Security Operation Center (SOC) analysts investigate alerts on suspicious network activity.  However, these analysts might not run across exploit kit (EK) traffic that often.  An organization's web gateway can stop a great deal of bad traffic before you see a full infection chain.  Investigating other types of suspicious activity will likely take up the majority of an analyst's workday.

Some of us are lucky enough to review EK traffic on a routine basis.  What that in mind, I want to share examples of the most common exploit kits I've noticed so far this year.

In order, the EK traffic I've seen most often in 2015 has been:

• Angler
• Fiesta
• Nuclear
• Neutrino
• Magnitude
• Rig

This isn't a comprehensive list.  Other exploit kits are out there, but these are most common that I've seen this year.  I don't have any hard numbers, and the last four (Nuclear, Neutrino, Magnitude, and Rig) are more of an educated guess for the ranking.  The EK scene can evolve fairly quick.  The list will likely change within a few months, and my observations are only one person's view.

Angler EK

Angler is the most common exploit kit I run across.  It's also the most advanced.  Angler changes URL patterns frequently, and these changes have recently happened on a near-daily basis.  Angler started using "fileless" infection techniques in 2014 [1], and it now sends its payload in a fairly sophisticated encrypted manner (meaning it doesn't use a straight-forward ASCII string to XOR the payload when it's sent over HTTP).  In recent months, I've had a hard time obtaining the payload from Angler EK.  In the example for this diary, I wasn't able to obtain or decrypt the payload.

Previously, I've seen Angler sending some form of ransomware like the TeslaCrypt/Alpha Crypt variants [2] or CrytoWall 3.0 [3].  In the past few days, I've mainly seen Bedep and related payloads sent by Angler.

• An example of Angler EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Angler EK traffic and post-infection activity on Wednesday 2015-06-03.

Fiesta EK

Fiesta is probably the next-most common exploit kit I've run across, most of it related to the BizCN actor that I described in a previous diary [4].  Other actors certainly use this exploit kit.  Like Angler EK, Fiesta also uses a more sophisticated type of encryption when sending the malware payload.  Fortunately, I can usually grab a copy of the payload from an infected host in my lab or decrypt the payload when necessary.

• Example 1 of Fiesta EK traffic on 2015-06-03: click here for the pcap file.
• Example 2 of Fiesta EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Fiesta EK traffic on Wednesday 2015-06-03.

Magnitude EK

Magnitude EK often sends several payloads, sometimes 6 or more.  It's a very noisy exploit kit.  I'll often see CryptoWall 3.0 as one of the payloads.  In the example for this diary, Magnitude only sent one payload, and that was CryptoWall 3.0.  I've usually seen Magnitude EK send the malware payloads unencrypted, at least when using IE 8 as a web browser in the vulnerable host.  I don't see Magnitude now as much as I did last year.

• An example of Magnitude EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Magnitude EK traffic and post-infection activity on Wednesday 2015-06-03.

Neutrino EK

In 2014, this exploit kit disappeared for about six months then came back in a much different form [5].  Traffic patterns have remained relatively unchanged since it reappeared in late 2014.  Neutrino EK uses a more sophisticated style of encryption when sending the malware payload (not merely a straight-forward XOR using an ASCII string).

Neutrino's current URL patterns remind people of Sweet Orange EK; however, Sweet Orange seems to have disappeared from the scene back in February of 2015.  I haven't found any Sweet Orange after February, but I've seen plenty of Neutrino since then.  If you see recent traffic you think is Sweet Orange, double check it.  It's probably Neutrino EK.

Neutrino has been relatively consistent over the past few months.  Haven't seen a lot of it, but it's never gone away.

• An example of Neutrino EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Neutrino EK traffic on Wednesday 2015-06-03.

Nuclear EK

Last year, this exploit kit seemed much more common than it is today.  Operation Windigo still uses Nuclear EK [6], but in recent weeks, I've rarely seen Nuclear outside of that.  Nuclear EK obfuscates its payload by XOR-ing it with an ASCII string.

• An example of Nuclear EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Nuclear EK traffic and post-infection activity associated with Operation Windigo on Wednesday 2015-06-03.

Rig EK

When Rig first appeared in 2014, it looked remarkably similar to Infinity EK [7] (which was first identified as Goon EK).  Rig EK apparently borrowed a great deal from Infinity.  While I haven't seen Infinity this year, I've definitely run across Rig every once in a while.

In April 2015, Rig EK changed the encryption it uses for sending the malware payload.  Now, it uses the same method as Nuclear EK, obfuscating its payload by XOR-ing it with an ASCII string [8].

• An example of Rig EK traffic on 2015-06-03: click here for the pcap file.

Shown above: Rig EK traffic on Wednesday 2015-06-03.

Final words

As mentioned earlier, this is merely one person's view into the current state of exploit kits.  It's not comprehensive, and there are other exploit kits I don't have visibility on.  Here's a list of pcap files from the previous paragraphs:

• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Angler-EK-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Fiesta-EK-traffic-example-01.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Fiesta-EK-traffic-example-02.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Magnitude-EK-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Neutrino-EK-traffic.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Nuclear-EK-traffic-Operation-Windigo.pcap
• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-Rig-EK-traffic.pcap

I've also collected the exploits and malware payloads where I could.  A zip file with this collection is available at:

• http://malware-traffic-analysis.net/2015/06/03/2015-06-03-malware-samples.zip

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

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

References:

[1] http://malware.dontneedcoffee.com/2014/08/angler-ek-now-capable-of-fileless.html
[2] https://isc.sans.edu/diary/Angler+exploit+kit+pushes+new+variant+of+ransomware/19681
[3] https://isc.sans.edu/diary/Angler+exploit+kit+pushing+CryptoWall+30/19737
[4] https://isc.sans.edu/diary/Actor+using+Fiesta+exploit+kit/19631
[5] https://isc.sans.edu/diary/Exploit+Kit+Evolution+Neutrino/19283
[6] http://www.rackspace.com/blog/in-2015-operation-windigo-is-still-going-strong/
[7] http://www.kahusecurity.com/2014/rig-exploit-pack/
[8] http://malware-traffic-analysis.net/2015/05/06/index2.html

Introduction

As early as Wednesday 2015-05-27, there have been more waves of malicious spam (malspam) spoofing myfax.com.  On Tuesday 2015-06-02, the messages contained links to a zip archive of a Pony downloader.  Tuesday's messages also had links pushing Neutrino exploit kit (EK).  Spoofed myfax emails are nothing new.  They've been around for years.  This is yet another wave in the continuous onslaught of malspam that organizations face every day.

Background

Earlier on 2015-06-02, @Techhelplistcom tweeted about myfax malspam he'd found [1], and he posted links from these emails to pastebin [2].  

I noticed similar messages last week, but they were all blocked.  At that time, I wasn't able to investigate any further.  On 2015-06-02, checking my employer's spam filters revealed spoofed myfax messages were coming in again after a 3 day break.

Details

Below is an example of the messages blocked by my organization's spam filters on 2015-06-02:

Shown above: myfax-themed malspam from Tuesday, 2015-06-02

The above example shows 2 types of URLs.  The first points to a zip file.  The second points to URLs ending in fax.php that push Neutrino EK.  Last week's malspam only had links to the zip files.

Shown above: myfax-themed malspam from Thursday, 2015-05-28

In a lab environment, those links ending with fax.php returned HTML with iframes leading to Neutrino EK.

Unfortunately, I wasn't able to generate any Neutrino EK traffic.  The domain names for the Neutrino URLs didn't resolve in the DNS traffic.

We saw the following fax.php URLs from the malspam: 

• chuotbu.com - GET /wp-content/plugins/feedweb_data/fax.php
• www.faura-casas.com - GET /wp-content/plugins/feedweb_data/fax.php 

We also found the following URLs for zip files from the malspam: 

• sv.com.vn - GET /wp-content/plugins/feedweb_data/pdf_efax_message_3537462.zip
• edenika.net - GET /wp-content/plugins/cached_data/pdf_fax_message238413995.zip
• edujay.com - GET /wp-content/plugins/cached_data/pdf_fax_message238413995.zip
• eciusda.org - GET /wp-content/plugins/cached_data/pdf_fax_message238413995.zip
• nightskyhotel.com - GET /wp-content/plugins/feedweb_data/incoming_myfax_doc.zip
• sciclubtermeeuganee.it - GET /wp-content/plugins/feedweb_data/pdf_efax_message_3537462.zip
• serenityonthesquare.com - GET /wp-content/plugins/cached_data/pdf_efax_message_3537462.zip
• vanepcanhcuong.com - GET /modules/mod_vvisit_counter/images/digit_counter/embwhite/pdf_efax_message_3537462.zip
• www.ditta-argentiero.it - GET /wp-content/plugins/feedweb_data/pdf_efax_message_3537462.zip

Here's what we saw in a lab environment when downloading the zip file, extracting the malware, and infecting a Windows host:

Click on the above image for a full-size view

Indicators of compromise (IOC) from the infection traffic:

• 112.78.2.223 - nightskyhotel.com - GET /wp-content/plugins/feedweb_data/incoming_myfax_doc.zip HTTP/1.1 
• 78.136.221.141 - moskalvtumane.com POST /gate.php HTTP/1.0 
• 94.73.151.210 - mechgag.com - GET /wp-content/plugins/feedweb_data/k1.exe HTTP/1.0 
• 87.250.250.8 - yandex.ru  - GET / HTTP/1.1 
• 93.158.134.3 - www.yandex.ru - GET / HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /confk.jpg HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /ki.exe HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /ki.exe HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com-  POST /gate.php HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /confk.jpg HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /ki.exe HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /ki.exe HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - POST /gate.php HTTP/1.1 
• 213.152.181.66 - dortwindfayer.com - GET /confk.jpg HTTP/1.1 

The image below shows Emerging Threats-based Snort events on the infection traffic using Security Onion.  The events indicate a Fareit/Pony downloader infected the lab host with Graftor or a Zeus/Zbot variant.

A sample of the Pony downloader was submitted to malwr.com at: https://malwr.com/analysis/ODExOWNlY2Y4N2QwNDhkNmE4YmFkODc2ODA3NzlkNDI/

A sample of the follow-up malware was also submitted to malwr.com at: https://malwr.com/analysis/OTc4MWY3OTdmZDZkNGYxMGJhNGRkMDAzOThlNmQ1NmI/

Post-infection traffic contains HTTP GET requests for a small image file with an image of Marlon Brando from the Godfather movies.  Matthew Mesa found some other URLs with (what I assume is) the same image [3].

The image contains some ASCII text for the last 1.4 KB or so of the file, which indicates steganography is being used to send some information to the infected host.

Final words

A pcap of the 2015-06-02 infection traffic is available at:

• http://malware-traffic-analysis.net/2015/06/02/2015-06-02-myfax-malspam-infection-traffic.pcap

A zip file of the associated malware is at:

• http://malware-traffic-analysis.net/2015/06/02/2015-06-02-myfax-malspam-artifacts.zip

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

Special thanks to Techhelplist and Matthew Mesa for their Twitter posts about this activity.  Techhelplist also updated his blog entry about fake myfax emails with this recent information [4].

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

References:

[1] https://twitter.com/Techhelplistcom/status/605765844258287618
[2] http://pastebin.com/0WXz209K
[3] http://pastebin.com/x6U940wj
[4] https://techhelplist.com/index.php/spam-list/125-inbound-fax-fake-myfax-notification

[Guest Diary: Xavier Mertens] [Playing with IP Reputation with Dshield & OSSEC]

When investigating incidents or searching for malicious activity in your logs, IP reputation is a nice way to increase the reliability of generated alerts. It can help to prioritize incidents. Let's take an example with a Wordpress blog. It will, sooner or later, be targeted by a brute-force attack on the default /wp-admin page. In this case, IP reputation can be helpful: An attack performed from an IP address reported as actively scanning the Internet will not (or less) attract my attention. On the contrary, if the same kind of attack is coming from an unkown IP address, this could be more suspicious...

By using a reputation system, our monitoring tool can tag an IP address with a label like "reported as malicious" based on a repository. The real value of this repository depends directly of the value of collected information. I'm a big fan of dshield.org (https://www.dshield.org), a free service provided by the SANS Internet Storm Center. Such service is working thanks to the data submitted by many people across the Internet. For years, I'm also pushing my firewall logs to dshield.org from my OSSEC server. I wrote a tool to achieve this: ossec2dshield (https://github.com/xme/ossec2dshield). By contributing to the system, it's now time to get some benefits from my participation: I'm re-using the database to automatically check the reputation of the IP addresses attacking me. We come full circle!

To achieve this, let's use the API (https://isc.sans.edu/api/) provided on isc.sans.org and the OSSEC (http://www.ossec.net) feature called "Active-Response" which allows to trigger a script upon a set of conditions. In this example, we call the reputation script with our attacker address for any alert with a level >= 6.

Recently I made some small modifications to the Dshield Linux Cisco PIX submission perl script (https://www.dshield.org/clients/framework/cisco.tar.gz).  This allows anyone with an ASA or Cisco Security Manager(CSM) to submit logs to the project with ease.

1. Setup the ASA or CSM to syslog to a server. (http://bit.ly/1AF6vOv)

2. Edit the config of the dshield.cnf and place it into /etc/

   1. Note: If sending emails, you need a SMTP setup. This script does not have it built-in.

3. Setup a cron, to submit the logs.

Troubleshooting

• Initially it's best to have it cc you the logs so you can validate that everything is working via the dshield.cnf file.

• If using postfix, make sure that the message size limit is very high, as this will not attach a compressed file, it’s actually has the logs in the message of the email. Default size is 10MB

  • /etc/postfix/main.cf

  • message_size_limit =

• If the email goes through, check the ISC portal My Account -> My Reports. You should see when you last submitted logs. This may lag behind several hours before the website updates, so don’t worry on first submission if it takes a bit.

Now get submitting your logs!

--

Tom Webb