Earlier today, various sources reported a highly-suspicious Windows update.  According to Ars Technica, a Microsoft spokesperson stated the company had incorrectly published a test update and is in the process of removing it [1].  The update is no longer available, and ZDNet has confirmed this was a test update "gone errant" [2].

Shown above: A screenshot someone posted on a Microsoft community forum [3].

Thanks to everyone who notified us at the ISC.  See the references below for further information.

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

References:

[1] http://arstechnica.com/security/2015/09/nerves-rattled-by-highly-suspicious-windows-update-delivered-worldwide/
[2] http://www.zdnet.com/article/microsoft-accidentally-issued-a-test-windows-update-patch/
[3] https://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-appears-to-be-compromised/e96a0834-a9e9-4f03-a187-bef8ee62725e​

Very often I get questions on how to perform analysis on DLL files.

The reason being that it is easier to perform behavioral analysis on executables, either using external sandboxes or a vmware with tools like the ones from the Sysinternals suite .

For DLL, on most of times, you can't just run them, you can use windows applications like rundll32 with right the export, but sometimes it may not work. 

At this point if you want something fast to perform some analysis on the DLL you can go for the static analysis, looking for the strings and trying to determine the nature of the malware.

The problem resides on fact that most malware these days are using custom packers, making your job more difficult.

The quick and dirty solution for this would be to force it to memory so it would unpack itself. That would make your job much easier by just using a process dump tool and then check the strings.

Something that I used to do to accomplish it was to use regsvr32 to "load" the DLL on memory. It will throw an error on most cases, but the DLL will be loaded, until you close the error message.

On that period of time, you can use your preferred dump tool and dump the regsvr32 process, and check the DLL strings.

Another way is to simply inject the DLL into a running process, like explorer.exe for example. This simple python script inspired by the Grey Hat Python book seems to do the job quite well!

Simply run it by passing the PID you want to inject the DLL and the DLL file as parameters and it will work.

For example:

python dll_inject.py 618 badll.dll  

--> This will inject the baddll.dll into process ID 618. 

To find the process ID you can either use tools like Sysinternals process explorer or Windows Task Manager. 

Good luck!

------

Pedro Bueno (pbueno /%%/ isc. sans. org) 

Twitter: http://twitter.com/besecure

This morning, I received several e-mails with the subject "Email from Transport of London". The attacker even picked a plausible "From" address with noresponse@cclondon.com. This domain is used by Transport of London for information about London's congestion charge. 

The domain does have an SPF record defined, making it easy to reject the emails as spam:

v=spf1 include:spf.messagelabs.com -all

This SPF record would allow all hosts listed in Messagelab's SPF record to send e-mail on behalf of cclondon.com. Interestingly, the e-mail seems to include a fake "Received" header, listing a "cclondon.com" host as part of the received chain:

Received: from 151.161.27.77.dynamic.mundo-r.com (151.161.27.77.dynamic.mundo-r.com [77.27.161.151])

    by mail.dshield.org (Postfix) with ESMTP id B11E07FE0C;

    Mon, 28 Sep 2015 09:40:21 +0000 (UTC)

Received: from cclondon.com (tfldxmqmp63-svc [10.130.182.150])

    by tfldcpopp21.cclondon.com (Postfix) with ESMTP id 367DFD536

    for ; Mon, 28 Sep 2015 10:39:59 GMT

Since my server (mail.dshield.org) states that it received the e-mail directly from 77.27.161.151, an apparently home user system, I doubt the second Received header is real.

These emails do not only target Londoners, but appear to also use Subject lines like:

"Toll road bill notice"
"Outstanding toll road payment notice"

The London Transport one was however the only one I saw that played the trick with a valid looking From address.

Sadly, anti-virus coverage for the obviously malicious attachment is dismal with 4 out of 55 on Virustotal (F-Secure being the only "name brand" AV recognizing it as a generic downloader). [1]

A quick screen shot of the entire message:

(click on the image for a full size view)

[1] https://www.virustotal.com/en/file/80237fc10155567a68163bfd5bbf0afc5cb521bfdd1d486e1c3682083b5f61f8/analysis/1443436044/

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

Firefox has announced several vulnerabilities in Firefox and Firefox ESR which were reported by Ronald Crane . The vulnerabilities has been fixed in Firefox 41 and Firefox ESR 38.

CVE-2015-4517: NetworkUtils.cpp in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors.(2)

CVE-2015-4521: The ConvertDialogOptions function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors (3)

CVE-2015-4522: The nsUnicodeToUTF8::GetMaxLength function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors, related to an "overflow."(4)

CVE-2015-7174 : The nsAttrAndChildArray::GrowBy function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors, related to an "overflow."(5)

CVE-2015-7175 : The XULContentSinkImpl::AddText function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors, related to an "overflow."(6)

CVE-2015-7176: The AnimationThread function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 uses an incorrect argument to the sscanf function, which might allow remote attackers to cause a denial of service (stack-based buffer overflow and application crash) or possibly have unspecified other impact via unknown vectors.(7)

CVE-2015-7177: The InitTextures function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors.(8)

CVE-2015-7180: The ReadbackResultWriterD3D11::Run function in Mozilla Firefox before 41.0 and Firefox ESR 38.x before 38.3 misinterprets the return value of a function call, which might allow remote attackers to cause a denial of service (memory corruption and application crash) or possibly have unspecified other impact via unknown vectors.(9)

       1-https://www.mozilla.org/en-US/security/advisories/mfsa2015-112

2-http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4517

3- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4521

4- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4522

5- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7174

6- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7175

7- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7176

8- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7177

      9- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7180

Cisco have released three patch bulletins today http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep15.html for issues affecting their IOS and IOS XE firmware.  The most intriguing one on the list is called "RSA based user authentication bypass vulnerability", and from the description, it sounds like key based SSH authentication can be successful "with a crafted private key" if the attacker "knows the userid and the associated RSA public key".  Well ... if it were readily possible to "craft" the private key out of a known public key, then most of our Internet crypto protocols would become invalid overnight. Hence, something else must be at the root of this problem, but what exactly, the advisory doesn't say. Probably something embarrassing, like another backdoor or default key.

Remember back in the ancient days, when macro viruses were rampant, and we security geeks instructed our flock of virus scared users to never click on a .DOC attachment in an email, but that a .PDF was perfectly fine?  Fast forward a couple years, and we had to tell the users, yes, .DOCs are still somewhat bad, but .PDFs are WAY worse.

It took a while to get that message across. What we call "security education" or "user awareness training" is hard enough, but nothing in it is more difficult than to make users unlearn an earlier awareness message, once it finally stuck with them.

Another example is WiFi. It looks like we were successful in bringing the point across that "open", unencrypted public WiFi is dangerous, because you have no idea who is listening in. This message stuck, to the extent that the average person today seems to firmly believe that a WiFi access point that requires a WPA2 password is not "open", and hence must be secure. It is, but only if you're the only one who has the password. But in a public setting, like an airport lounge or hotel, where the "password" is nicely displayed at the front desk, there is obviously nothing stopping an impostor to run his very own WiFi with the same SSID and the same password. And if that impostor has a strong signal, this is the Access Point that guests will connect to. Hence, in a public setting, a WPA protected access point only offers marginally more security than an open one. Both are equally exposed to a man in the middle impostor.

It looks though like most of us security professionals forgot to tell our users this when we originally instructed them to be careful with public WiFi. Et voila, we have on our hands another instilled behavior that we need to make them unlearn again.

There's plenty other examples like this, where our earlier "advice" comes back to bite us. Kicking myself in annoyance whenever I notice such a situation, I have started to look at "security awareness campaigns" with a different set of eyes. Awareness campaigns need a "risk analysis" of their own. For every "message" that we, as security professionals, push onto our users, we should ask ourselves:

1. Is this indeed the best (applicable, accurate and useful) lesson that we can teach
2. What would need to happen, in technology, process or behavior changes, to make this lesson useless or even harmful?
3. How likely is this to occur?
4. What is our mitigation when it happens?

There isn't always a good solution, but we at least need to start asking these questions, lest we just continue to teach our users the next future bad security behavior.

TLS (I still have to get used to saying TLS instead of SSL) everywhere is a goal many sites attempt to achieve. There are however issues if you try to convert an existing site to "all SSL". Many legacy pages may refer to resources by the full URL using the http protocol. For example, we keep finding image tags in old diaries on our site from time that are still pointing to http. 

Having a mix of secure and insecure content can be a problem. An attacker could manipulate the insecure content, and with that, affect the content the browser loaded securely. Rightfully so, browsers have become more picky when it comes to mixed content, and stopped displaying or executing some mixed content.

