Case 2: What if IOCs are received today but your organization is targeted in the coming one or two months? Ok, the life of a malware sample (MD5 or SHA1 hash) is very short. They are millions of new malicious files every day. But it’s not the same with IP addresses or domains. I see often malicious IP addresses that are re-used across multiple events in MISP: Remember, yesterday we exported a list of hashes from the last 30 days from MISP. In some cases, 30 days might already be way too much for some platforms and have to be reduced to fewer days. The scheduled search in Splunk was scanning event from the last hour. If we increase this to events from the last x months or ‘all time’, they are chances to dramatically impact the Splunk performance. The solve the cases above, let’s create a new tag in MISP called ‘Hunting’ (or whatever you want). All events tagged as ‘Retrohunt’ will have they IOCs exported forever (until the tag is removed): Let’s generate the list of IOC’s with 2 MISP queries: The last 15 days + events flagged as ‘Hunting’: wget --header 'Authorization: <redacted>' -O - https://misp/events/hids/md5/download/false/false/false/15d | grep -v "^#") > /tmp/ioc.tmp wget --header 'Authorization: <redacted>' -O - https://misp/events/hids/md5/download/Hunting | grep -v "^#") >> /tmp/ioc.tmp (echo md5 && sort -u /tmp/ioc.tmp) > /opt/splunk/etc/apps/search/lookups/malicious_md5.csv The Splunk lookup table will now contain a sliding window of 15 days with all MD5 hashes and all the hashes flagged as “Hunting”. To address the case 1describe above, we just need to run a unique big scan once a day at night to search across all the files and the case 2 will be automatically solved because interesting IOCs are now present in the lookup table. The most important step: How to define which events to tag for ‘Hunting’? Of course, you could generate a list of IOCs based on existing tags or based on organizations that you trust for the quality of their sharings but, in my humble opinion, it's not sufficient. This is a good opportunity to introduce a process to review IOCs. Indeed, the main problem with platforms like MISP (but it’s the same with any tool collecting IOCs) is the flood of IOCs received daily. Keep in mind: The value of an IOC is not only the technical information (the IP address, hash or domain, etc) but also its context. Not all organisations are working in the same business, not all of them have risks to be targeted by known groups. That’s where some threat intelligence is required to define which events received in your MISP are relevant for you and your organization or... not!  https://isc.sans.edu/forums/diary/Automatic+Hunting+for+Malicious+Files+Crossing+your+Network/23473/
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
ISC Stormcast For Friday, March 23rd 2018 https://isc.sans.edu/podcastdetail.html?id=5923, (Fri, Mar 23rd)
If classic security controls remain mandatory (antivirus, IDS, etc), it is always useful to increase your capacity to detect suspicious activities occurring in your networks.Here is a quick recipe that I’m using to detect malicious files crossing my networks. The different components are:
- MISP - the Malware Information Sharing Platform. I’m running a MISP instance to receive useful IOC’s (Indicator of Compromise) from multiple peers. Common IOCs are IP addresses, domain names, filenames and hashes.
- Bro is an NSM (Network Security Monitoring) tool that acts like a swiss-army knife on your network. The core feature that will be used here is the extraction of files from network flows. Bro is fully integrated to the SecurityOnion distribution.
- Splunk - as the orchestrator of the solution.
- TheHive - A scalable, open source and free Security Incident Response Platform
- Connection logs and IP addresses
- Nameserver resolution and domain names
 https://thehive-project.org/ Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC Stormcast For Thursday, March 22nd 2018 https://isc.sans.edu/podcastdetail.html?id=5921, (Thu, Mar 22nd)
