Why we Don't Deserve the Internet: Memcached Reflected DDoS Attacks.
Let me start off by saying: If you have a memcached server in your environment that is exposed to the internet, then you should stop scanning for them, and spend your time writing a resume instead. Either because you do not want to work in an utterly incompetent organization like that, or if you are responsible for the exposed server, then well.. write a resume for a simpler job. (I was going to suggest a job here. But I can't come up with a job a sysadmin would be qualified for in a case like this)
Ok. Enough victim bashing (but in this case, you deserve it). The problem: Apparently people are exposing memcached to the internet. For many other services, I would qualify that statement: "without access control". But for memcached there is no access control. This is by design. You are not supposed to expose memcached to the internet, and it says so right in the configuration file:
# Specify which IP address to listen on. The default is to listen on all IP addresses
# This parameter is one of the only security measures that memcached has, so make sure
# it's listening on a firewalled interface.
-l 127.0.0.1
So what will happen if you do expose your memcached server? Imagine that: All your data will be "messed up" (that is a technical term people who do expose memcached servers may understand)
But not only that. memcached offers a simple "stats" command, that will return statistics about the memcached server. Since memcached typically talks via UDP (but TCP works too), you can send the "stats" command from a spoofed IP address. The payload will be 15 bytes. The reply on the other hand will be at least around 1500 bytes, but can be several 100 kBytes in size.
So you got yourself a classic reflective amplified DDoS attack. Luckily, it isn't too hard to block. You should see traffic *from* port 11211 if you are hit by this attack. Blocking all traffic from port 11211 should be possible as all modern operating systems tend to use a source port higher than that for client connections. But given the traffic volumes people are seeing, you will likely need help "upstream" or from an anti-DDoS company.
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|
Malspam pushing Formbook info stealer
Introduction
I wrote a diary about malicious spam (malspam) pushing the Formbook information stealer back in November 2017. Formbook malspam is still a thing. Recently, I've seen malspam with RTF attachments disguised as Word documents. These files use one of the recent exploits targeting unpatched versions of Microsoft Office like CVE-2017-8570 to infect computers with Formbook.
Today's diary reviews recent Formbook malspam from Monday 2018-02-26.
Details
The email is disguised as a requirements document for a supposed sale. The email has a .docx attachment which is a decoy document that checks clean in VirusTotal. The email also has an RTF attachment disguised as a .doc file with the Microsoft Office exploit.
Shown above: Screenshot from the malspam.
Opening the .doc attachment caused the same type of activity I've seen with previous RTF attachments using a CVE-2017-8570 exploit to target unpatched versions of Microsoft Office.
Shown above: Opening the RTF file on a vulnerable Windows host.
Post-infection traffic followed typical URL patterns I've seen before with Formbook. However, an initial HTTP request was caused by the RTF attachment to retrieve the Formbook binary. Checking that server, I found an open directory hosting other malware. Some of the malware was Formbook, some of it was Loki-Bot, and some of it I couldn't immediately identify.
Shown above: Traffic from the infection filtered in Wireshark.
Shown above: Open directory on the compromised server showing more malware.
The infected Windows host showed the same type of artifacts I've seen previously with Formbook malware. Formbook was made persistent on the infected Windows host through an update to the Windows registry.
Shown above: Artifacts in the user's AppData\Roaming directory.
Shown above: Windows registry showing Formbook persistent on the infected host.
File hashes
The following are SHA256 file hashes for malware from the compromised server's open directory:
- 1dc75220bb88f51c4b5360302d9a27e2c2b4371fd9bf7a4ea22fb473b7c2dc6c - amb001.exe
- b0e4efe1a8bba94620599f55d53242ed6a620fac21b0df37a6fd032b7f7e6887 - amo001.exe
- e4376d593b255d9d86c38bcafc03e6257578761250488f36170a06a7d986f853 - dew001.exe
- cb15dd1e1a8d6cf5c4104f5939d9299ad94803e58ec35cb4854b153878a00ce9 - dew002.exe
- ebe6a9d8157723f6094f2ffce63874b360858f9c72b523ed94f389f3d04c4942 - dew003.exe
- ec5355b2bbb85324152dea7ea091ab76de7a66dd2e6df31bfd764c5a2ece5cdc - dew004.exe
- f7ac0508367a4e674f44299d62c17b0001d9e8de8b219ddc190940dad1467997 - dew005.exe
- c702b7774bebf4dc0925c57a87adaa52349e14b43c2d1bd418d3cb3250ef1ab3 - emma001.exe
- bac0420c56402d30e21e1ce9e236efeb294c4a946d8945458593f1b16aa1172c - emma002.exe
- 8c65ba2730e674220ce7a6ccdedaf9d6876430f2ddc13fe4456b9c2eb26ceb08 - mine001.exe
- 37d2de8fd7283a9b2f66fda75a66795d9278b439948b4c17345087e2ab3cc641 - mine001.doc
NOTE: mine001.doc has the same file hash as the RTF attachment from the malspam named Specification.doc.
Final words
As always, properly-administered Windows hosts are unlikely to get infected. To infect their computers, users would have to ignore multiple warnings from Microsoft Word when opening the malicious RTF attachment. System administrators and the technically inclined can also implement best practices like Software Restriction Policies (SRP) or AppLocker to prevent these types of infections.
Pcap and malware samples for today's diary can be found here.
---
Brad Duncan
brad [at] malware-traffic-analysis.net
Comments