After you convert your site to https only, the first thing to do to reduce the impact of legacy http links is adding the "String Transport Security" header (HSTS). This header will let browsers know that your site is only valid via https, and browsers will refuse to connect to your site via http going forward [RFC6797]. 

HSTS does however not help if the browser comes across a page including insecure content. The warning regarding insecure content will still be displayed. A new technique, "Upgrade Insecure Requests" can be used instead.

All this is made possible by Content Security Policies (CSP). A new standard [1] defines a "upgrade-insecure-requests" option that will instruct the browser to rewrite all references for insecure content to https. This way, the mixed content warning will no longer be displayed.

The advantage of this method is that you do not have to update the content of the pages. If you run a site with thousands of legacy pages (like us), it can be difficult to find and fix every last image and script reference. Instead, we let the browser handle it and all we have to do is to add the header to our server configuration.

To enable this feature, add the "Content-Security-Policy: upgrade-insecure-requests" header,or a <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> meta tag. As an added bonus, if a reporting URL has been defined for the CSP violation, it will be reported to the site and remaining insecure content can be eliminated. The header of course should not prevent you from cleaning up your site.

According to caniuseit.com, this option is currently supported in Chrome and Opera with support in Firefox coming [2]. It is marked as "under consideration" for Internet Explorer.

Thanks to Caleb for alerting me about this new option. Caleb also collect HTTP headers as a hobby at https://securityheaders.com .

[1] http://www.w3.org/TR/upgrade-insecure-requests/
[2] http://caniuse.com/#feat=upgradeinsecurerequests

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

End of last week, Palo Alto Networks published information about the "XCodeGhost" malware. Johannes already talked about it in today's podcast episode but I searched for more details about this story. Apple is known to be very strict with its application validation process. Every time a developer submits a new (or an updated) app, it must pass multiple security checks. Why so many applications infected by XCodeGhost successfully passed them? Could we imagine that Apple has some kind of trust with reputed developers or popular applications? Until now, ~50 applications have been reported vulnerable and mainly used in China. But some are popular worldwide like WeChat.

The XCodeGhost has be published by its author on github and a quick analyze shows that the following information is sent to a unique URL via a HTTP POST request:

The following information is sent to the server:

• Application name
• Application version
• OS version
• Language
• Country
• Developer info
• Application installation type
• Device name
• Device type

​The FQDN init.icloud-analysis.com does not resolve anymore but it resolved to the following IP addresses (from the VT Passive DNS):

How to detect infected devices?

If you're an iPhone user:

• Check for HTTP traffic to http://init.icloud-analysis.com in your firewalls or proxies logs.
• Check for traffic to the IP addresses listed above.
• Remove the apps listed as malicious.
• Change passwords on websites used by the malicious applications.

If you're a developer:

• Check if the file Library/Frameworks/CoreServices.framework/CoreService exists in the Xcode SDK/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/.
• Always download resources from official locations and double-check the provided hashes (MD5/SHA1).

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

Testssl project has announced the release of testssl 2.6. testssl.sh is a free command line tool which checks a server's service on any port for the support of TLS/SSL ciphers, protocols as well as recent cryptographic flaws.

Here is some examples of how to use testssl.sh:

First you have to download the script from:

https://testssl.sh/

Running the script without any option will run all the tests:

testssl.sh google.com

If you like to check for a specific vulnerability such as heartbleed you can run the following option

testssl.sh -B isc.sans.edu

To check the supported ciphers suites you can use the –f option:

./testssl.sh –f Microsoft.com

Another neat option is –H which will give you some information about the http header and it will mark the security features

./testssl.sh –H isc.sans.edu

While speaking with a customer, he complained about the huge number of privileged users having domain admin rights in his network. It seems to be a recurrent problem for him: The security team reviews all the users at a time t and it reduces the number of privileged accounts to the strict minimum. But quickly, the number of administrators is growing again and, at time t+x, they have to restart the cleaning process. Amongst the SANS 20 Critical Security Controls, the point #12 focuses on controlling administrative privileges. The following controls are already in place by the customer:

• Auditing privileged accounts usage
• Auditing privileged accounts changes (creation, removal)
• Strong password policy

Unfortunately, the control #7 (CSC 12-7) remains a pain: the utilization of privileged accounts for non-administration tasks like reading e-mails or surfing the web. As most of the controls remains technical, a suggestion was to add a extra layer of awareness for administrators to remind them that using privileged accounts can be dangerous. Instead of simply displaying a warning message, the idea was to force the administrator to describe (log) in a few words why he started an administrator session. The information is logged and can be used later to generate activity reports from their SIEM like this example:

Not valid, funny or empty reasons can we investigated case by case improving the control of privileged users.

There are commercial solutions which implement this like Cyber-Ark or Digital Guardian. I wrote a PowerShell script which can be deployed as a logon script. Details are available on my blog.

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

Maybe you read my PDF + DOC malicious document diary entry, or maybe even you tested your system with my PDF + DOC test file, and maybe you wondered if you could change Adobe Reader's behavior.

Well, no more "maybes": you can. Years ago, when PDF malware was the most widespread malicious document type, disabling JavaScript in Adobe Reader was a recommendation.

But you can also prevent Adobe Reader from opening embedded files and launching the associated application. Here is the setting in the Trust Manager to do this:

And if PDF attachments are important in your organization, this setting will not prevent attachments from being saved (extracted). Only from being launched from within Adobe Reader.

I also have a video showing the effects of this setting (plus the JavaScript setting).

Didier Stevens
Microsoft MVP Consumer Security
blog.DidierStevens.com DidierStevensLabs.com
My YouTube Channel

As a professional penetration tester I often get asked questions like "What are the top 10 tools you use" or "How do you get to be a pentester". Since I become a SANS instructor more and more these questions come from media and they get to reword my responses to make their story. I would like to post here my direct and accurate answers to some of of questions I have been asked recently.  

Q: What are the top five skills that a penetration tester must possess?
A: Interesting question in that we tend to think in terms of a single lone wolf penetration tester, when the truth is that the best engagements are run with teams. Some of the skills that are required on that team are project management, creativity, being methodical, analysis, and writing. They will all need an extensive background in information security, and tend to be very technical in their areas of expertise. Team membership will vary based on the specifics of each engagement, expertise in network testing is not as useful in a wireless or web application test. 

Q: Are there typically broad steps that a pen tester follows? Like a playbook that they follow? What do these steps look like?
A: Penetration testers tend to all follow the same high level methodologies, often tailored for a specific organization or engagement. Many of them are free and available for download. Examples are the SANS PenTest methodology, the Open Source Security Testing Methodology Manual (OSSTMM), Open Web Application Security Project (OWASP) Testing Guide, and NIST Technical Guide to Information Security Testing and Assessment SP 800-115. The steps are generally:
- planning and logistics;
- reconnaissance and intelligence gathering ;
- identification and enumeration of targets;
- vulnerability assessment and validation;
- exploitation;
- post exploitation - pillaging and pivoting; and
- analysis and report writing. 
A superlative pentester knows when to exactly follow the methodology and derived checklist, and when to get creative and document where the team goes off the path. 

Q: What three tools are typically first in a pen tester's arsenal?
A: It really depends on the scope and nature of the engagement. The only required tool is the matter most people have between their ears. As my friend James Jardine puts it " I thought it was just a mindset? The rest is just pretty accessories". The honest answer is a web browser to do the recon and information gathering, a project management tool for scheduling, and a database to track target data in. Probably not the sexy answers you were expecting. For Internet based testing a port scanner such as massscan, nmap or unicornscan, a vulnerability scanner such as OpenVas or Tenable Nessus, and an exploitation kit such as Core Impact Pro or Metasploit. For web applications, wireless, or other forms of testing the tools are quite different. 

The real ingredients for a successful penetration test by a good team are people, process, and technology. 
–People with the training, painstaking attention to detail, experience, analysis skills, and creativity to emulate attackers in a controlled professional manner.
–Process includes determining the rules of engagement, project management, logistics, scope, policies, procedures, and methodology of the pentest. 
–Technology. Finding the tools is not difficult, often they are free and open source readily available for download by anyone. In the hands of a skilled penetration tester they are incredibly useful. In the hands of a wannabe they are a disaster waiting for a place to happen. 

Q: What is the single biggest mistake that a pen tester can make?
A: Violating the rules of engagement or going out of scope. The rules of engagement include the laws and ethical guidelines as well as those types of tests that are allowed to be performed in that engagement. The scope are those things that you are allowed to test in that engagement. Going out of bounds on either of these can not only be career limiting, but also freedom limiting. When in doubt always go back to the written rules of engagement and scope. Ask for clarification or modification if required. There is no cheating in penetration testing. Only those things that are illegal, immoral, unethical, or illogical.  

