AutoIt Scripting Used By Overlay Malware to Bypass AV Detection

13 November 2017

Seven Phases Cyber Kill Chain

Cyber Kill Chain

Anti-Virus (AV) protection works fine if the attacker uses a well-known malware, e.g. Locky, or one of its variants. In this case, the AV scan engine computes the fingerprint of the malicious object and checks it against its fingerprint database. Since a fingerprint is available, the attack is stopped in the delivery phase of a cyber attack the latest.

In the case of the AutoIt Overlay Malware the attacker hides the pattern in an AutoIt script which results in a modified fingerprint. Since this fingerprint is not known in the database the AV scan engine cannot stop the attack. For details about the AutoIt Overlay Malware see this excellent report by Gadi Ostrovsky published on November 8, 2017 in the IBM Security Intelligence blog

Anti-Virus evasion techniques are well known for years. Thus companies are well advised to rely not only on an anti-malware system in their endpoint protection strategy.

My favorite add-on to Anti-Malware systems is still Blue Ridge Networks AppGuard because its available for consumers as well as for businesses. AppGuard would block the AutoIt Overlay Malware during the installation phase the latest because it just blocks the execution of whatever objects from inside a user’s home directory.

Have a great week.

Advertisements

Microsoft announces unbreakable Edge Browser with Windows 10 Fall Creators Update

4 November 2017

On 13 July 2015 Bromium announced a partnership with Microsoft to integrate the Bromium micro-virtualization technology in Windows 10. Two years later, on 23 October 2017, Microsoft announced the Windows 10 Fall Creators Update. With this update, Microsoft enhances Systems Center Endpoint Protection by many new security functions. The Bromium micro-virtualization technology is integrated in Windows Defender Application Guard (WDAG):

Windows Defender Application Guard makes Microsoft Edge the most secure browser for enterprise by hardware isolating the browser away from your apps, data, network and even Windows itself. WDAG protects your Microsoft Edge browsing sessions so if users encounter malware or hacking attempts while online they won’t impact the rest of your PC.

This sounds very promising! For details see this post published on 23 October 2017 in the Windows Security blog.

Unfortunately, currently only enterprise customers benefit from WDAG. I would appreciate it if Microsoft would integrate WDAG as soon as possible in all Windows versions to allow consumers and small businesses to benefit from WDAG as well.

Have a great weekend.

Oh dear! Oh dear! I shall be too late! – The White Rabbit

29 October 2017

WannaCry, NotPetya, and now: Bad Rabbit. The good news is that Bad Rabbit isn’t spreading as fast as WannaCry and NotPetya. According to a DARKReading report from October 25th the outbreak appears to die down already.

The bad news is, that it happened again. Like the White Rabbit in Alice’s Adventure in Wonderland, IT departments seem to mutter only “Oh dear! Oh dear! I shall be too late!”, instead of increasing the security baseline of their company networks.

Bad Rabbit uses similar techniques as WannaCry and NotPetya for spreading in the networks:

Open SMB shares, Mimikatz alike ways to dump credentials from the affected systems, a hardcoded list of credentials, … For more technical details see this post from Malwarebytes Labs.

The methods to avoid this are well-known and easy and cheap to implement:

  • Run a user awareness campaign.
  • Reduce the number of users and administrators working with permanent administrative privileges to zero. This is a leadership task!
  • Apply the measures to mitigate Pass-the-Hash attacks to all Windows systems and networks.
  • Limit the functionality of technical users to local systems and the lowest possible privileges. Use individual passwords, eliminate default passwords.
  • Review all firewall rules. Question every required connection. Limit the use of the SMB protocol as far as possible. Eliminate the use of unsecured protocols as far as possible. Patch the systems at the endpoints of firewall rules.

The above list is not exhaustive, but if implemented, the attacker’s ability to explore the network is clearly reduced.

It appears to me, that everyone is waiting for Windows 10 to solve some of the issues. This however is the wrong approach. Windows 10 cannot be introduced with a big bang. In particular in the production, lab, and building automation domain, it will take a few years until we can shutdown Windows XP/7 completely. And during this years, our networks are at risk.

With this, there is no time to lose. The White Rabbits returns.

Have a great week.

To panic, or not to panic, that is the question: A simple panic calculator

22 October 2017

Last week, I had some interesting discussions about when to panic if a new vulnerability is published. With the concept of critical vulnerabilities in mind, this is an easy task:

My Panic Level Calculator

My Panic Level Calculator

To be honest, the panic in the media about the WPA2 / Krack vulnerability published last week appears somewhat exaggerated. CVE-2017-11292 however, a remote code execution vulnerability in Flash Player published on 16 October 2017, was not discussed in the media at all, although Kaspersky found an exploit on 10 October 2017.

Please keep in mind that critical vulnerability must be mitigated before an exploit is available on the market. The flash player vulnerability shows, that immediate action is required.

Have a great week!

