Defending Downwind as the Cyberwar Heats up

The last few weeks have seen a substantial escalation of tensions between Iran and the US as regional cyberattacks gain pace and sophistication with Iran’s downing of a US drone, possibly leveraging its previously claimed GPS spoofing and GNSS hacking skills (to trick it into Iranian airspace) and a retaliatory US cyberattack knocking out Iranian missile control systems. 

While global corporations have been targeted by actors often cited as supported by or sympathetic to Iran, the escalating tensions in recent weeks will inevitably bring more repercussions as tools and tactics change with new strategic goals. Over the last decade, at other times of high tension, sympathetic malicious actors have often targeted the websites or networks of Western corporations – pursuing defacement and denial of service strategies. Recent state-level cyberattacks show actors evolving from long-cycle data exfiltration to include tactical destruction.

State sponsored attacks are increasingly focused on destruction. Holmium, a Middle Eastern actor, has been observed recently by Microsoft to target oil & gas and maritime transportation sectors – using a combination of tactics to gain access to networks, including socially engineered spear phishing operations and password spray attacks – and are increasingly associated with destructive attacks.

Many businesses may be tempted to take a “business as usual” stand but there is growing evidence that, as nation state cyber forces square off, being downwind of a festering cyberwar inevitably exposes organizations to collateral damage. 

As things heat up, organizations can expect attacks to shift from data exfiltration to data destruction and for adversarial tooling to grow in sophistication as they expose advanced tools and techniques, such as zero-day exploits, in order to gain a temporary advantage on the cyber battlefield.

Against this backdrop, corporate security teams and CISOs should focus on the following areas:

1. Pivot SOC teams from daily worklist and ticket queue response to an active threat hunting posture. As state-sponsored attackers escalate to more advanced tools and break out cherished exploits, some attacks will become more difficult to pick up with existing signature and payload-based threat detection systems. Consequently, SOC teams will need to spend more time correlating events and logs, and hunting for new attack sequences.
2. Prepare incident responders to investigate suspicious events earlier and to mitigate threats faster. As attackers move from exfiltration to destruction, a timely response becomes even more critical.
3. Review the organization’s back-up strategy for all critical business data and business systems, and verify their recoverability. As the saying goes, a back-up is only as good as its last recovery. This will provide continuity in the event actors using ransomware no longer respond to payment, leaving your data unrecoverable.
4. Update your business response plan and practice disaster recovery to build your recovery muscle memory. Plan for new threat vectors and rapid destruction of critical business systems, both internal and third-party.
5. Double-check the basics and make sure they’re applied everywhere. Since so many successful attack vectors still rely on social engineering and password guessing, use anti-phishing and multi-factor authentication (MFA) as front-line defenses for the cyberwar. Every privileged account throughout the organization and those entrusted to “trusted” supplier access should be using MFA by default.
6. Engage directly with your preferred security providers and operationalize any new TTPs and indicators associated with Middle Eastern attack operators that they can share with you. Make sure that your hunting tools account for the latest threat intelligence and are capable of alerting the right teams should a threat surface.
7. For organizations that have adopted cyber-insurance policies to cover business threats that cannot be countered with technology, double-check which and what “acts of war” are covered.

While implementing the above advice will place your organization on a better “cyberwar footing”, history shows that even well-resourced businesses targeted by Iranian state-sponsored groups fall victim to these attacks. Fortunately, there’s a silver lining in the storm clouds. Teaming up in-house security teams with public cloud providers puts companies in a much better position to respond to and counter such threats because doing so lets them leverage the massively scalable capabilities of the cloud provider’s infrastructure and the depth of security expertise from additional responders. For this reason, organizations should consider which critical business systems could be duplicated or moved for continuity and recovery purposes to the cloud, and in the process augment their existing on-premises threat response.

-- Gunter Ollmann

First Published: SecurityWeek - July 2, 2019

Analysis of the Flame, Flamer, sKyWIper Malware

The world is abuzz this week with some flaming malware – well “Flame” is the family name if you want to be precise. The malware package itself is considerably larger than what you’ll typically bump into on average, but the interest it is garnering with the media and antivirus vendors has more to do with the kinds of victims that have sprung up – victims mostly in the Middle East, including Iran – and a couple of vendors claiming the malware as being related to Stuxnet and Duku.

A technical report on sKyWIper was released by the Laboratory of Cryptography and Systems Security (CrySys Lab) over at the Budapest University of Technology and Economics yesterday covering their analysis of the malware – discovered earlier in May 2012 – and they also drew the conclusion that this threat is related (if not identical) to the malware described by the Iran National CERT (MAHER) – referred to as Flamer. Meanwhile, Kaspersky released some of their own analysis of “Flame” on Monday and created a FAQ based upon their interpretation of the malware’s functionality and motivations.