I have always described penetration testing as attempting to find an alternative functionality or data. Or identifying an alternative method of accessing functionality or data. Both of these are often not placed there deliberately, but they sure are handy.  

I am never quite certain how to respond to the question of how to become a penetration tester. Honestly, it seemed to have found me as a career. My first degree is in political science. However my true interest has always been in exploring new ideas, and playing with things until they broke. Most people I know have found many different paths to this one. The many creative arts and scientific methods required in a team make for eclectic mixes of people that's for sure!

Please let us know what you think are the tools, techniques, and skills required for penetration testing!

Cheers,
Adrien de Beaupré, @adriendb #bsidesottawa
Intru-shun.ca Inc.
If you are in Ottawa or can be nearby and enjoy information security check out bsidesottawa.ca! The conference is 2-3 October 2015.
I will be teaching penetration testing next in Dubai, Florida, and at the Hackfest!

2015-09-16 update:  Paul Burbage at Phish Me also published a write-up about this on Friday 2015-09-11 at: http://phishme.com/a-peek-inside-an-affiliates-malspam-operation-kovter-and-miurefboaxxe-infections/

Introduction

On 2015-07-29, the ISC published a diary covering malicious spam (malspam) with zip archives of javascript (.js) files [1].  Since then, we've received notifications from others who have found this type of malspam.  Let's revisit the spam filters, search for this type of email, and see if anything has changed.

Background

Although zipped .js attachments in malspam is nothing new, we noticed a significant increase since January 2015.  This appears to be botnet-based malspam, and we've noticed different payloads as the second-stage download after running the .js file.

A few points to make, before we proceed:

• This malspam appears to target Windows computers.
• The extracted file is Javascript-based, and the infection requires user action.
• The user must open the zip attachment, extract the .js file, and manually run the .js file.
• A properly-administered Windows host using software restriction policies should prevent an infection.
• A properly-administered spam filter will prevent this type of malspam from reaching the recipient's inbox.

As long as your organization's network is administered correctly, there's no real chance of infection.  Which begs a question.  Why do we still see this malspam every day?

The answer?  We assume enough people get infected, so sending .js malspam is profitable for the criminals behind this operation.  Why else would we still see it?

The malspam

We searched our spam filters for the past week and found five different themes used for this malspam:

• American Airline e-tickets
• Charge for driving on a toll road
• FedEx delivery notification
• IRS tax refunds
• Notices to appear in court

The ones we've discovered so far have all been plain-text messages with zip attachments containing .js files.  They're fairly easy to identify.

Shown above: A list of some .js malspam caught by our spam filters during the past few days.

Below are screenshots showing some of the themes we saw from this malspam during the past week:

We gathered eight malspam examples from the past few days.  Details follow: 

Date: Thursday, 2015-09-08 11:44 UTC
From: E-ZPass Manager ( arnold.savage@199.195.117.231.static.a2webhosting.com )
Subject: Payment for driving on toll road, invoice #00000893738
Attachment: E-ZPass_00000893738.zip - MD5 hash: 687141bd2a548889cd2cd7c59c5cd425
Extracted file: E-ZPass_00000893738.doc.js - MD5 hash: e1d4b1ec9717ae9aed02c1c5395ffc1b

Date: Tuesday, 2015-09-08 23:38 UTC
From: FedEx Ground ( armando.madden@liastudio.ru )
Subject: Courier was unable to deliver the parcel, ID00524666
Attachment: Delivery_Notification_00524666.zip - MD5 hash: 06868d58f113c9b746acfbf51b25b1a8
Extracted file: Delivery_Notification_00524666.doc.js - MD5 hash: 1ad9f4f8e051fa5bada2c1b57dbc5c24

Date: Thursday, 2015-09-10 07:45 UTC
From: District Court ( glen.bartlett@judcred.org.br )
Subject: Notice of appearance in Court #00000516375
Attachment: 00000516375.zip - MD5 hash: 2403b4b255ca3b84e0ff4fd43b8b6c99
Extracted file: 00000516375.doc.js - MD5 hash: 06b5e08e8c943d8440baf4148bd2b14f

Date: Saturday, 2015-09-12 21:52 UTC
From: America Airlines ( orders@aa.com ) - spoofed sender
Subject: Ticket information regarding your order #000735142
Attachment: 00735142.zip - MD5 hash: 85605e67e3afdfc2b9d8d0864b1f0891
Extracted file: 000735142.doc.js - MD5 hash: b4a2d86ee289780ea42882bdcfbf22c8

Date: Monday, 2015-09-14 23:15 UTC
From: Internal Revenue Service ( office@irs.gov ) - spoofed sender
Subject: New payment for tax refund #0000333948
Attachment: Refund_Payment_Details_0000333948.zip - MD5 hash: 54f889567831ed6ae987ef7afb225796
Extracted file: Refund_Payment_Details_0000333948.doc.js - MD5 hash: 733d87c6703bcaf2639a08bb7a011e3e

Date: Tuesday, 2015-09-15 06:03 UTC
From: ( quadernc@webhosting1100.interserver.net ) on behalf of Internal Revenue Service ( office@irs.gov )
Subject: New payment for tax refund #000346071
Attachment: Refund_Payment_Details_000346071.zip - MD5 hash: 774e8165338e3d06b7bf192951308148
Extracted file: Refund_Payment_Details_000346071.doc.js - MD5 hash: 5483e0b8a4ef2ade0f5b1e0d085ef2a3

Date: Tuesday, 2015-09-15 11:20 UTC
From: Internal Revenue Service ( office@irs.gov ) - spoofed sender
Subject: Payment for tax refund #000200199
Attachment: Tax_Refund_000200199.zip - MD5 hash: 652a1bf18ef1a914cbbe91fde63c98d6
Extracted file: Tax_Refund_000200199.doc.js - MD5 hash: ec3de6bcb421d482242d95b055f49ce0

Date: Tuesday, 2015-09-15 13:03 UTC
From: Internal Revenue Service ( office@irs.gov ) - spoofed sender
Subject: Payment for tax refund #00000106406
Attachment: 00000106406.zip - MD5 hash: 079c91fce37f0b2ec37178795455e43a
Extracted file: 00000106406.doc.js - MD5 hash: 0835c11379f639ec460bce73703cfe3a

The attachment

Extract the .js file from the zip archive, and you'll still find highly-obfuscated javascript.  Just like last time, this is merely a javascript-based file downloader.

We executed several of the .js files on a Windows host so we could find URLs for the follow-up malware.  Below is a Wireshark display of traffic we generated.

IP addresses and domains hosting the follow-up malware were:

• 64.239.115.111 - 64.239.115.111 (no domain name)
• 67.195.61.46 - ayuso-arch.com **
• 66.147.242.176 - bisstt.com
• 199.175.49.19 - crossfitrepscheme.com
• 72.20.64.58 - dickinsonwrestlingclub.com
• 174.36.231.69 - dominaeweb.com
• 96.31.36.46 - idsecurednow.com
• 50.116.104.205 - ihaveavoice2.com **
• 208.43.65.115 - laterrazzafiorita.it
• 76.74.242.190 - les-eglantiers.fr
• 23.91.123.160 - leikkihuone.com
• 174.137.191.22 - selmaryachtmarket.com **
• 69.89.31.73 - syscomm.smartlanka.net

NOTE: Domains with ** hosted malware for other .js malspam as noted in our previous diary covering this subject on 2015-07-29.

The traffic

We infected a Windows host in a lab environment with the most recent sample of .js malware, 00000106406.doc.js (MD5 hash: 0835c11379f639ec460bce73703cfe3a).  This provided a full infection chain of traffic.  Like last time, three .exe files were downloaded by the .js file.  Post infection traffic triggered alerts for Corebot, Miuref/Boaxxe, and Kovter.B malware.

Click on the above image for a full-size view.

Below are alerts on the infection traffic using Security Onion with the EmergingThreats signature set.

HTTP GET requests for the three .exe files happened first.  All were identified as .gif images in the HTTP response headers, but they were clearly executable files.  

Feel free to dig into the traffic for more details.  A link to download the pcap is included in the final words for this diary.

The malware

Below are samples of .exe files downloaded to our infected lab host:

File name:  2015-09-15-js-malware-first-download.exe

• File size:  305.0 KB ( 312,360 bytes )
• MD5 hash:  41959be39cf634fa4344396940d680c7
• SHA1 hash:  a4c6b301e62a67ba28d2ae4347093c80c25dac89
• SHA256 hash:  462a93d028eca2e116cf8818f6b299adba372895eeffb71f7ffbd95347f939fe
• Detection ratio:  12 / 56
• Virus Total link  -  Malwr.com link  -  Hybrid-analysis link

