Information Security News
The much-maligned Java browser plugin, source of so many security flaws over the years, is to be killed off by Oracle. It will not be mourned.
Oracle, which acquired Java as part of its 2010 purchase of Sun Microsystems, has announced that the plugin will be deprecated in the next release of Java, version 9, which is currently available as an early access beta. A future release will remove it entirely.
Of course, Oracle's move is arguably a day late and a dollar short. Chrome started deprecating browser plugins last April, with Firefox announcing similar plans in October. Microsoft's new Edge browser also lacks any support for plugins. Taken together, it doesn't really matter much what Oracle does: even if the company continued developing and supporting its plugin, the browser vendors themselves were making it an irrelevance. Only Internet Explorer 11, itself a legacy browser that's receiving only security fixes, is set to offer any continued plugin support.
Some of these blocked emails have malicious Microsoft Office documents (Word, Excel, etc.) as file attachments.
Most of these Office documents have macros that, if enabled, will download and install malware on an unprotected Windows host. Payloads vary with this type of malspam. Weve seen CryptoWall  and Pony or other downloaders pushing further payloads [2, 3, 4].
However, Dridex is by far the most common malsapm we see using malicious Office documents. Several sources routinely report waves of Dridex malspam [for example: 5, 6, 7]. Ive already posted some diaries about Dridex here for the Internet Storm Center (ISC) [8, 9, 10].
I havent posted any technical details on Dridex in the past few months, so I figure were overdue for a review.
What is Dridex?
Dridex is credential-stealing malware that targets Windows clients like desktops and laptops. Dridex is designed to steal credentials and obtain money from victims bank accounts. The malware is generally distributed through email . however, it is more accurately described as malspam. The criminal organizations behind this malware rely on Microsoft office documents containing malicious macros to download Dridex onto an unsuspecting users Windows computer .
First spotted around November 2014, Dridex is considered the direct successor of Cridex banking malware . Dridex malspam has been fairly consistent since then, usually appearing on a near-daily basis. Dridex disappeared about a month in September 2015 after the arrest of an administrator for a botnet delivering the malware. By October 2015, Dridex malspam was back , and its been appearing on a near-daily basis up through the present day.
According to IBM security intelligence, Dridex released a new malware build earlier this month on 2016-01-06. This new build was followed by a malspam campaign using the Andromeda botnet to deliver malware to would-be victims. Campaigns have mainly focused on users in the UK .
Dridex malspam from Monday 2016-01-25
On Monday 2016-01-25, we saw a wave of 558 Dridex malspam messages." />
Shown above:">Shown above: End of the list of emails I found for this Dridex wave on Monday 2016-01-25.
Shown above: One of the Dridex emails seen on Monday 2016-01-25.
The sender, subject lines, message text, and attachment names are different for each email sent by the botnet." />
Shown above: A pcap of the infection traffic, filtered in Wireshark. This image was edited in order to fit as much information as possible.
Enabling the macros caused an HTTP GET request for Dridex malware." />
Shown above: The malicious Word documents macro downloading a Dridex executable.
The remaining traffic includes SSL over TCP ports 4143 and 443. The infected host contacted other IP addresses that didnt respond, and we saw some encrypted traffic for two other IP addresses over TCP port 444. The SSL traffic used certificates similar to Dridex examples we" />
Shown above: A TCP stream from the pcap in Wireshark, with data on one of the SSL certificates highlighted.
Overall, this was a fairly straight-forward example of recent Dridex activity. There were no tricks to obfuscate or hide the initial malware downloaded by the document macros. Too bad I didnt get an example from some of the trickier methods Dridex uses to disguise this initial download [15, 16]. Dridex malspam is sent by different botnets. The associated malware will have different characteristics depending on the wave of malspam sent by a particular botnet . Todays diary only provides one such example.
Traffic and malware used for this diary can be found here.
If you have a properly-configured Windows host in a well-administered environment, your risk of infection is low. Unfortunately, humans are the weakest link in this infection chain. I still hear an occasional story about someone who was infected with Dridex. These waves of malspam must be profitable for the criminals behind Dridex, or we wouldnt continue seeing them.
Have you seen Dridex this year? Has anyone had to respond to a Dridex infection? If so, please share your story by leaving a comment below.
How millennials can be the saviors -- not the scourge -- of the security staffing shortage
This blog covers topics across the spectrum of security, privacy and compliance, as well as the people and issues driving enterprise infosec today. Latest Blog Posts. Cybersecurity and CES 2016: A comedy of omissions · The transaction that lasts ...
We havent had an event like this in a while... Odd Packets! I was going through some honeypot packet captures with tcpflow, when I got this error message:
$ tcpflow -r ../allpackets Wifipcap() tcpflow: TCP PROTOCOL VIOLATION: SYN with data! (length=970)
It has been a while since I got SYN packets with data! So I had to look closer:
$ tcpdump -r ../allpackets -nX tcp=2 ip[2:2]- ((ip0x0f)*4)-(tcp4)*40 reading from file ../allpackets, link-type EN10MB (Ethernet)
Nothing! Is tcpflow wrong? Well... I may be a bit too picky with tcp=2. Lets make Judy proud and use a bitmask:
tcpdump -r /tmp/allpackets -xn tcp2=2 ip[2:2]- ((ip0x0f)*4)-(tcp4)*40 reading from file /tmp/anon2, link-type EN10MB (Ethernet) 08:43:59.138235 IP 192.0.2.1.9090 192.0.2.2.27450: Flags [S.], seq 159625496:159626466, ack 770903892, win 12960, length 970 0x0000: 4508 03f2 530f 4000 2e06 71eb c000 0201 0x0010: c000 0202 2382 6b3a 0983 b118 2df3 0f54 0x0020: 5012 32a0 6ec5 0000 0000 0000 0000 0000 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000
Here we got it. It was actually a SYN-ACK, not a SYN that had the payload. The payload was all 0x00 (I truncated the output).
There was no SYN going to that IP address, so this was an unsolicited response (backscatter). Has anybody seen traffic like this? So far, this was the only packet I have seen. The original source IP was 22.214.171.124. DoS agains the analyst? Or some kind of new TCP based reflective DoS off a real broken service?
ISIS affiliate Cyber Caliphate announces plans to hack Google
Remember Cyber Caliphate? Yes, the hacking group affiliated to IS or ISIS/Daesh is planning to hack Google. According to International terrorism watchdog group Terror Monitor, the Islamic State “cyber army” has announced plans to hack Google.
We still got two surveys running, and will probably close them out soon:
Our year end, how to improve survey:https://dshield.typeform.com/to/W5p1Cu
If you are interested in submitting logs to usbut are not doing so right now survey:https://dshield.typeform.com/to/t5g9K8
Also, we will start using a new twitter account, @netsecjobs, to post new job ads submitted to our jobs section. (submitting jobs is free, but the job has to prefer candidates with a GIAC certification)
Insurers Getting Smarter About Assessing Cyber Insurance Policy Risks
As that happens, customers could experience some pain as insurance companies get wise to the red flags of poor information security practices. But overall, this maturation could mean good things for cyber-insurance customers and the infosec world as a ...