New vulnerability in SIMATIC WINCC systems – Don’t Panic!

20 October 2017

Yesterday morning I found a notification about a new vulnerability in Siemens SIMATIC WINCC systems from the manufacturer’s product CERT on LinkedIn. CVE-2017-6867 is network exploitable, thus every WINCC system that is accessible from the internet is potentially vulnerable. But that is no reason for panic.

A closer look at the CVE details revealed that the vulnerability “could allow an authenticated, remote attacker who is member of the “administrators” group to crash services by sending specially crafted messages to the DCOM interface”.

To be honest, it is not worth studying more details. To exploit this vulnerability, the attacker needs to be a member of the administrators group of the WINCC system.

But why should the attacker send specially crafted messages to the DCOM interface if he can easily compromise the entire SCADA network by leveraging windows built-in utilities? 

Moreover, it’s not worth patching this vulnerability immediately, if at all. If patching is required due to compliance reasons, it can wait until the next scheduled maintenance.

This endless stream of new vulnerabilities pulls us away from doing the right and important things, e.g. implementing good account and password practice in the SCADA active directory.

Have a great weekend.

Top secret information about Australia’s military hacked – SME’s overstretched with Cyber Security Frameworks

15 October 2017

Lisa Martins report Top secret information about Australias military hacked, published on October 12th, 2017 at news.com.au, about a one year old attack on an Australian defense contractor is another example that small businesses are technically and organizationally overstretched with the challenges of cyber security.

The best approach for SMEs would be to set up a cyber security framework like the NIST Cyber Security Framework or an ISO 27001 based framework. But the effort to do this is for small businesses just too high.

For SMEs to stay ahead of the cyber security curve a light version of such frameworks is required, with focus put on actively managing the risk.

The Strategies to Mitigate Cyber Security Incidents of the Australian Signals Directorate (ASD) puts focus on the basics. If carefully implemented and regularly assessed, the security level goes up and this kind of attacks are no longer possible. Even large businesses can raise their security level when implementing the ASDs recommendations.

But when it comes to critical infrastructures a full implementation of a cyber security frameworks is the only way to survive in the long-term. By the way, the first task in the NIST CSF core is asset management…

Have a great week.

Congress hearing brings light into the Equifax darkness – Trust in the results of vulnerability scans a possible cause for the Equifax data breach?

8 October 2017

On October 3rd, 2017 a hearing titled “Oversight of the Equifax Data Breach: Answers for Consumers.” was conducted by the Subcommittee on Digital Commerce and Consumer Protection of Committee on Energy and Commerce of the 115 U.S. congress.

Sarah Buhr’s report “Former Equifax CEO says breach boiled down to one person not doing their job” posted on October 3rd, 2017 on TechCrunch gives a good summary of the hearing results.

And a surprisingly plain cause for the data breach:

‘“The human error was that the individual who’s responsible for communicating in the organization to apply the patch, did not,” Smith, who did not name this individual, told the committee.’

To be honest, this sounds somewhat too easy.

In the witness statement of Mr. Smith one reads:

[1] “On March 9, Equifax disseminated the U.S. CERT notification internally by email requesting that applicable personnel responsible for an Apache Struts installation upgrade their software. Consistent with Equifax’s patching policy, the Equifax security department required that patching occur within a 48 hour time period.

[2] “We now know that the vulnerable version of Apache Struts within Equifax was not identified or patched in response to the internal March 9 notification to information technology personnel.”

[3] “On March 15, Equifax’s information security department also ran scans that should have identified any systems that were vulnerable to the Apache Struts issue identified by U.S. CERT. Unfortunately, however, the scans did not identify the Apache Struts vulnerability. Equifax’s efforts undertaken in March 2017 did not identify any versions of Apache Struts that were subject to this vulnerability, and the vulnerability remained in an Equifax web application much longer than it should have.”

[4] “The company knows, however, that it was this unpatched vulnerability that allowed hackers to access personal identifying information.”

From [1] we learn that Equifax has a good vulnerability management process in place.

From [2] and [3] we learn that Equifax’s vulnerability scanner did not find the systems with the vulnerable version installed, although the company knew that the vulnerable Apache Struts framework was installed on some systems.

There are many reasons for this. Just two examples:

  1. Vulnerability scanners must be updated regularly to keep pace with the threat market. But there is often a gap between the release of a scanner update and the disclosure of a vulnerability.
  2. Even up-to-date vulnerability scanners provide no 100% detection. In addition, the results are often somewhat puzzling.

From my point of view, the trust in the results of the vulnerability scanners is the cause for the data breach. Because of the gap between the release of a scanner update and the disclosure of a vulnerability an up-to-date asset repository, at least for the systems facing the internet, is of desperate need for fast identification of vulnerable systems.

The reduction to a human error is just too plain. This sounds more like a systematic error. And provides some interesting food for thought for the next week.

Have a great week.