File name:  2015-09-15-js-malware-second-download.exe

• File size:  127.6 KB ( 130,680 bytes )
• MD5 hash:  56451b5b6ff6f9cbfeb221b80943f75f
• SHA1 hash:  298bc25dc9a55590ae002b255b384c478163d0c8
• SHA256 hash:  853b50ac132100c8176229d5144716b8b86033293bce4064ecfd7107cea8e3ec
• Detection ratio:  0 / 56
• Virus Total link  -  Malwr.com link  -  Hybrid-analysis link

File name:  2015-09-15-js-malware-third-download.exe

• File size:  453.5 KB ( 464,384 bytes )
• MD5 hash:  6b83ab0582fb59e89c090ec91b31db7a
• SHA1 hash:  06a8713fe2dacfc0d59345b0a3317154a961a68b
• SHA256 hash:  d567404c7ec78e23a5661fbc242d15107f9327a810ffc241c338e39487448979
• Detection ratio:  3 / 56
• Virus Total link  -  Malwr.com link  -  Hybrid-analysis link

Final words

We haven't noticed any significant change after comparing this malspam to our previous diary about it on 2015-07-29.  Assuming people continue to get infected by the malspam, we will likely continue to see it caught by our spam filters.  

Most spam filters prevent these messages from getting to their intended recipients, but filters are never a full-proof method.  As botnets continue trying to flood the world's inboxes with malicious content, we should always remain aware of the current threat landscape.

Below are links for the associated files.

A .csv spreadsheet with some dates, times (CDT), senders, and subject lines of the malspam for this diary:

• http://malware-traffic-analysis.net/2015/09/16/2015-09-16-ISC-diary-malspam-tracking.csv

A zip archive containing eight sanitized examples of the malspam (.eml files) used for this diary:

• http://malware-traffic-analysis.net/2015/09/16/2015-09-16-ISC-diary-eight-malspam-examples.zip

A pcap of the 2015-09-15 infection traffic:

• http://malware-traffic-analysis.net/2015/09/16/2015-09-16-ISC-diary-malspam-infection-traffic.pcap

A zip archive of the associated malware:

• http://malware-traffic-analysis.net/2015/09/16/2015-09-16-ISC-diary-associated-malware.zip

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

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

References:

[1] https://isc.sans.edu/forums/diary/Malicious+spam+continues+to+serve+zip+archives+of+javascript+files/19973/

I read an article yesterday about various stores and markets requiring a state-issued driver's license or identification as proof of identification for returns.  When the return is made,  identification is presented to the vendor, and it is scanned into their system to be stored with the transaction.  On the surface, this seems reasonable, except for scanning and *storing* the identification; now it is probably not such a good idea.  The vendor is now collecting more information than we would probably like to give, such as name, address, drivers license#, and other details, depending on the issuing state.

The need for identification, whether physical or virtual, is real.  Stores and markets most likely (not getting into the legal here) have some right to ask for a form of identification when conducting certain transactions, and I agree with that requirement.  30 years ago, when using a bank check to make a purchase, vendors would require a valid credit card, which they would write on the check. (youch)  The capture and storage of information, of which the consumer may not even be fully appraised of, is the issue here.

So we are here today to discuss ways we can do this better.  My initial thought was that a scan of the identification into the system, to read what is magnetically written, and display it on a screen for the merchant.  Compare that to what is printed and the photograph, and document the verification of ID was valid.  We still trust employees that work for us, so let’s leverage that.  In this we have a solution in which no information is stored, only displayed for the merchant to verify against what is printed.

I open the floor to any comments, questions, queries, quibbles, complaints, or concerns.  Mostly I am hoping for solutions thought.

tony d0t carothers --gmail

This morning, I had a quick look at my web server log file and searched for malicious activity. Attacks like brute-force generate a lot of entries and thus can be easily detected. Other scanners are working below the radar and search for very specific vulnerabilities. In this case, a single request is often sent to the server and generate a simple 404 error without triggering any alert. My blog being based on the Wordpress CMS, I searched for non HTTP/200 hits for plugins URLs ("/wp-content/plugins/")

CMS or “Content Management Systems” became vey popular today. It's easy to deploy a WordPress, Drupal or Joomla on top of a UNIX server. They exist also shared platforms which offer you some online space. If a CMS is delivered with standard options, it is easy for the owner to customize or to tune it.. just like cars. Modern CMS offer a way to extend the features or the look’n’feel via plugins (or add-ons or extensions).

From a security perspective, plugins are today the weakest point of a CMS. If most of the CMS source code is regularly audited and well maintained. It’s not the same for their plugins. By deploying and using a plugin, you install third-party code into your website and grant some rights to it.  Not all plugins are developed by skilled developers or with security in mind. Today, most vulnerabilities reported in CMS environment are due to … plugins!

Based on my logs, here are some stats for the last 3 months:

• 8000+ hits for uninstalled/non-existent plugins
• 899 unique plugins tested (list)

Just for information, here is my Top-20 of tested Wordpress plugins:

(1) Very popular exploit in the wild for a while

If you run your own CMS, here are some security tips regarding the use of plugins:

• Only install plugins that your really need.
• Some plugins can be configured. Always review the default settings and adapt them to your environment and security requirements
• When you tested a plugin and if you decide to not use it, disable and un-install it completely.
• If the popularity is a plugin is a good indicator, do not trust them! (Popularity != Security)
• Like any piece of software, update them
• Take a deep breath and jump into the code to have a quick code review (any backdoor installed?)
• WordPress has an hardening guide with good recommendations.

As a general advice regarding 4xx HTTP errors, do not implement checks for single errors but search for multiple 4xx (or 5xx) errors generated in a short amount of time from a single IP address. This is helpful to detect ongoing scans! (a log management solution can do that very easily)

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

No not from me, but from the UK government. 

GZ (thanks) sent a link through to this document https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/458857/Password_guidance_-_simplifying_your_approach.pdf published by the UK government.  

The document is a little bit different to many other such advise handed out by many organisations in that it is aimed more at system administrators rather than end users.  As far as the actual advise to system administrators.  It is nothing too revolutionary, but then we are dealing with passwords.  And there isn't anything there that most of us wouldn't agree with.  It does server as a little reminder that we should all be taking some care with passwords.  

The 7 tips are: 

1. Change default passwords
2. Help users deal with all their passwords
3. Understand limitations of user generated passwords
4. Understand limitations of machine generated passwords
5. Prioritise Administrators and Remote user accounts
6. Use account lockouts and protective monitoring
7. Don't store passwords as plain text

None are earth shattering, yet all of us know that pretty much every organisation has users with passwords of Password123, Changeme, Welcome1 and of course Ashley Madison user favourites 123456.  Numbers 1 and 7 feature in most penetration testing reports you  read or write.

So whilst these tips provided by the UK government aren't new or fantastic I would encourage you to spend a few minutes reading the document and on Monday see how your organisation meets, exceeds or perhaps fails in one or more of them.  

We'll be stuck with passwords for a while yet, we should at least make people work for them a bit harder.  

Cheers

Mark H 

Today, I'd like to promote a tool that I wrote four years ago and that is running every 30 minutes on my OSSEC server. DShield offers many clients to collect and process logs from multiple firewall brands/vendors. But today, more and more logs are already centralized to a SIEM. Collecting the events twice can be a pain for performance, complexity and security reasons. I'm collecting firewall logs from many devices with OSSEC so there are stored in a central place. The idea of ossec2dshield is to read the logs from OSSEC and forward them to DShield. Writing a DShield agent is easy, everything is described here. Basically, the script parses the OSSEC's firewall.log and generates the corresponding DShield events. 

The script syntax is self-explanatory:

$ ossec2dshield.pl --log=file --userid=dshieldid --statefile=file --from=email --mta=hostname
                  [--help] [--debug] [--test] [--obfuscate] [--ports=port1,port2,...]  
