Last Updated: 2015-10-24 02:59:50 UTC
by Brad Duncan (Version: 1)
In early September 2015, we started seeing reports about arrests tied to Dridex malware [1, 2]. About that time, we noticed a lack of botnet-based malicious spam (malspam) pushing Dridex malware. During the month of September, Dridex disappeared from our radar. By the beginning of October 2015, malspam pushing Dridex came back , and it's continued since then.
From what I can tell, Dridex was gone about a month, for most of September 2015.
Even though Dridex came back, organizations have still been discussing the previous takedown. The most recent wave of reporting happened in mid-October after the US Justice Department (DoJ) published a news release discussing the August 2015 takedown . The DoJ release on Dridex (also known as "Bugat" or "Cridex") reported the botnet administrator had been arrested back in August, and the botnet's operations were substantially disrupted. That was old news, but it spread anew as other organizations passed on the information [5, 6, 7, to name a few]. Some of those reports warned that botnets are rarely disrupted for long, and that's certainly been the case with Dridex.
When did the outage start? When did it stop? The Dridex botnet administrator was arrested on 2015-08-28 , and Palo Alto Networks reported Dridex was back by 2015-10-01 . That represents an outage of approximately one month. Let's get a clearer picture of how long the Dridex botnet was disrupted by searching VirusTotal using hashtags.
This morning (Friday 2015-10-23) when I searched VirusTotal for #Dridex, I found more than 80 comments posted by at least a dozen individuals after the 2015-08-28 arrest. These #Dridex comments covered 28 Word documents, 4 Excel spreadsheets, and 37 Win32 EXE files. I also found 14 URLs tagged as #Dridex in the comments.
I compiled a spreadsheet of the data. It's saved as a .csv file available here. In it, you'll find an absence of #Dridex-tagged submissions after 2015-09-02. #Dridex-tagged submissions resumed on 2015-10-01. This matches what Palo Alto reported , and it gives us a little more insight on the Dridex disruption.
The hashtag is a quick way to find files that people have specifically identified as Dridex. Some of the files may have been mistakenly identified, so there's room for error. However, this preliminary analysis backs up what Palo Alto reported , and plenty of us are seeing Dridex malspam on a near-daily basis now.
Dell SecureWorks has a good description of the architecture behind Dridex . More recent write-up about Dridex malspam are available from sites like Dynamoo's Blog  and Techhelplist.com . Twitter is also a good source for Dridex information and plenty of commentary.
Shown above: Example of Twitter commentary on the recent Dridex takedown (link).
In the past few days, we've received samples of malspam attachments submitted by our readers. Some of these submissions have been malicious Word documents associated with Dridex. As always, handlers at the ISC continue to monitor the cyber landscape, and we'll keep you up-to-date on any recent trends.
Last Updated: 2015-10-23 15:52:37 UTC
by Johannes Ullrich (Version: 1)
Maksymilian Arciemowicz of CXSECURITY released an advisory showing an unpatched buffer overflow in Apple's FTS library . The "FTS" function is used by commands like "ls" and "cd" on Unix/BSD systems to traverse the file system. The exploit does not appear to present a serious threat right now as it requires an authenticated user on the system with the ability to create directories. It doesn't appear to lead to privilege escalation.
In order to trigger the vulnerability, the attacker will have to create a very deep set of subdirectories. Maksymilian creates 1024 with a simple bash script. While creating these directories, an error message, "
cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory" will be displayed.
After returning to the top of the nested subdirectory structure, a recursive "ls -laR" will lead to a segmentation fault.
The impact of this vulnerability is likely small as it is not exploitable remotely and requires a user to be already logged in. But Maksymilian notes that man AV tools will miss binaries located more then 512 directories deep in such a nested file system, so it could be used to hide malware.