What’s happening with blackmails? For those who don't know the word, it is a piece of mail sent to a victim to ask money in return for not revealing compromising information about him/her. For a few days, we noticed a peak of such malicious emails. One of our readers reported one during the weekend, Johannes Ullrich received also one. A campaign targeted people in The Netherlands.
Blackmails are not new. For years, bad people tried to extort money by using different techniques. For months, we are facing ransomware attacks which encrypt data to prevent the victim to access his/her files but there exist other techniques for a while. In 2012, I wrote a blog post about the social impact of ransomware. At this time, Belgium was under fire with plenty of fake pages pretending to be from the Police services:
In this case, it was quite easy to get rid of such page (a simple system restore was enough). I remembered a friend of mine, non-techie, that was ready to pay the ransom to not disclose some personal stuff to his wife!
Today, blackmail apparently remains a nice way to get money from the victim, even more with the cryptocurrencies that are harder to track. Most of the blackmail samples propose to the victim to pay via a BTC wallet. For the security guys, this is even better because we can track to wallet usage and detect is the campaign is ongoing and if victims paid.
Here is a first example:Hey . Have you ever heard anything information related to the RAT malware 68967? Great job, you have today became a satisfied owner of my own, personal version of this software. I've been able to locate several interesting stuff on your personal computer and I have also been able get in to all ur units, which includes a cellphone. Yet these are definitely all are very little things as opposed to the next. I made this virus to record a mike, a cam, as well as the graphic on the screen, and you know I have created numerous interesting movies. I do believe a few movies will certainly be interesting for you personally :D The best part is that my application recorded is a moment you go to one of the pornographic sites. I even haveinvested two hours of my time to combine two video clips, one which is an image on the screen and another one of the actual web cam. It was quite amusing! Ok, lets get right to the point. I recommend you pay out 350 usd to my wallet - 1Q7xmTttjGgACeuY6ThtBQ9YXEeSzcWgdM I solely utilize BTC. If you will have trouble payingjust use any search box. After obtaining the funds. We will both just forget about this unpleasant moment and erase all the info I have gathered from your devices. You have three days. If I do not receive my cash, I am going to deliver all of the details to the contact information I located on your equipment! Possibly I'll do it with your accounts. It will be very amusing if your loved people obtain a footage of this type. I offer a small amount of time simply because my wallets frequently get locked and you will need to deliver just before that. Yes, you are not the only person receiving an email of this sort, I have infected a 9972 individuals and more than 1131 of them ended up with fascinating things. You actually can call up authorities, think its worthless, the worst stuff they are able to perform is block my wallet. So do not do stupid things. If perhaps I will not receive my cash for any reason, including the failure to send them to a blocked account wallet, ur status will be destroyed. Therefore hurry up! I take care of my anonymousness and use the short-lived e-mail to deliver messages, additionally I am on-line from my working laptopand i only with fake Wi fi from numerous organizations besides i use Double-VPN. Thus, getting in touch with me and responding to to this notice makes no sense.
The wallet 1Q7xmTttjGgACeuY6ThtBQ9YXEeSzcWgdM is empty.Here is a second one: Hello! Do not pay attention on my English, Im from Iran.We uploaded our malware onto your system.Now I thiefted all private data from your device. In addition I received some more evidence.The most entertaining evidence that I have- its a videotape with your masturbation.I set deleterious soft on a porn web site and then you loaded it. As soon as you decided with the video and clicked on a play button, my malicious software instantly adjusted on your device. After downloading, your front-camera shoot the record with you masturbating, furthermore software captured exactly the video you selected. In next few days my deleterious soft grabbed all your social and work contacts. If you need to erase the records- transfer me 295 euro in Bitcoins. I provide you my Btc wallet address - 1FKLcCQTyznP9n1FkiZpxWZx8idxv43icT You have 30 h. to go since now. When I receive transaction I will erase the evidence in perpetuity. Differently I will send the tape to all your contacts.
The wallet 1FKLcCQTyznP9n1FkiZpxWZx8idxv43icT is also empty.
Another example:Whats poppin During all your life u was notified to surf web catiously, but you didnt. Whats the problem?- You will ask me. The whole point is that I adjusted the malicious soft on a web-site with videos for adults (site with p?rn content) (u know whats up). Object was watching video for adults and device tarted functioning as dedicated desktop with keylogger function. Furthermore all cams and screen at the 1st onset started recording. Then my virus collected all your contacts from messengers, e-mails and social networks. So what do we have now? I made the split screen vid (1st part-screen rec.(u have a nice interests lmao), second- camera rec.) and all ur contacts. I think its not good news. Consequently in my opinion two hunned ninety usd is enough for this smallwee error. My btc(cryptocurrency) wallet - [xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] Ask internet how to buy it. It is not very hard. Just write "how to get btc" I give u 1 day after opening this message(I adjusted a special pixel in it, Ill know when you read it). If you dont send me the necessary amount Ill send video with you to all your contacts Upon I receive btc- the ?ompromising will be deleted.If u charge me to send evidence, reply + and Ill share video that I made with three contacts Ive collected from u. Can go to cops, but they will not have time to find me , im Ukranian, so ull be a star among friends.
Finally, here is a valid wallet, it belongs to the campaign launched in The Netherlands:
There is no need to translate it, the context is the same: Your computer has been compromized while you were visiting a pornographic website. But, this time, we can see that (at least for this morning) somebody paid. The requested ransom is 500€ (approximatively 0.068BTC):
In most of the scenarios, the attacker pretends that he caught you via your camera in your private space or while you were browser a pornographic website. How to react when you received a blackmail? The main advice is to NOT pay the ransom. If the mail was received in a business context, contact your local helpdesk or security team. If it is in a private context, just delete the mail. If you have a local CSIRT available, you may also report the blackmail to them.
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
ISC Stormcast For Wednesday, March 21st 2018 https://isc.sans.edu/podcastdetail.html?id=5919, (Wed, Mar 21st)
Just a quick reminder about some bad practices while handling Windows Administrator credentials. I'm constantly changing my hunting filters on VT. A few days ago, I started to search for files/scripts that use the Microsoft SysInternals tool psexec. For system administrators, this a great tool to execute programs on remote systems but it is also used by attackers to pivot internally. This morning, my filter returned an interesting file with a VT score of 11/66. The file is a compiled AutoIT script. This kind of malicious files is coming back via regular waves. AutoIT executable can be easily decompiled. To achieve this, I'm using Exe2Aut.exe. This tool has not been updated for a while but is still doing a good job.
I decompiled the malicious file which was not malicious at all. It was a script created by a Windows administrator to automate the creation of users' directories. This seems a legit script, however, there were two security issues in this very little script:
The first one was the hardcoded domain admin credentials in the script:$adusername = "Administrator" $adpassword = "*C0rnHu******"
The password was a strong one but once the file is published on VT, you can consider the password as lost. Other interesting information are also hardcoded:$server = "Pithos" $folderpath = "E:\Users\" $server = "RMT-SLIA-FILE01"
Note: the Microsoft domain was also present in the file and a simple Google search helped to guess the company. Could we call this a "virtual compromisation"?
The second issue is nastier. The developer is using PsExec to execute a script on a remote server:RunWait("C:\pstools\psexec.exe \\" & $server & " -u " & @LogonDomain & "\" & $adusername & " -p " & $adpassword & " C:\createudir.bat")
Used in this way (with '-u' and '-p' options), PsExec sends the credentials in clear text across the network. Hopefully, it has been fixed by Microsoft starting with PsExec version 2.1. An alternative to this to protect the credentials is to open a NULL session to the remote host prior to calling PsExec. This way, NTML or Kerberos will be used. According to a post written by Mike Pilkington on the Digital Forensics SANS Blog, the $IPC NULL session will also prevent the domain administrator's hash to be captured by dumping tools on the remote system!
Some tips to protect your credentials:
- Do not use an outdated version of system tools
- Do not store credentials into scripts/source code (binaries can be decompiled/reversed!)
- Do not publish internal tools on VT (or any other cloud services)
- Use strong authentication mechanism to prevent credentials to cross networks and be stored in memory
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
ISC Stormcast For Tuesday, March 20th 2018 https://isc.sans.edu/podcastdetail.html?id=5917, (Tue, Mar 20th)
ISC Stormcast For Monday, March 19th 2018 https://isc.sans.edu/podcastdetail.html?id=5915, (Mon, Mar 19th)
Wireshark can capture USB traffic, provided you fulfil the necessary requirements.
When you start capturing USB traffic and then insert a USB stick, you'll see something like this:
First we see a request (and response) for the device descriptor.
The descriptor contains interesting information, like the Vendor ID (VID or idVendor) and Product ID (PID or idProduct). Maybe you've already come across VIDs and PIDs, like in this instance ID: USB\VID_0951&PID_16AE\902B341D991AB031991F4C4D
In this device descriptor, you can also see the indices for the Manufacturer, Product and SerialNumber string descriptors: 1, 2 and 3.
A bit later in the capture, you'll see a request for a string descriptor (type 3) with index 0: that actually means an inquiry for the languages used for the string descriptors.
The language used for the string descriptors of the USB stick I inserted is US English (0x0409):
With this information, Windows will perform a query to obtain the length of string descriptor 3 in US English:
It is 50 bytes long:
And thus Windows can do a query for a 50 bytes long string descriptor with index 3 in US English:
Which gives us the serial number in response:
I invite you to test out Wireshark's USB capture with different USB devices, and post a comment with your findings.
Wireshark-announce: [Wireshark-announce] Wireshark 2.5.1 is now available
This is a semi-experimental release intended to test new features for Wireshark 2.6.
Wireshark 2.6 is the last release that will support the legacy (GTK+) user interface. It will not be supported or available in Wireshark 3.0.
New and Updated Features :
The following features are new (or have been significantly updated) since version 2.5.0:
• HTTP Referer statistics are now supported.
• Wireshark now supports MaxMind DB files. Support for GeoIP and GeoLite Legacy databases has been removed.
• The Windows packages are now built using Microsoft Visual Studio 2017.
• The IP map feature (the “Map” button in the “Endpoints” dialog) has been removed.
For more information please refer to:
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
VMware has released the following new security advisory:
Workstation and Fusion updates address a denial-of-service vulnerability
2. Relevant Products
- VMware Workstation Pro / Player (Workstation)
- VMware Fusion Pro / Fusion (Fusion)
3. Problem Description
Denial-of-service vulnerability through VNC
VMware Workstation and Fusion contain a denial-of-service vulnerability which can be triggered by opening a large number of VNC sessions.
Note: In order for exploitation to be possible on Workstation and Fusion, VNC must be manually enabled.
VMware would like to thank Lilith Wyatt of Cisco Talos for reporting this issue to us.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2018-6957 to this issue.
For further information please refer to:
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC Stormcast For Friday, March 16th 2018 https://isc.sans.edu/podcastdetail.html?id=5913, (Fri, Mar 16th)
This is a guest diary by Joshua Barton
A New Old Threat
The revelation in January 2018 of a vulnerability affecting modern processors was seen as a catastrophe. In some regards, perhaps it was. Aspects of SPECTRE and Meltdown touched processors from Intel, AMD, and ARM going back for two decades. Intel, however, was affected by all aspects of the issue and seemingly touches a proportionally larger group of Enterprise computers and servers. Given that the flaw has existed for over 20 years, it can be assumed that it has been used by sophisticated threat actors for quite some time.
A more thorough description of the issue with white papers and video of the exploit in action can be found at this site: https://meltdownattack.com/.
The CVSS scoring for the SPECTRE/Meltdown vulnerabilities is 5.6 on the CVSS v3.0 scoring methodology.(1) A 5.6 is considered a medium level issue. While it warrants attention, it’s not a time to drop everything and run for the hills. At the time of release, there were multiple other vulnerabilities with higher CVSS scores. Despite the score of 5.6, US-CERT issued a formal alert on 1/4/18 and strongly recommends deploying updated microcode as soon it’s available and tested. (2)
This is not the first processor flaw discovered. Intel released advisories and firmware updates twice in just 2017 for vulnerabilities in the embedded Management Engine technology. Roughly 30 years ago, Intel had to recall a number of x86 processors due to a multiplication error. Companies such as HP, Dell, Lenovo, Acer, and Toshiba take the firmware and place it into a BIOS update, management engine update, or another chipset update that is specific to their hardware. Typically several such updates are released per year. More later on what is in all these updates.
Sometimes things are just HARD!
Despite having six months to work the problem, Intel was forced to release their firmware updates a week ahead of a planned coordinated global announcement.(3) The vulnerability had been discovered by a second group and released publically to the media, forcing the hand of the chip giant. The first set of firmware updates that were released were seriously flawed. Many were caught off-guard. Several OEM’s were not looped into the embargo, governments were not made aware (including the US Government, where Intel resides.) Microsoft incorporated a partial firmware update into the Windows operating system and Linux incorporated it into a Kernel update. Microsoft placed a complex test in place due to incompatibilities with nearly every antivirus package on the market.
Numerous warnings of performance issues were being given by the various manufacturers. Depending on the workload, a slowdown of 1-30% was possible.(4) Such a slowdown could be very expensive for businesses and cloud providers that run large virtualization farms. A few days after the massive rollout began, serious problems were being encountered. Computer system crashes were becoming quite common. A week later Intel started broadcasting to not install its update…resulting in OEMs reversing the update and issuing new BIOS updates that used the previous microcode. Microsoft pushed an out-of-cycle update to disable the new microcode in Windows and Linux removed the microcode completely.
Intel released a statement that they had determined the source of the crashing and began work on a new set of microcode updates for its chips. Starting with the more modern chips and working backward, new updates began appearing in February. OEM’s incorporated the changes and began releasing updates roughly a week after Intel. As of this writing, roughly 30% of the Intel-based platforms have an update available for them with more streaming out daily. There have been no reports of crashing this go around; however, adoption is likely slower than previously as the crashing issue will have a delirious effect on the speed at which large corporations roll these updates out.
What’s in a BIOS or Firmware Update?
BIOS and firmware updates more than half of the time contain a fix for a security relevant issue. Other fixes range from blank screens, performance, power consumption, fan speeds, etc. A common model for both HP and Dell were reviewed. This focuses strictly on Firmware/BIOS and ignores the hundreds of driver updates that likely also have security implications.
Taking a look at the updates released for the HP ProBook 650 G1 for the last 2 years(5):
There have been 15 BIOS updates released for this model.
BIOS 1.43A – Intel SPECTRE Microcode fix version 2
BIOS 1.42A – Restored previous Microcode from 1.40A
BIOS 1.41A – REMOVED Included the Microcode for SPECTRE
BIOS 1.40A – UEFI Security Update (UEFI is used to ensure a secure boot process and prevent rootkits)
Intel Management Engine Firmware Component 18.104.22.16802A – Unauthenticated system takeover over WIFI
BIOS 1.39A -- UEFI Security Update (UEFI is used to ensure a secure boot process and prevent rootkits)
Intel Management Engine Firmware Component 22.214.171.12424A – Unauthenticated system takeover
BIOS 1.36A -- UEFI Security Update (UEFI is used to ensure a secure boot process and prevent rootkits)
Taking a look at the updates released for the Dell Precision 7510 (a common business laptop) (6)
There have been 18 BIOS updates released for this model.
BIOS 1.15.4 – Intel Management Engine Firmware, unauthenticated system takeover, SPECTRE, UEFI
BIOS 1.14.4 – Trusted Platform module fix(encryption keys), Intel ACM update (unauthenticated system takeover), Various bugs
BIOS 1.13.5 – Bootguard bypass issue, System hangs, crashing
BIOS 1.12.4 – Intel Management Engine Firmware – unauthenticated system takeover, TPM flaw preventing bitlocker
TPM 1.2 126.96.36.199 – Encryption Key compromise
BIOS 1.10.7 – No security content
BIOS 1.9.5 – Windows 10 security causes reboot issues, Intel Management Engine
BIOS 1.8.3 – No security content
BIOS 1.7.3 – No security content
BIOS 1.6.6 – No security Content
BIOS 1.5.4 -- No security Content
BIOS 1.4.14 – Intel CPU Microcode update
BIOS 1.3.12 -- No security Content
BIOS 1.3.10 – Intel CPU Microcode update, Intel Management Engine Firmware
How to update
For an individual consumer, updating is obviously done on a one-at-a-time basis. Most OEMs bundle an updating program that compares the device’s model or serial number to an online database that directs it as to what updates are valid. It then assists with the download and installation of the updates, including the firmware. No need to call the computer guy.
For businesses, it’s a little trickier. Business models frequently come with enterprise features such as AMT or VPRO turned on. Generally, you would never want to automatically update a server as you want complete control over what installs and when. Some updates are not as critical as others and the risk of downtime outweighs a risk of compromise. As we have seen with the recent SPECTRE and Meltdown flaws blindly installing updates can result in significant performance and stability issues.(7) Business may also have many thousands of endpoints which also need updating. Allowing each device to phone home and self-update is generally not practical for three reasons: the bandwidth consumption of that many devices phoning-home at the same time would be catastrophic, any sort of phone home is considered a risk for many businesses, and business, in general, have not divested control of what update gets installed vs skipped to the OEMs. The trend has started to pull control away from businesses with Microsoft’s Windows 10 support model only offering cumulative updates (negating the ability to skip an update)
The automatic updating utilities for computers are targeted towards personal use, not shipping with business models, and in most cases not supported on those models. Of course, there is the tried and true direct installation, one at a time, in person, on the machine. However, Firmware and BIOS updates from the OEMs accept command-line based arguments to do everything from making them silent, delay the reboot, force an install, run an inventory, or log the activity so that updates can be pushed via various methods such as login scripts or your favorite software deployment tool. Additionally the major vendors have released administration toolkits specifically for businesses to update and manage firmware and BIOS in their environments.
HP, for example, has released two centralized management methods.(8)(9)
The HP BIOS configuration utility has been around for a number of years and allowed you to create a “golden” BIOS configuration include the BIOS password and system ownership along with deploying of the BIOS update. (10)
Since 2013, HP has also published a utility called the Client Integration kit. The client integration kit integrates with an SMS/SCCM server to deploy BIOS “golden” config files, firmware, and driver updates. It can be configured to operate automatically or with manual intervention.
In Mid 2017, HP renamed the utility to the Management Integration Kit and continued to add features, and in early 2018 released version 2.0 of the SCCM add-on. In the later version, you can not only push updates but also adjust individual settings in BIOS and update the TPM chips.
For its part, Dell released the Client configuration Toolkit from 2003 through 2013.(11) Starting in 2014, the toolkit was renamed to the Dell Command and Configure (DCC). While updates can be delivered using SCCM, Dell has opted to maintain its own management console for DCC. (12)
Both HP and Dell have published a catalog for WSUS/SCCM of all drivers and firmware based on the model. After implementing the System Center Updates Publisher (SCUP), catalogs for these vendors will appear alongside any Microsoft updates. It’s just a matter of selecting them for detection and deployment; packaging is not required.(13)
Is it safe to update BIOS and firmware “over the wire”?
Generally speaking, it is safe to remotely deploy BIOS and firmware updates. The OEMs have gone through the efforts to streamline the process and make tools available to do just that. It’s actually in the OEM’s best interest to make this as safe as possible. Botched BIOS or firmware updates could render a machine dead and subject to a warranty claim. In most cases, modern computers contain two copied of the BIOS. This is in place in case one copy gets corrupted (such as a power failure during updating). The computer can still boot off the untouched version and you can restart the update process. Most failures that occur these days is from forcing an incorrect firmware or an actual hardware fault.
Asking the question a different way, is it SAFE to ignore a security update such as the Firmware for SPECTRE and Meltdown? The adage, “If it ain’t broke, don’t fix it” does not really apply to a security vulnerability means it actually IS broken…just not from the end user standpoint.
Processor flaws are not unique. Intel has had a long history of flaws and subsequent updates required to mitigate. Over the past year, Intel has had to come to terms with three separate disclosures about security flaws in its processors that could lead to a remote system takeover or the divulging of sensitive information. While Intel has had the worst of the press on the issue, all processors are subject to these kinds of flaws.
SPECTRE/Meltdown are fairly serious vulnerabilities that when exploited can’t be detected and do not leave a trace. It is speculated that they have been utilized by advanced hacking groups such as nation/state for years without detection. Now that fixes are out along with detailed whitepapers it is a foregone conclusion that this attack vector is being leveraged. OEMs, Microsoft, Intel, and the US Government are all strongly encouraging installation of the firmware fixes and settings required to close the vulnerability.
Tools exist from the major vendors to aid in the deployment of BIOS and firmware updates along with regular driver updates, the majority of which are released due to a security or performance flaw.
Given the overwhelming coverage of these vulnerabilities, urging from multiple credible sources, and the total lack of ability to determine if an attack against SPECTRE/Meltdown is underway or has occurred it is the position of the author that deployment of BIOS, Firmware, Operating System, and Driver updates that address these specific security flaws should be deployed in a fairly urgent manner. Other updates beyond SPECTRE/Meltdown should be reviewed and a determination based on risk made. Tools that facilitate deployment to large numbers of devices are freely available from the OEMs and should be made available to support the cybersecurity mission.
- NIST National Vulnerability Database; https://nvd.nist.gov/vuln/detail/CVE-2017-5754
- United States Computer Emergency Response Readiness Team https://www.us-cert.gov/ncas/alerts/TA18-004A
- The Verge; Keeping SPECTRE Secret, Jan 11, 2018; https://www.theverge.com/2018/1/11/16878670/meltdown-spectre-disclosure-embargo-google-microsoft-linux
- Tech Crunch; Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device? Jan 3, 2018; https://techcrunch.com/2018/01/03/kernel-panic-what-are-meltdown-and-spectre-the-bugs-affecting-nearly-every-computer-and-device/
- HP Probook 650-G1 Support Page; https://support.hp.com/us-en/drivers/selfservice/hp-probook-650-g1-notebook-pc/5405400
- Dell Precision 7510 Support Page; http://www.dell.com/support/home/us/en/19/drivers/driversdetails?driverId=P5JC8
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
ISC Stormcast For Thursday, March 15th 2018 https://isc.sans.edu/podcastdetail.html?id=5911, (Thu, Mar 15th)
Sigma ransomware was first reported in November 2017 by places like Malware Mayhem and Cofense (formerly PhishMe). Since then, write-ups on Sigma have occasionally appeared on blogs like My Online Security and Bleeping Computer. A list of notable reports follows:
- 2017-11-09 - Malware Mayhem: Threat Actors Go Gree Using Sigma
- 2017-11-10 - Cofense: Threat Actors Put a Greek Twist on Ransomware with Sigma
- 2017-12-01 - My Online Security: fake Visa notification with password protected word doc delivers malware
- 2017-12-20 - Cofense: Recent Sigma Ransomware Campaign Demonstrates Danger in the Simplest of Changes to Malware Delivery
- 2018-03-09 - My Online Security: Regarding a career! Fake resume malspam delivers Sigma Ransomware
- 2018-03-12 - Bleeping Computer: Sigma Ransomware Being Distributed Using Fake Craigslist Malspam
Sigma ransomware activity dropped in January and February of 2018, but during the past week or so, it's come back. I personally hadn't run across it, but I noticed Sigma ransomware from the same type of malspam campaign I reported in a diary last week.
Today's diary looks at the wave of malspam pushing Sigma ransomware on Tuesday 2018-03-13.
Patterns in the email headers, message text, and attachment names for this week's example were nearly the same as last week's diary. This time, the attachment names ended with " resume.doc" with the sender's name before it. These characteristics indicate Tuesday's wave of malspam is from the same campaign, and it continues to push various families of ransomware. As before, each attachment had a different file hash
As early as Friday of last week, this campaign started using password-protected Word documents. The password was always resume as stated in the emails' text. As usual for this type of malicious Word document, enabling macros will kick off the infection process. The enabled macro will cause the victim's host to retrieve a malware binary to infect a vulnerable Windows host.
Enabling macros caused my vulnerable Windows host to download a 3.1 MB Windows executable file stored in the user's AppData\Roaming directory as a .tmp file. After the .tmp file appeared, my Windows host had a tor client installed, and another file of the exact same size with a different file hash appeared in the same directory. After they had done their work, both files were quickly deleted from that location.
After macros were enabled on the Word document, the initial malware binary was downloaded over HTTP using TCP port 80, similar to what we saw this past Friday. The initial download was followed by an IP address check and tor traffic.
Forensics on an infected Windows host
The infected Windows host looked the same as previously reported examples of Sigma ransomware infections. Encrypted files did not have any file extensions added. The ransomware decryptor listed $400 USD as the ransom cost.
My infected lab host had additional files saved to the user's AppData\Roaming\Microsoft directory under a folder with the same name as the ransom ID used in the decryption instructions. An entry was added to the Windows registry to keep the infection persistent.
See below for a list of URLs, domains, and file hashes associated with this malspam.
SHA256 hashes for all attachments:
- f504eaea0e389859e38156255661e879def47fb3a667f032fa06b7dfb84276de - Alane Resume.doc
- e8e485a340a56774ee7c83bbc2be48e4185ed1aeefd17e45f75e445cdb561d8a - Becki Resume.doc
- cfba52ab5d939ba45d38179b743a98832f76eb091d37b6e6f2784e95b58eb566 - Beth Resume.doc
- 9793bef2fa003523961862973b946f09f51005b8ac15bfe3a080d7922fa37ee3 - Braidy Resume.doc
- a27328898c137448a745dc37855881dd22aa15d3502b2f2f578fe4d8d6a60b71 - Deandra Resume.doc
- 5d7a4340695f91d50658cc45a815c1f57998c3eb96eb313f5bfe11c135a1f2ad - Eva Resume.doc
- 5fc458775799db577eafc6fb52e8a42ca3938beed8877a76a5b71f02518a9795 - Felicia Resume.doc
- 58510fbc104d73199361b1bfb93cc44c86f64f422ba04df1b29dd96ba3402f8a - Gary Resume.doc
- c7b041e0f7b34a8ac2a2cdb5e55bf3cc72d9cbcd22a453a78338754914824a0f - Kiaran Resume.doc
- 3fa03e6adab2c240c9da3bf51509453e946be78cc75200e177aae969ce44f0fd - Lorne Resume.doc
The following are malware samples retrieved from my infected lab host:
- SHA256 hash: cd25aa002c73bfb68e0c952d8be90b5380a56972e9d3d90f0769a3a312e687cc
- File size: 3,207,168 bytes
- File location: C:\Users\[username]\AppData\Roaming\BITF881.tmp
- SHA256 hash: cbbb8b1b14b3df9d331ece7167ca9ab2b7da61839742a107142016d8d9c6f8e8
- File size: 3,207,168 bytes
- File location: C:\Users\[username]\AppData\Roaming\taskwgr.exe
File location: C:\Users\[username]\AppData\Roaming\Microsoft\[ransom ID]\taskwgr.exe
The following are URLs and domains associated with these infections:
- 188.8.131.52 port 80 - onlinedocuments.ir - GET /email.bin (ransomware binary)
- port 80 - ip-api.com - GET /json (IP check, not inherently malicious)
- various IP addresses - various TCP ports - tor traffic
- yowl2ugopitfzzwb.onion.link (HTTP link for Sigma decryptor)
- yowl2ugopitfzzwb.onion (tor address for Sigma decryptor)
Ransomware is still at low levels compared to last year, but I'm detecting a small uptick so far during March 2018. We'll see if this trend continues.
Even with the password-protected Word documents, this recent wave pushing Sigma ransomware is no more dangerous than previous ransomware-related malspam attacks. Criminals have already tried these tricks before.
As always, properly-administered Windows hosts are not likely to get infected. To infect their computers, users would have to bypass Protected View and ignore security warnings about activating macros on a Word document. System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.
Pcap and malware samples for today's diary can be found here.
brad [at] malware-traffic-analysis.net
ISC Stormcast For Wednesday, March 14th 2018 https://isc.sans.edu/podcastdetail.html?id=5909, (Wed, Mar 14th)
March 2018 Security Updates (Preliminary. Work in Progress)Description CVE Disclosed Exploited Exploitability (old versions) current version Severity .NET Core Denial of Service Vulnerability %%cve:2018-0875%% No No Less Likely Less Likely Important ASP.NET Core Denial of Service Vulnerability %%cve:2018-0808%% Yes No - - Important ASP.NET Core Elevation of Privilege Vulnerability %%cve:2018-0787%% No No - - Important CNG Security Feature Bypass Vulnerability %%cve:2018-0902%% No No Less Likely Less Likely Important Chakra Scripting Engine Memory Corruption Vulnerability %%cve:2018-0930%% No No - - Critical %%cve:2018-0931%% No No - - Critical %%cve:2018-0933%% No No - - Critical %%cve:2018-0934%% No No - - Critical %%cve:2018-0936%% No No - - Critical %%cve:2018-0937%% No No - - Critical %%cve:2018-0872%% No No - - Critical %%cve:2018-0873%% No No - - Important %%cve:2018-0874%% No No - - Critical CredSSP Remote Code Execution Vulnerability %%cve:2018-0886%% No No Less Likely Less Likely Important Hyper-V Information Disclosure Vulnerability %%cve:2018-0888%% No No Less Likely Less Likely Important Internet Explorer Elevation of Privilege Vulnerability %%cve:2018-0942%% No No - - Important Internet Explorer Information Disclosure Vulnerability %%cve:2018-0929%% No No More Likely More Likely Important March 2018 Adobe Flash Security Update ADV180006 No No - - Critical Microsoft Access Remote Code Execution Vulnerability %%cve:2018-0903%% No No Less Likely Less Likely Important Microsoft Browser Information Disclosure Vulnerability %%cve:2018-0927%% No No More Likely More Likely Important %%cve:2018-0932%% No No - - Critical Microsoft Edge Information Disclosure Vulnerability %%cve:2018-0879%% No No - - Important Microsoft Exchange Elevation of Privilege Vulnerability %%cve:2018-0940%% Yes No Unlikely Unlikely Important Microsoft Exchange Information Disclosure Vulnerability %%cve:2018-0924%% No No Unlikely Unlikely Low %%cve:2018-0941%% No No Unlikely Unlikely Important Microsoft Office Excel Security Feature Bypass %%cve:2018-0907%% No No More Likely More Likely Important Microsoft Office Information Disclosure Vulnerability %%cve:2018-0919%% No No More Likely More Likely Important Microsoft Office Memory Corruption Vulnerability %%cve:2018-0922%% No No - - Important Microsoft SharePoint Elevation of Privilege Vulnerability %%cve:2018-0909%% No No Less Likely Less Likely Important %%cve:2018-0910%% No No Less Likely Less Likely Important %%cve:2018-0911%% No No Less Likely Less Likely Important %%cve:2018-0912%% No No Less Likely Less Likely Important %%cve:2018-0913%% No No Less Likely Less Likely Important %%cve:2018-0914%% No No Less Likely Less Likely Important %%cve:2018-0915%% No No Less Likely Less Likely Important %%cve:2018-0916%% No No Less Likely Less Likely Important %%cve:2018-0917%% No No - - Important %%cve:2018-0921%% No No - - Important %%cve:2018-0923%% No No Less Likely Less Likely Important %%cve:2018-0944%% No No Less Likely Less Likely Important Microsoft Sharepoint Elevation of Privilege Vulnerability %%cve:2018-0947%% No No Less Likely Less Likely Important Microsoft Video Control Elevation of Privilege Vulnerability %%cve:2018-0881%% No No Less Likely Less Likely Important Scripting Engine Information Disclosure Vulnerability %%cve:2018-0891%% No No More Likely More Likely Important %%cve:2018-0939%% No No - - Critical Scripting Engine Memory Corruption Vulnerability %%cve:2018-0889%% No No More Likely More Likely Critical %%cve:2018-0893%% No No - - Critical %%cve:2018-0935%% No No More Likely More Likely Important %%cve:2018-0876%% No No - - Critical %%cve:2018-0925%% No No - - Critical Win32k Elevation of Privilege Vulnerability %%cve:2018-0977%% No No More Likely More Likely Important Windows Desktop Bridge Elevation of Privilege Vulnerability %%cve:2018-0880%% No No Less Likely Less Likely Important %%cve:2018-0882%% No No - - Important Windows Desktop Bridge VFS Elevation of Privilege Vulnerability %%cve:2018-0877%% No No Less Likely Less Likely Important Windows GDI Elevation of Privilege Vulnerability %%cve:2018-0816%% No No - - Important %%cve:2018-0817%% No No More Likely More Likely Important %%cve:2018-0815%% No No - - Important Windows Hyper-V Denial of Service Vulnerability %%cve:2018-0885%% No No Less Likely Less Likely Important Windows Installer Elevation of Privilege Vulnerability %%cve:2018-0868%% No No Less Likely Less Likely Important Windows Kernel Information Disclosure Vulnerability %%cve:2018-0811%% No No More Likely More Likely Important %%cve:2018-0894%% No No More Likely More Likely Important %%cve:2018-0895%% No No More Likely More Likely Important %%cve:2018-0896%% No No More Likely More Likely Important %%cve:2018-0897%% No No More Likely More Likely Important %%cve:2018-0898%% No No More Likely More Likely Important %%cve:2018-0899%% No No More Likely More Likely Important %%cve:2018-0900%% No No More Likely More Likely Important %%cve:2018-0901%% No No More Likely More Likely Important %%cve:2018-0926%% No No More Likely More Likely Important %%cve:2018-0813%% No No More Likely More Likely Important %%cve:2018-0814%% No No More Likely More Likely Important %%cve:2018-0904%% No No More Likely More Likely Important Windows Remote Assistance Information Disclosure Vulnerability %%cve:2018-0878%% No No Less Likely Less Likely Important Windows Security Feature Bypass Vulnerability %%cve:2018-0884%% No No Less Likely Less Likely Important Windows Shell Remote Code Execution Vulnerability %%cve:2018-0883%% No No More Likely More Likely Important Windows Storage Services Elevation of Privilege Vulnerability %%cve:2018-0983%% No No More Likely More Likely Important
This is a guest diary written by Remco Verhoef
The past weeks we’ve seen several large DDoS attacks taking advantage of public accessible memcached instances. By sending UDP packets to lots of memcached instances, with the source address being set to the victim, the return packet will be amplified (50.000 times) compared to the original packet, causing a DDoS of the victim. The largest attack seen so far has been 1.7Tb.
Several reports are referencing that the attacks contain a new method to deliver a ransom note and asking for Bitcoin or Monero. The ransom note (Pay_50_XMR_To) is included within UDP packets sent to the victim. (http://fortune.com/2018/03/02/crypto-hackers-monero-ddos-attack-ransom/)
We have seen attacks before where Elasticsearch, Redis and Mongodb instances had data replaced by ransom notes, claiming bitcoins. The vulnerable memcached instances have been around for a long time, which makes it possible that the data was replaced by an attacker not interested in the DDoS attempt, while another attacker used the same instance (with the content as is, in this case, the ransom note) for an amplification attack.
To effectively use a memcached server in a DoS attack, the attacker will first add data to the server. This will increase the size of the reply. So far, attackers have usually used one letter keys like “a b c d e f g h j k l m n” and then later requested the connect for these keys using the spoofed victim attacks. Within our honeytrap data we see first occurrences using the amplification signature “gets a b c d e f g h j k l m n” and UDP since 24th of February. An interesting fact is that for some reason key i isn’t being queried. In the period before we see a lot of “stats” commands (using TCP) probing our honeytraps. This could have been a first probe to see if there was a vulnerable memcached instance. Important to know is that to add a 1M large value into the database, TCP should be used.UDP is limited by the IPv4 datagram size to 64kBytes, effectively limiting the maximum value size to a little less than 64kBytes.
On 24th and 26th of February we’ve seen several gets being fired from (or spoofed to) host 184.108.40.206. In total we’ve seen gets from (or spoofed to) this host on 24th Feb, 26th Feb, 9th March and 11th March.
At the 26th of February, we’ve also seen host 220.127.116.11. The 27th we’ve seen host 18.104.22.168.
The 1.35 terabits attack on Github took place on the 28th of February. So apparently we’ve had some precursors of this upcoming attack 4 days before in our honeytraps. On and after the 1st of March, at the time of the first publications about the attacks, we’ve seen an increase in the number of attacks.
The gets command being used will retrieve one or multiple exact keys, the DDoS attacker should have known (or prepared) the key.
We’ve added simple support for Memcached stats to Honeytraps. To be sure we don’t inadvertently participate in DDoS attacks UDP answers will be rate limited.
If you take into account the following, then we cannot exclude the possibility that instances had been ransomed before by different attackers than the attackers behind the large DDoS attacks.
vulnerable and abandoned memcache servers have been accessible for a long time
there have been ransoming of databases, indexes and caching servers before
it is not logical to ask for ransom while firing the largest attacks ever
no signs of replacing the data right before the DDoS attack
instead of the XMR ransom note, we now see BTC ransom notes
the cmd being sent to the server contained key names a till n, where many of the instances only contain key a. The initial packet could have been smaller, or the other b .. n keys have been flushed/removed already.
the value should have been set by TCP, because the size of the values we see is close to the default 1M size limit.
The following question arises, did the DDoS attackers took advantage of ransomed instances to execute the DDoS or did they prepare the memcached instances themselves for a longer period of time?