Where: 
--help                   : This help
--debug                  : Display processing details to stdout
--test                   : Test only, do not mail the info to dshield.org
--obfuscate              : Obfuscate the destination address (10.x.x.x)
--ports=port1,!port2,... : Filter destination ports ex: !25,!80,445,53 
--log=file               : Your OSSEC firewall.log
--userid=dshieldid       : Your dshield.org UserID (see http://www.dshield.org)
--statefile=file         : File to write the state of log processing
--from=email             : Your e-mail address (From:)
--mta=hostname           : Your Mail Transfer Agent (to send mail to dshield.org)

You will need your dshield.org UserID, a mail relay (MTA). The state file is very important: it contains the timestamp of the last processed event. This prevents events to be sent twice to dshield.org. Once processed, the data will be submitted to register(at)dshield(dot)org. Using “–-port“, you can exclude or restrict to some interesting ports. Example: “–-port=’!80,!22,!443′” will report all blocked firewall traffic except for the destination ports 80, 22 and 443. The current version of the script is not so powerful as the regular Dshield clients but it works very well. Ideas and suggestions are always welcome. The script is available in my github.com repository. Happy logging!

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

Introduction

Any email filtering worth its cost should block numerous messages every day.  Most people are content to ignore these blocked messages; however, I'm always interested to see what exactly is being blocked.  Perhaps the most common type of malicious spam (malspam) I see from the spam filters is Upatre-based malspam.

I've written diaries before about specific waves of Upatre malspam sending the Dyre banking Trojan [1, 2].  I've only noticed emails with .zip file attachments from this type of malspam.  I recently looked through my organization's spam filters and found the same thing again.  In this case, we found three different themes of malspam sent in a three-hour window, and all had Upatre malware sending Dyre.  Let's take a closer look at these samples of Upatre/Dyre malspam from Wednesday, 2015-09-09. 

A three-hour window of malspam

Below is an image of blocked malspam with malicious attachments on Wednesday 2015-09-09 from 05:00 to approximately 08:00 CDT.  Some of the information has been redacted so I could share.

Shown above: A three-hour windows of blocked malspam from Wednesday, 2015-09-09.

In this three-hour window, we see several different types of subject lines.  Let's concentrate on the top three:

• Subject lines that start with:  Credit Note CN-
• Subject lines that start with:  Message from "
• Subject line:  Please view

Each of the above waves is botnet-based Upatre malspam.  A random check of the email headers shows almost every message came from a different IP address.

Malware from the first and second waves has the same file hash

The first wave is credit note-themed malspam.  Other sources have reported about this particular theme in recent days [3, 4].  The subject line for each message contains the domain name of the recipient's email address.  The subject lines, message text, and attachment names are different for each message.  The attachment is a .zip archive that contains an executable with an .scr file extension.

Shown above: Credit note-themed malspam from Wednesday, 2015-09-09.

The second wave is OMP-themed malspam.  At least one other organization saw this malspam today [5].  This type of malspam has the same spoofed sender, and the attachments all have the same name: omp cheque.zip.  Each message also has a spoofed sending address ending with the recipient's domain.  The attachment is a .zip archive that contains an executable named omp cheque.scr.

Shown above: OMP-themed malspam from Wednesday, 2015-09-09.

Examine the attachments, and you'll find the same file hash for the .scr file from both waves of malspam.  The extracted malware is the same for all these emails.

Shown above: Malware from the credit note and OMP-themed malspam.

The third wave is fax-themed malspam discussing a new contract.  The message text is the same for each email, but the attachments all have different file names.  The attachment is a .zip archive that contains an executable with an .exe file extension.

Malware from the third wave is similar to the first two

Shown above: Fax-themed malspam from Wednesday, 2015-09-09.

The file attachment is similar in size to the other two waves of emails.

Shown above: Malware from the fax-themed malspam.

Malware analysis from the first and second waves

Below is data on the extracted Upatre malware from the first and second waves of malspam:

File name:  contract last ver Buckridge Throughway.exe and various other names
File size:  30.0 KB ( 30720 bytes )
MD5 hash:  287b713e0dade68b08b036de0118dad9
SHA1 hash:  72ae7232261f243043126f7749604ed985c8808e
SHA256 hash:  b7578820f1369a3f0b620c8a6365fd7613e3d6b4cc9916c6fb32a2e6e2a346fb
First submission to Virus Total:  2015-09-09 10:44:24 UTC
Detection ratio:  9 / 56
https://www.virustotal.com/en/file/b7578820f1369a3f0b620c8a6365fd7613e3d6b4cc9916c6fb32a2e6e2a346fb/analysis/
https://www.hybrid-analysis.com/sample/b7578820f1369a3f0b620c8a6365fd7613e3d6b4cc9916c6fb32a2e6e2a346fb?environmentId=4

Traffic from an infected host: 

197.149.90.166 port 12125 - Upatre callback, campaign identifier 09-GB77
85.248.2.228 port 443 - encrypted traffic
217.168.210.122 port 443 - https://217.168.210.122/img917.png

Shown above: Creative filtering of the traffic in Wireshark.  Picture is edited--click on the image to see what it actually looks like.

Dyre malware found on an infected host:

File name:  C:\Users\username\AppData\Local\lpCXRrcEpmnPjnb.exe
File size:  605.5 KB ( 620032 bytes )
MD5 hash:  051eeea32bd66d207838f1ac640bd4f8
SHA1 hash:  f17655c2bf62572e4db84de2b8473cb4941baceb
SHA256 hash:  010e4d5c4668a04274c30a144021d56981da5991a3f7e26379db0782ef1632af
First submission to Virus Total:  2015-09-09 11:32:49 UTC
Detection ratio:  7 / 57
https://www.virustotal.com/en/file/010e4d5c4668a04274c30a144021d56981da5991a3f7e26379db0782ef1632af/analysis/
https://www.hybrid-analysis.com/sample/010e4d5c4668a04274c30a144021d56981da5991a3f7e26379db0782ef1632af?environmentId=5

Malware analysis from the third wave

Extracted Upatre malware from the third wave of malspam:

File name:  omp cheque.scr and various other names
File size:  36.5 KB ( 37376 bytes )
MD5 hash:  4c0915119ca00a67b1fb59de3ae08592
SHA1 hash:  14d5e5efcc06be76944cf3036fe880c785489e0b
SHA256 hash:  a61b06f03909b05e8130c7347cd66af6757280a7182880963f2f27c9071c8e51
First submission to Virus Total:  2015-09-09 11:46:07 UTC
Detection ratio:  17 / 57
https://www.virustotal.com/en/file/a61b06f03909b05e8130c7347cd66af6757280a7182880963f2f27c9071c8e51/analysis/
https://www.hybrid-analysis.com/sample/a61b06f03909b05e8130c7347cd66af6757280a7182880963f2f27c9071c8e51?environmentId=4

Traffic from an infected host: 

197.149.90.166 port 12127 - Upatre callback, campaign identifier 09-GB22
82.160.64.45 port 443 - https://82.160.64.45/img922.png
85.248.2.228 port 443 - encrypted traffic
45.46.50.225 port 443 - encrypted traffic

Shown above: Creative filtering of the traffic in Wireshark.  Picture is edited--click on the image to see what it actually looks like.

Dyre malware found on infected host:

File name:  C:\Users\username\AppData\Local\bitTUngcmhShQVQ.exe
File size:  610.0 KB ( 624640 bytes )
MD5 hash:  abea26ae7faf459012faa965d5bc6332
SHA1 hash:  9de25f25ab67e78e3abaca0811f4330c3e2f80a1
SHA256 hash:  4e07c2d3dd01e9553215a9afa02a513e95ad629ffc21c638bc191b42eca7d3ce
First submission to Virus Total:  2015-09-09 12:34:00 UTC
Detection ratio:  5 / 56
https://www.virustotal.com/en/file/4e07c2d3dd01e9553215a9afa02a513e95ad629ffc21c638bc191b42eca7d3ce/analysis/
https://www.hybrid-analysis.com/sample/4e07c2d3dd01e9553215a9afa02a513e95ad629ffc21c638bc191b42eca7d3ce?environmentId=1

Network alerts from the infection traffic

The image below shows some of the alerts I saw when playing back one of the pcaps of my infection traffic on Security Onion.

Shown above: Events from Squil on Security Onion using Suricata with the Emerging Threats (ET) and ET Pro rulesets.

Final words

Much like Liam Neeson's character in the Taken movie series, botnets serving Upatre malspam are relatively mature and relentless in their pursuit (the pursuit of continually spewing this sort of malspam).  Also, like the Taken movie series, the whole thing is getting kind of old.  In the security field, most of us are likely to ignore this malspam, because there's very little chance we'll ever be infected ourselves.

However, we see Upatre malspam almost every day, so it must somehow make a profit for criminals behind this operation.  With that in mind, some of us will continue searching the spam filters to see if anything changes.

Malware samples and pcap files for this diary are available from hybrid-analysis.com links above.

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

References:

[1] https://isc.sans.edu/forums/diary/UpatreDyre+the+daily+grind+of+botnetbased+malspam/19657/
[2] https://isc.sans.edu/forums/diary/UpatreDyre+malspam+Subject+eFax+message+from+unknown/19713/
[3] http://blog.dynamoo.com/2015/09/malware-spam-credit-note-cn-60938-from.html
[4] http://myonlinesecurity.co.uk/invoice-or-credit-note-from-random-companies-fake-pdf-malware/
[5] http://myonlinesecurity.co.uk/message-from-mp2541-fake-pdf-malware/

This one fell between the cracks yesterday. Adobe released one bulletin yesterday for patch Tuesday [1]. The update fixes two vulnerabilities in Adobe's Shockwave player.

All versions of Shockwave Player prior to 12.2.0.162 are vulnerable and Adobe assigned this patch a priority rating of 1, indicating that the vulnerability has already been exploited in targeted attacks.

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

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

Overview of the September 2015 Microsoft patches and their status.

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

My hope is that when people become familiar with the tactics employed by scammers, they will be less likely to get ripped off. With this in mind, I'd like to describe my recent interactions with miscreants who target sellers on Craigslist. Perhaps the details I've gathered about the scammer's operation will help curtail such activities. This encounter, which involved SMS messages, emails and a click, is a variation of a PayPal-themed overpayment scam that has been quite prolific in the recent years.

"Working in a very rural area"

The text message from 731-907-0226 arrived in response to my Craigslist post that advertised a furniture item for sale. "Text me back at (7312777303 if you still have it, am interested. Text only". My ad included a temporary phone number I set up just for cases like this. Responding to the sender of this message produced no reply; however, when I texted 731-277-7303, I received a quick answer:

"My name is Rick Smith. I am buying this as a surprise,I work with Turner Construction,we are currently working at a very rural area which makes it very hard for me to make phone calls. I have a Mover who will come for the pickup, I will be making the payment via PayPal that is the only payment option."

This message achieved two critical objectives for the scammer. First, the person began crafting a story that will later provide an excuse for asking the victim to wire funds to a third party. In addition, the scammer was establishing a reason why he could interact with me using voice calls. The supposed buyer was claiming to be in an area where voice calls didn't work. In another variation of a Craigslist-originating scam, scammers used the excuse of being on active duty in the military, which precluded non-text communications. Scammers might shy away from phone calls, in part because interacting with multiple targets this way is time-consuming; also, calls might reveal too many details about the scammer.

The scammer also requested my email address, so he could send me payment. He insisted that PayPal was the only payment method he could accommodate. As is common in schemes that target Craigslist users, the scammer didn't want to contact the victim using the Craigslist email relay, probably to avoid getting blocked by that system.

The scammer's phone numbers above were associated with the VoIP company Bandwidth.com, which makes its virtual numbers available to other providers, such as Google Voice according to Phone Validator.

"You are required to send the $680.00"

After I supplied my email address, which I set up for interactions like this, I received a reply:

"Please check your email for the notification and instructions,but if you don’t get the notification in your inbox please check the spam. PayPal must have sent you some emails by now, I think you need to follow some steps. please check both spam/junk and inbox and get back to me ASAP."

Indeed, my Hotmail inbox included a message with the subject "Notification Of An Instant Payment From Rick Smith(brwnsmith20@gmail.com)". Although it was designed to look like it came from PayPal, its headers told a different story:

Authentication-Results: hotmail.com; spf=pass (sender IP is 209.85.223.194) smtp.mailfrom=joylove270@gmail.com; dkim=none header.d=consultant.com; x-hmca=none header.id=Email.transactionverifier@consultant.com
X-SID-PRA: Email.transactionverifier@consultant.com
Sender: joylove270@gmail.com
From: "Service@PayPal.com" <email.transactionverifier@consultant.com>
Date: Sun, 30 Aug 2015 19:20:59 +0100
Subject: Notification Of An Instant Payment From Rick Smith(brwnsmith20@gmail.com)
Return-Path: joylove270@gmail.com

The headers confirmed that the message was sent using Gmail (209.85.223.194 belongs to Google). The actual sender was joylove270@gmail.com.

All emails I received from the scammer had the Date: stamp that included the +0100 time zone designation, lending some credence to the hypothesis that the person was sending the messages from a Central European Time (CET) country.

The notice listed the buyer's as brwnsmith20@gmail.com, which might be an artifact carelessly left from an earlier version of the scam. The email indicated that the supposed payment was significantly larger than what I had requested on Craigslist. It included an explanation for this overpayment:

"Rick Smith has made his intentions known to PayPal® that he will like $680.00 USD to be sent to the recipient's address below.You are required to send the $680.00 USD via Money Gram Money Transfer."

This was a setup for the overpayment scam, in which victims are persuaded to pay a third-party on behalf of the miscreant.

"We are working with Money Gram on this transaction."

Despite the (fake) email confirmation of payment, no funds were actually deposited into the PayPal account I set up for such interactions. When I asked the "buyer" about this discrepancy, he explained:

"As per the e-mail PayPal sent to me which is also similar to yours which i hope you receive, you will have to pay an upfront payment out of your pocket via Money Gram to the address given to you, and you will be given the information which is the Reference Number you will email to PayPal by replying to the confirmation mail from them regarding the details you have from Money Gram, you will receive the whole money in your account without any delay."

The fake PayPal message in my inbox clarified that I might not see the funds in my PayPal account until I sent money to the buyer's pickup agent using MoneyGram. The email provided further assurances:

"The money has now been deducted from the buyer's account and is ready to be deposited into your PayPal® account. Please reply this email directly with the Information needed from you. While funds are pending, the money belongs to you but is not available to spend or withdraw."

Soon, I received two more messages claiming to be from PayPal and impressing upon me of the safety of the transaction:

"My name is Mellisa and it is my pleasure to assist you in regards to the transaction between you and Rick Smith. We cannot credit your account until you send us the transfer details, but I am very happy to be assigned to tell you that the transaction is 100% secure and legitimate, we want to use this medium to tell you once again that the amount of $1,680.00 USD has been made to your account by Rick Smith."

The email stated that if I had any concerns, I should express them by responding to the message. The email software would make the victim believe that such queries would go to Service@PayPal.com, while in reality they would be directed to Email.transactionverifier@consultant.com.

"Go to any Money Gram Outlet close to your home"

According to fake PayPal's emails, I had to take one last step to complete the transaction: I had to send money via Money Gram to the buyer's agent, who would be responsible for picking up the purchased item from my location. This step was explained in multiple emails, including the one from the supposed buyer, Rick Smith, which came from ric.smith222@gmail.com:

"I want you to know that i added an extra fee of $680 to the total payment which i need you to help send to the agent coming for pick up and it needs to be sent via Money Gram as that's the only way they can get it. I am sorry i should have informed you but i only got the urgent message from the pick up agent that they will need the funds before they can come to pick up when i was about making the payment. [...] I also added $100 the Money Gram charges."

One of the messages specified the name of the person who would pick up the money in Bangor, PA in the US. In the context of this scam, this person was acting as a money mule.

Though my emails to the fake PayPal account Email.transactionverifier@consultant.com went unanswered, the scammer did respond from ric.smith222@gmail.com when I asked why he couldn't pay the pick-up agent directly:

"There is no money gram here to make the transfer and I tried more that 4 times making the transfer online but they keep on rejecting my card."

So, to receive payment for the item I was selling, I had to first send irrevocable funds to someone in Pennsylvania. In this case, the scammer requested funds via MoneyGram. Other variations of the scam that I've seen asked the victim to transfer funds using Western Union. Supposedly the money I would receive via PayPal would reimburse me for that expense.

"Surf anonymously"

Curious whether I could gather any information about the scammer, I emailed him (or her) a link to a benign image that resided on my temporary web server. In my email message to the scammer I asked for help making sense of MoneyGram's website and provided a URL to the screenshot. The scammer initially told me to visit MoneyGram in person, but after I threatened to give up on the transaction, I saw someone retrieving the image from my server:

GET /images/screenshot15.jpg HTTP/1.1
Host: 104.131.115.41
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

If these headers are to be believed, the scammer was using an up-to-date version of Google Chrome on Windows 7.

The connection came from 208.31.49.29. This IP is on a /24 subnet assigned to Kaia Global Networks in the US, on the Sprint network according to Robtex. One Wikipedia page I found indicated that this subnet hosted CyberGhost VPN exit nodes. I downloaded this provider's VPN client and was able to confirm that 208.31.49.29 is, indeed, one of the IPs associated with the paid version of the service.

Alas, the scammer was careful to obscure his origins by tunneling through the this Romania-based VPN service, which is designed "protect your online privacy, surf anonymously and access blocked or censored content." According to my testing, CyberGhost's VPN doesn't modify browser headers, though the scammer could have tweaked them using other means.

"The nature of my work"

I searched the web for the artifacts exhibited by the scammer in the interactions above to assess the scope of the malevolent activities. I found a few complaints associated with the two phone numbers. They dated to 2014, possibly because these VoIP numbers were misused for other shady machinations (1, 2, 3) at the time. I saw no mention of ric.smith222@gmail.com, though joylove270@gmail.com was associated with several complaints that began in April 2014 and matched the pattern of this scam. At the time, "Rick Smith" was using other phone numbers, including 610-455-5663 and 914-268-3815.

When I pivoted my search on "Rick Smith," I came across numerous reports (1, 2, 3, 4) from Craigslist sellers who were targeted in the manner described above. The phone numbers in these complaints were too numerous to list here. The reports mentioned other names and email addresses employed in the scam, including: brwnsmit10@gmail.com, Anthony Smith, walkerchromer@gmail.com, Richard Johnson, walkerchromer@gmail.com, p.poner12301@gmail.com, safareewalker@gmail.com, walkingthon@gmail.com, celisiur@gmail.com, richardjrbrown09@gmail.com, brwnsmit6@gmail.com, celisiur477@gmail.com, rick06smith@gmail.com, lamdons4@gmail.com, Frank Rick, customerhelpline@mail2pay.com, andie.macdowell099@gmail.com, pallybill@gmail.com, etc.

The scammer's pickup agentsmoney mules mentioned in the discussion forums above included: Levon Rivers, Columbus, OH 43227; David. Jacobo, Federal Way, WA 98003; Rob Frazier, Brooklyn, NY 11212; Terry Dunn, Lebanon, OH 45036; and Billy Ray Mayo, Livingston, LA 70754.

The earliest mention of the activities I observed and attributed to this scammer date to January 2012. At the time, the scammer used the email address brwnsmith20@gmail.com—the same address included in the body of the fake PayPal notification email that I received. The scammer's target wrote that the scammer claimed to be on active duty in the military, using that excuse to explain why he could not speak on the phone or pick up the item in person. The scammer reportedly stated, "Am not available to talk through phone due to the nature of my work."

This set of scams might be the work of a single miscreant. It's also possible that a group of scammers is using a common toolkit to prey on Craigslist sellers. Regardless, I'm disheartened to see the volume of complaints associated with these activities. The person or people behind them seem to be operating with apparent impunity for years. Perhaps some of the details above can assist law enforcement with weaving these malicious actions into a pattern that helps identify the individual(s) responsible for them.

For more of my articles about online scams, take a look at How Victims Are Redirected to IT Support Scareware Sites and Conversation With a Tech Support Scammer.

-- 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.

Threat intelligence became a hot topic for a while. The food of threat intelligence is based on IOC's (Indicators of Compromise) which contains technical information like:

• Files, path
• Hashes 
• IP addresses
• Domains
• Users

Mixed with other sources of information or tools, they help in detecting malicious behaviors of programs or networks. They are plenty of sources to collect IOC's. Some are publicly available while others are compiled and maintained by organizations for their customers or restricted users. DShield is of course a good source of IP addresses but Lenny (another ISC handler) is maintaining a nice list of resource on his website(1). Usually, free services offer lists of IOC's in common format that are reusable in your own environment. But sometimes, you will find interesting information published online. Many security researchers analyze pieces of malware and publish the results on their blog. Big organizations like to publish nice PDF reports containing juicy information. In both case, IOC's can be present but how to extract them automatically?

ioc-parser(2) is a nice Python script which might be very helpful in this case. It parses an input file and generates a list of IOC's in another format. It supports the following input formats: Text files, PDF files or HTML (URLs). Results can be generated in CSV, JSON, YARA or NetFlow. The idea is simple, it searches for patterns based on regular expressions. Everything is configurable and your own regexp can be added. 

Here is the list of IOC's extracted from an old PDF report about Duqu 2.0 written by Kasperky Lab:

But you can access URLs directly and extract IOC's present in the HTML code of the latest MalwareMustDie blog article:

And the same results generated in YARA format:

This is a nice script to keep in your personal toolbox. Of course, be careful to not re-use the generated data "as is", there could be false positives or bad regular expression matches.

Happy IOC's hunting!

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

(1) https://zeltser.com/malicious-ip-blocklists/
(2) https://github.com/armbues/ioc_parser

On a quiet, rainy Sunday I would like to talk about NIST 800-12, “An Introduction to Computer Security”.  I am sharing this to help raise awareness, as much for our regular supporters, but also for those around us who may not fully grok the whole of a computer security program.  Specifically today, I am speaking to the role of auditors and compliance in a security program.

I recently had the opportunity to explore the job market due to a lack of funding at my previous engagement (an expression that is often heard in security, as security personnel are most often viewed as overhead).  During this time, I had the opportunity to interview with a growing company, a startup that apparently was well funded, based on their recent expansion and growth.  The interview took an hour, but was actually over 15 minutes into the interview when one executive  asked the perilous question:

“Which is more important, compliance or security?”

Given the context in which the question was asked, it sent chills that, mentally, sent me running.  It was very apparent in the question that the individual saw these as two distinct efforts, completely unrelated in their application.  Compliance, and any infosec audit function, should exist to aid the overall security effort, not hinder or lead.  When Compliance becomes the lead or priority, then it is not so good.  Metrics over actual Security is bad.  Very bad.  And that’s the feeling I had there.

OTOH, when organizations truly understand the roles and responsibilities required for an effective security program, good things happen.  When you have a scenario where security and compliance do work closely together, great things can be accomplished.  Often times it is a matter of working with the auditor so they understand your challenges, and they can often raise those to levels that need to hear actual risk and vulnerabilities.  NIST 800-12 talks about the security program, as a whole, and the components that are often required to actually implement a continuous improvement environment.  I am not advocating sharing it all with everybody, but rather understand what is there in order to share the relevant parts with our peers and colleagues.   I believe we all agree that knowledge is power, and that Security and all its complexities are often misunderstood throughout the enterprise.

Let’s change that.

tony d0t carothers --gmail

Every morning, while drinking coffee, one of my daily task is to keep an eye on my logs. Keeping logs is critical to help you to investigate incidents and, sometimes, to prevent some of them. That's why I'm collecting a huge amount of data. Besides miscellaneous tools and scripts, I'm receiving a daily overview of my firewalls traffic via a DShield report. Every days, I see that IP addresses are scanning my network. Today, I went deeper and tried to get the good and the bad from this report. The firewalls protect classic devices and applications (home network, collocated servers, websites and other public services). 

Port scanning is an activity that has always induced debates. The classic question is: "Do we have to take care about port scans?". I already had discussions with peers about this topic and different point of views are always defended. Some people argue that port scanning is a normal activity and it will never decrease. For them, creating incidents related to port scans is way too much time consuming. Others are feeling offended and track them continuously.

Even if you don't track them, port scans must be logged because they can be part of a reconnaissance phase and be followed by a much deeper attack against your infrastructure. It could be useful to use them later as evidences. So, the next question is: can we reduce the noise and filter good VS. bad port scanners?

They are official port scanners operated by companies, non-profit organizations or security researchers. Some examples on top of my list:

• SHODAN (identified with PTR records: xxxxxx.shodan.io)
• ShadowServer project (identified with PTR records: scan-xxx.shadowserver.org)
• Rapid7's Sonar project (IP range: 71.6.216.32/27)

Do you know other Internet scanners like these? Feel free to share them.

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

A few days ago, Tom wrote a diary(1) about RTIR(2) and its REST API. He explained how the tool can be fulfilled with external data. Being a DShield contributor for years (I submit my firewall logs), I like to search for IP addresses information in the DShield database. By default, RTIR extracts IP addresses from tickets and has an interface to query services like WHOIS servers, to perform a traceroute or to query any third-party website. RTIR being extremely configurable, why not extend it to query the DShield database using the ISC API(3)!

If IP addresses can be queried via the URL "https://isc.sans.edu/ipinfo.html?ip=x.x.x.x", don't do this. First of all for performance reasons but the page cannot be displayed in an iframe (that's the case in RTIR) because it sets the 'X-Frame-Options' to 'SAMEORIGIN'. To query details of an IP address, use the following IP API call:

