Information Security News
I was looking at a curious uptick in traffic to TCP port 6881. What caught my eye was that itwas a immediate uptick from almostnothingand it hasbeensustained over a couple of weeks.Also, the number of sources has risen significantly compared to the past year. Here width:600px" />
Heres what it looked like over the past year. Notice the number of sources/day, especially for the time frame above width:700px" />
If anyone has any packets or ideas, please send them in!(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
=============== Rob VandenBrink Metafore(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Researchers at Cisco's Talos threat research group are publishing research today on a targeted attack delivered by a malicious Microsoft Word document that goes to great lengths to conceal its operations. Based entirely on Windows PowerShell scripts, the remote access tool communicates with the attacker behind it through a service that is nearly never blocked: the Domain Name Service.
The malware was first discovered by a security researcher (@simpo13) who alerted Talos because of one peculiar feature of the code that he discovered: it called out Cisco's SourceFire security appliances in particular with the encoded text, "SourceFireSux."
Welp, someone doesn't like SourceFire pic.twitter.com/NzuGXZ0WgC
— simpo (@Simpo13) February 24, 2017
Delivered as an e-mail attachment, the malicious Word document was crafted "to appear as if it were associated with a secure e-mail service that is secured by McAfee," wrote Talos researchers Edmund Brumaghin and Colin Grady in a blog post to be published later today.
I recently had a client get an interesting phishing message. They had received a fake message from their CEO to their Controller - a start the conversation email to end up with a wire transfer. width:1001px" />
Some technical warning signs in that note were:
So the discussion quickly moved from Im glad our execs came to us, we really dodged a bullet there to just how did this get in the door past our spam filter anyway?
This is where things got interesting. Their SPAM filter does use the SPF (Sender Policy Framework) DNS TXT record, and a quick check on the SPF indicated that things looked in order there.
However, after a second look, the problem jumped right out. A properly formed SPF will end with a -, which essentially means mail senders in this SPF record are valid for this domain, and no others. However, their SPF had a typo - their record ended in a ~ instead. What the tilde character means to this spam filter is the mail senders in this SPF record are valid for this domain, but YOLO, so is any other mail sender.
From the RFC (RFC7208), the ~ means softfail, A softfail result is a weak statement by the publishing ADMD that the host is probably not authorized. More detail appears later in the RFC:
A softfail result ought to be treated as somewhere between fail and neutral/none. The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. This same reasoning applies to the ~all and -all directives in the SPF (which I see more often).
Youd think that a lot has changed since 2006 (the date of the original SPF spec, RFC4408), that in 2017 a spam filter should fail on that result, but apparently not (sad panda). Kinda makes you wonder what the actual use case is for that tilde character in the definition - I cant think of a good reason to list permitted mail senders, then allow any and every other server too.
That being said, their filter *should* still have caught the mismatch between the from and reply-to fields, especially since it involved an external source and internal domains. Or at least paired that up with the domain mismatch to weight this email towards a SPAM decision. But thats another rant altogether.
Long story short - this type of attack was pretty popular (and widely reported) about a year ago, but successful methods never (never ever) go away. A little bit of research can make for a really well-formed phish, right down to using the right people in the conversation, good grammar, and phrasing appropriate to the people involved. So a bit of homework can get an attacker a really nice payday, especially if their campaign targets a few hundred companies at a time (and they put more work into their email than the example above)
So in this case, a typo in a DNS record could have cost millions of dollars. Good security training for the end users and vigilant people made all the difference - a phone call to confirm is a must-do step before doing something irrevocable like a wire transfer.
Xavier pointed me towards a new issue posted on Palo Altos Unit 42 blog - the folks at PA found apps in the Google Play store infected with hidden-iframe type malware. 132 apps (so far) are affected, with the most popular one seeing roughly 10,000 downloads. But were not at the end of the trail of breadcrumbs yet .. these apps were traced back to just 7 developers, who arent in the same company, but all have a connection to Indonesia (the smoking gun here was the code signing certificate). But wait, were *still* not at the punchline.
Two more facts to throw into the pot - the malware that the app downloads is a windows executable, so this is unintentional - the developers in question would know that a windows PE wont run on their android platform. The malicious apps also point to sinkholed domains, so they are doubley ineffective. The theory so far is that these 7 developers have all downloaded an infected IDE (Integrated Development Environment) or APK packager, which then infects all of their subsequent android apps.
If this sounds like last years XCodeGhost issue to you (where Apple devs pulled unsanctioned, infected code libraries), you are not alone. Because of their position in the food chain, developers especially need to be careful about what they download, and what ingredients go into making their apps. This means libraries, compilers, IDEs - everything that goes into the pot to make the soup that becomes their app. One infected tool or library can easily affect thousands or millions of end users. Luckily todays issue ends up being a bit of a non-issue - - the malware simply is not effective on the platform its being delivered to. However, if it had been written a bit more cleverly, or been more targetted, it could have become a decent android worm, or the android app could have become a carrier for a plague on windows or OSX hosts. Hopefully its a wake-up call for folks to build their apps using libraries and code directly from the source - a free download generally means that youve just become the product (or the vector to get to the end product).
Kudos to Xiao Zhang, Wenjun Hu and Shawn Jin from Palo Alto Networks for their excellent sleuthing and write-up. They in turn acknowledge Zhi Xu and Claud Xiao from Palo Alto Networks as well as the Google Security team for their help in piecing this together. Full details here: http://researchcenter.paloaltonetworks.com/2017/03/unit42-google-play-apps-infected-malicious-iframes/