There is of course some debate starting about the first detection of Flamer. Given the malware’s size and number of constituent components it shouldn’t be surprising to hear that some pieces of it may have been detected as far back as March 1st 2010 – such as the file “~ZFF042.TMP” (also seen as MSSECMGR.OCX and 07568402.TMP) – analyzed by Webroot and attributed to a system in Iran.
While it’s practically a certainty that the malware was created and infected a number of victims before it was “detected” in May, I’d caution against some of the jumps people are making related to the attribution of the threat.

Firstly, this behemoth of a malware pack is constructed of a lot of different files – many of which are not malicious; with the package including common library files (such as those necessary for handling compression and video capture) as well as the Lua virtual machine. Secondly, when you’re limited to an 8.3 file naming convention, even malicious files are likely to have name collisions – resulting in many spurious associations with past, unrelated, threats if you’re googling for relationships. And finally, why build everything from scratch? – it’s not like malware authors feel honor bound to adhere to copyright restrictions or steal code from other malware authors – nowadays we see an awful lot of code recycling and simple theft as criminals hijack the best features from one another.

As you’d expect from a bloated malware package developed by even a marginally capable hacker, there are a lot of useful features included within. It’s rare to see so many features inside a single malware sample (or family), but not exceptional. As Vitaly Kamluk of Kaspersky stated – “Once a system is infected, Flame begins a complex set of operations, including sniffing the network traffic, taking screenshots, recording audio conversations, intercepting the keyboard, and so on,” – which is more typical of an attack kit rather than a piece of malware. What do I mean by “attack kit”? Basically a collection of favorite tools and scripts used by hackers to navigate a compromised host or network. In the commercial pentesting game, the consultant will normally have a compressed file (i.e. the “attack kit”) that he can shuttle across the network and drop on any hosts he gains access to. That file contains all of the tools they’re going to need to unravel the security of the (newly) compromised host and harvest the additional information they’ll need to navigate onto the next targeted device. It’s not rocket science, but it works just fine.

I’m sure some people will be asking whether the malware does anything unique. From what I can tell (without having performed an exhaustive blow-by-blow analysis of the 20Mb malware file), the collection of files doesn’t point to anything not already seen in most common banking Trojans or everyday hacking tools. That doesn’t make it less dangerous – it merely reflects the state of malware development, where “advanced” features are standard components and can be incorporated through check-box-like selection options at compile time.

For malware of this ilk, automated propagation of infections (and infectious material) is important. Flame includes a number of them – including the commonly encountered USB-based autorun and .lnk vulnerabilities observed in malware families like Stuxnet (and just about every other piece of malware since the disclosure of the successful .lnk infection vector), and that odd print spooler vulnerability – which helps date the malware packaged. By that I mean it helps date the samples that have been recovered – as there is currently no evidence of what the malware package employed prior to these recent disclosures, or what other variants that are circulating in the wild (and not been detected by antivirus products today).

Are these exploits being used for propagation evidence that Stuxnet, Duku and Flame were created and operated by the same organization? Honestly, there’s nothing particularly tangible here to reach that conclusion. Like I said before, criminals are only too happy to steal and recycle others code – and this is incredibly common when it comes to the use of exploits. More importantly, these kinds of exploits are incorporated as updates into distributable libraries, which are then consumed by malware and penetration tool kits alike. Attack kits similar to Flame are constantly being updated with new and better tool components – which is why it will be difficult to draw out a timeline for the specific phases of the threat.

That all said, if the malware isn’t so special – and it’s a hodgepodge of various public (known) malicious components – why has it eluded antivirus products in the victim regions for so long? It would be simple to argue that these regions aren’t known for employing cutting-edge antimalware defenses and aren’t well served with local-language versions of the most capable desktop antivirus suites, but I think the answer is a little simpler than that – the actors behind this threat have successfully managed their targets and victims – keeping a low profile and not going for the masses or complex setups.

This management aspect is clearly reflected in the kill module of the malware package. For example, there seems to be a module named “browse32″ that’s designed to search for all evidence of compromise (e.g. malware components, screenshots, stolen data, breadcrumbs, etc.) and carefully remove them. While many malware families employ a cleanup capability to hide the initial infection, few include the capability of removing all evidence on the host (beyond trashing the entire computer). This, to my mind, is more reflective of a tool set designed for human interactive control – i.e. for targeted attacks.