https://isc.sans.edu/api/ip/x.x.x.x

Results are returned in XML. To integrate DShield lookups into RTIR, follow this procedure.

1. Create a new page called "isc_ipinfo.php" in your Apache server running RTIR (or any available HTTP server). This page will receive the IP address, query the DShield API and reformat (basically) the XML output:

2. Edit your $RTIRHOME/etc/RTIR_SiteConfig.pm and add the new service in $RTIRIframeResearchToolConfig (pointing to your URL):

3. Restart your RTIR instance and enjoy! You can now query the DShield API:

It's also easy to create new "portlets" to be used in dashboards. As a bonus, let's display the ISC Infocon status in a RTIR dashboard. 

1. Create the new portlet in $RTIRHOME/local/html/Elements. Let's call it "InfoconStatus":

2. Enable the new portlet in $RTIRHOME/etc/RTIS_SiteConfig.pm:

3. Restart your RTIR instance and adapt your favorite dashboards:

(1) https://isc.sans.edu/forums/diary/Automating+Metrics+using+RTIR+REST+API/20087/
(2) https://www.bestpractical.com/rtir/
(3) https://isc.sans.edu/api/

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

Introduction

Last month in mid-August 2015, an actor using Angler exploit kit (EK) switched to Neutrino EK [1].  A few days later, we found that actor using Angler again [2].  This week, we're back to seeing Neutrino EK from the same actor.

Neutrino EK from this actor is sending TeslaCrypt 2.0 as the payload.  We also saw another actor use Angler EK to push Bedep during the same timeframe.

Today's diary looks at two infection chains from Tuesday 2015-09-01, one for Angler EK and another for Neutrino.

First infection chain: Angler EK

This infection chain ended with a Bedep infection.  Bedep is known for carrying out advertising fraud and downloading additional malware [3, 4, 5].

A page from the compromised website had malicious script injected before the opening HTML tag.  The Bedep payload along with patterns seen in the injected script indicate this is a different actor.  It's not the same actor currently using Neutrino EK (or Angler EK) to push ransomware.

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

We saw Angler EK on 148.251.98.68.  Using Wireshark to filter the traffic, we find activity typical for Bedep infections as shown in the image below.

Click on the above image for a full-size view.

Using tcpreplay on the pcap in Security Onion, we find alerts for Angler EK and Bedep.  This setup used Suricata with the EmergingThreats (ET) and ET Pro rule sets.  See the image below for details.

Click on the above image for a full-size view.

Second infection chain: Neutrino EK

Our second infection chain ended in a TeslaCrypt 2.0 infection.  Very little has changed from last week's TelsaCrypt 2.0 post-infection traffic.  This actor's malicious script was injected into a page from the compromised website.  The injected script follows the same patterns seen last week [2].  In the image below, the URL for a Neutrino EK landing page is highlighted.

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

Take another look at the image above.  Notice another URL with the domain heriaisi.work before the Neutrino EK landing URL.  We saw the same type of URL using heriaisi.work last week from injected script used by this actor.  This suspicious domain is registered to a person or organization in the Czech republic [6], and it is currently hosted on a Ukrainian IP at 93.171.205.64.  It doesn't come up in the traffic.  I'm not sure what purpose it serves, but that URL is another indicator pointing to this particular actor.

We're still seeing the same type of activity from our TeslaCrypt 2.0 payload this week.  The only difference?  Last week, the malware included a .bmp image file with decrypt instructions on the desktop.  This week, the TeslaCrypt 2.0 sample didn't include any images.  It only dropped .txt and .html files for the decrypt instructions.

Shown above: A user's Windows desktop after the TeslaCrypt 2.0 infection.

Shown above: Clicking on one of the links for the decrypt instructions brings up a captcha window.

Shown above: TeslaCrypt 2.0's decrypt instructions, ripped off from CryptoWall 3.0, still stating CryptoWall in the text.

We saw Neutrino EK on 46.108.156.181.  As always, Neutrino uses non-standard ports for its HTTP traffic.  This type of traffic is easily blocked on an organization's firewall, but most home users won't have that protection.  Using Wireshark to filter and view the traffic, we find activity typical for TeslaCrypt 2.0 infections as shown in the image below.

Click on the above image for a full-size view.

Using tcpreplay on the pcap in Security Onion, we find alerts for Angler EK and AlphaCrypt.  This setup used Suricata with the EmergingThreats (ET) and ET Pro rule sets.  The TeslaCrypt 2.0 traffic triggered ET alerts for AlphaCrypt.  See the image below for details.

Click on the above image for a full-size view.

Final words

We can't say how long this actor will stick with Neutrino EK.  As I mentioned last time, the situation can quickly change.  And despite this actor's use of Neutrino EK, we're still seeing other actors use Angler EK.  As always, we'll continue to keep an eye on the cyber landscape.  And as time permits, we'll let you know of any further changes we find from the various threat actors.

Traffic and malware for this diary are listed below:

• A pcap file with the infection traffic for Angler EK from Tuesday 2015-09-01 is available here.  (2.08 MB)
• A pcap file with the infection traffic for Neutrino EK from Tuesday 2015-09-01 is available here.  (594 KB)
• A zip archive of the malware and other artifacts is available here.  (692 KB)

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

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

References:

[1] https://isc.sans.edu/forums/diary/Actor+using+Angler+exploit+kit+switched+to+Neutrino/20059/
[2] https://isc.sans.edu/forums/diary/Actor+that+tried+Neutrino+exploit+kit+now+back+to+Angler/20075/
[3] http://blog.trendmicro.com/trendlabs-security-intelligence/bedep-malware-tied-to-adobe-zero-days/
[4] https://threatpost.com/angler-exploit-kit-bedep-malware-inflating-video-views/112611
[5] http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Win32/Bedep#tab=2
[6] http://whois.domaintools.com/heriaisi.work

Always nice when the spammers are so forthcoming to send their latest crud directly to our SANS ISC honeypot account. The current incarnation

Subject: Re: Your complimentary 3-night stay giftcard (Expires 09
From: "Marriott Gift Card" marriottgiftcard@summerallstar.review

came from

Received: from summerallstar.review (50.22.145.13-static.reverse.softlayer.com [50.22.145.13])

which kinda figures, Softlayer is among the cloud computing providers whose "get a virtual server FREE for one month" is an offering that scammers can't resist. The "Marriott" email said:

Marriott Special Gift Card:
=======================================================
Expires 09/15/15
Notification: #2595319
=======================================================

ALERT: Your Marriott-Gift Card will expire 09/15/15.

Please claim your gift-card at the link below:
http://seespecial.summerallstar[dot]review

This gift-card is only good for one-person to claim
at once with participation required. Please respect the
rules of the special-giftpromo.

=======================================================
Expires 09/15/15
Notification: #2595319
=======================================================

End-GiftCard Notification

.review ? How lovely! Let's use the opportunity to again *thank* ICANN for their moronic money grab, and all the shiny new useless "top level domains" that honest users and corporations now have to avoid and block. The lesson learned a couple years ago, when ".biz" and ".info" came online, should have been enough to know that the new cyber real estate would primarily get occupied by crooks. But here we are. I guess ICANN and most domain name pimps don't mind where their revenue stream comes from. But I digress.

Clicking on the link results in a rather unimaginative website, hosted on http://lucky-survey.com-hu3[dot]info, shown on the picture below.

It doesn't (seem to - as far as I could tell) push any malware, but asks a couple of dumb questions, and then offers a prize. Ahem. Sort of a prize:

Somewhere along the way, it seems like the connection to "Marriott" got lost. Which is maybe all the better...

Over in the SANS ISC discussion forum, a couple of readers have started a good discussion https://isc.sans.edu/forums/Encryption+at+rest+what+am+I+missing/959 about which threats we actually aim to mitigate if we follow the HIPAA/HITECH (and other) recommendations to encrypt "data at rest" that is stored on a server in a data center. Yes, it helps against outright theft of the physical server, but - like many recent prominent data breaches suggest - it doesn't help all that much if the attacker comes in over the network and has acquired admin privileges, or if the attack exploits a SQL injection vulnerability in a web application.

There are types of encryption (mainly field or file level) that also can help against these eventualities, but they are usually more complicated and expensive, and not often applied. If you are interested in "data at rest" encryption for servers, please join the mentioned discussion in the Forum.

While looking for something else, I discovered that Google (of course) knows what people are trying to hack lately:

 
Agreed, this information is not overly useful.  These hacks are basically on the opposite end of the threat scale from the over-hyped "Advanced Persistent Threat" (APT).  Let's call it the "Basic Sporadic Annoyance" (BSA), just to come up with a new acronym :).

The BSAs still tell us though what "average" wannabe hackers seem to be interested in breaking into, namely: websites, online games, wifi and phones.  Cars, pacemakers, fridges and power plants are not on the list, suggesting that these targets are apparently not yet "popular" enough.

Being fully aware of the "filter bubble" https://en.wikipedia.org/wiki/Filter_bubble we had several people try the same search, and they largely got the same result. Looks like Facebook really IS currently the main wannabe hacker target.  But Facebook don't need to worry all that much. Because if you just type "How to h", then the suggestions reveal that other problems are even more prominent than "hacking Facebook":

If your results (of the "how to hack" query, not the latter one) differ significantly, please share in the comments below.  Updated to add: Thanks, we have enough samples now :)