Tag Archives: STIG

Lessons Learned from the Latest Ransomware Attack on an ESXi Host

19 October 2021

Lisa Vaas’s report about a ransomware attack on a VMware ESXi infrastructure is worth a detailed analysis because it reveals some interesting details on the attackers intentions.

The attack happened very fast and targeted. Vaas cites the Sophos press release: “This is one of the fastest ransomware attacks Sophos has ever investigated, and it appeared to precision-target the ESXi platform”.(Vaas 2021; Sophos Ltd. 2021)

How got the attacker initial access to the network?

The attackers used an inadequately secured TeamViewer remote access to break into the company. The hijacked account “had domain administrator access credentials“.(Sophos Ltd. 2021)

The ransomware operator was not interested in the Active Directory

It is very remarkable that the attackers then focused on the ESXi server. If an attacker is able to hijack an account that is member of the domain administrators group, he has got the keys to the kingdom. An APT would then act very carefully to stay as long as possible undetected.

But the ransomware operator made the right decision. To stay undetected in a network for weeks or months requires technical skills that ransomware operators just lack. This was an economically sensible decision.

The course of events shows some shortcomings in security best practice

Working with TeamViewer in unattended mode without a second factor is bad enough in itself, but, connecting to an account with domain admin privileges under this terms, violates any best practice.

User account control is available since Windows Vista, so there is no need to work with permanent administrative privileges. Moreover, Microsoft makes clear that “There should be no day-to-day user accounts in the DA group with the exception of the local Administrator account for the domain”.(Microsoft 2021)

ESXi servers were transparently accessible in the network, with active shell enabled

„The investigators believe the ESXi Server on the network was vulnerable because it had an active Shell, a programming interface that IT teams use for commands and updates.“(Sophos Ltd. 2021)

The IT team was aware of active shell security issue. “This organization’s IT staff was accustomed to using the ESXi Shell to manage the server, and had enabled and disabled the shell multiple times in the month prior to the attack. However, the last time they enabled the shell, they failed to disable it afterwards. The criminals took advantage of this fortuitous situation when they found the shell was active.”(Brandt 2021)

Adoption of ESXi security best practice would have reduced the impact

Good security practice restricts the accessibility of critical systems like the ESIx host. This can be done by isolating the ESIx hosts in separate network segment and restricting administrative access from an admin segment. Or by configuring the ESXi firewall to allow only connections from dedicated systems.

A good starting point is the VMware guideline “Securing the ESXi Hypervisor”.(VMware Inc. 2020). The DoD VMware ESIx STIG (Security Technical Implementation Guide) gives more details.(Network Frontiers LLC 2018)

Rule SV-77743r1_rule of the VMware ESIx STIG deals with the active shell issue: “The system must terminate shell services after a predetermined period.” The DoD requests to use 600s as timeout.

What can we learn from this attack?

  • Operations security is indispensable.
  • “Defense in depth” must be applied to secure ESXi hosts.
  • Security best practice and hardening guides are available.
  • Security best practice must be implemented and followed.

Have a great day!

References

Brandt, Andrew. 2021. “Python Ransomware Script Targets ESXi Server for Encryption.” Sophos News (blog). October 5, 2021. https://news.sophos.com/en-us/2021/10/05/python-ransomware-script-targets-esxi-server-for-encryption/.

Microsoft. 2021. “Implementing Least-Privilege Administrative Models.” Microsoft Docs. July 29, 2021. https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/implementing-least-privilege-administrative-models#securing-domain-admins-groups.

Network Frontiers LLC. 2018. “VMware VSphere ESXi 6.0 Security Technical Implementation Guide.” STIG Viewer | Unified Compliance Framework®. 2018. https://www.stigviewer.com/stig/vmware_vsphere_esxi_6.0/2019-01-04/.

Sophos Ltd. 2021. “Sophos Researchers Uncover New Python Ransomware Targeting an ESXi Server and Virtual Machines in an Ultra-High-Speed Attack.” Sophos Press Release. October 5, 2021. https://www.sophos.com/en-us/press-office/press-releases/2021/10/sophos-researchers-uncover-new-python-ransomware-targeting-an-esxi-server-and-virtual-machines.aspx.

Vaas, Lisa. 2021. “VMware ESXi Servers Encrypted by Lightning-Fast Python Script.” Threatpost. October 6, 2021. https://threatpost.com/vmware-esxi-encrypted-python-script-ransomware/175374/.

VMware Inc. 2020. “Securing the ESXi Hypervisor.” VMware Docs. February 24, 2020. https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-E9B71B85-FBA3-447C-8A60-DEE2AE1A405A.html.

How to defeat antivirus evasion and privilege escalation techniques

4 February 2018

Last weekend I read two very informative posts on Antivirus Evasion by Mattia Campagnano. But part 2 [1] puzzled me somewhat.

“Following up to my previous post Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt. 1), we’re going now to perform the same attack on a genuine Windows 10 machine, where all latest updates have been installed.”

For a moment I thought ‘a security professional mistakes compliance for security’ because ‘fully patched’ means not that the system is resilient against cyber-attacks. But both posts show that even the most secure Windows ever is vulnerable against privilege escalation and AV evasion if the basic configuration is not changed and fundamental elements of cyber hygiene are missing.

Why are such attacks successful?

First, the user was logged in with permanent administrative privileges. This makes life easy for attackers and fosters lateral movement.

Revoking permanent administrative privileges on workstations and servers must be a basic element of any cyber security program. Under normal conditions, standard users should not have any administrative privileges for their devices at all. If needed, they can be temporarily granted through User Account Control (UAC).

Second, UAC was not set to the highest level “Always notify me”. Unfortunately this is the standard setting after a fresh installation of Windows. With this, privilege escalation is possible without user notification. If configured properly, UAC will notify the user even if he works with administrative privileges.

The BypassUAC method in the meterpreter attack framework will fail, if UAC is set to the highest level. The following excerpt of the code [2] makes this clear

case get_uac_level
 when UAC_PROMPT_CREDS_IF_SECURE_DESKTOP,
      UAC_PROMPT_CONSENT_IF_SECURE_DESKTOP,
      UAC_PROMPT_CREDS, UAC_PROMPT_CONSENT
 fail_with(Failure::NotVulnerable,
  "UAC is set to 'Always Notify'. This module does not bypass this setting, exiting..."
 )
 when UAC_DEFAULT
    print_good('UAC is set to Default')
    print_good('BypassUAC can bypass this setting, continuing...')
 when UAC_NO_PROMPT
    print_warning('UAC set to DoNotPrompt - using ShellExecute "runas" method instead')
    shell_execute_exe
  return
end

Standards like the DISA STIG for Windows 10 [3] activate all UAC features to make life for the attackers as difficult as possible. From my point of view, the STIGs should be considered also in industry to create workplaces resilient against cyber-attacks. And Microsoft should raise the Windows default for UAC to “Always notify me” for all versions. If a user wants to reduce the security level, he should do this on his own responsibility.

Besides the secure configuration of IT systems and cyber hygiene is user awareness training the third essential pillar of a security program. Users and help desk staff must take proper actions if their system unexpectedly enters the secure desktop and asks for permissions of an action they never asked.

Have a good weekend.

  1. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 44: AV Evasion (pt 2). The S@vvy_Geek Tips Tech Blog
  2. Rapid7 bypassuac_vbs.rb  Metasploit Framework. (Accessed: 3rd February 2018)
  3. Windows 10 Security Technical Implementation Guide. STIG Viewer | Unified Compliance Framework® Available at: https://www.stigviewer.com/stig/windows_10/. (Accessed: 3rd February 2018)
  4. Campagnano, M. Tips for an Information Security Analyst/Pentester career – Ep. 43: AV Evasion (pt.1). The S@vvy_Geek Tips Tech Blog

How to mitigate Drive-by-Downloads Attacks

24 January 2014

Bad news for Adobe Flash Player users. A new critical vulnerability (CVE-2015-0311) was found in Adobe Flash Player 16.0.0.28… Successful exploitation could cause a crash and potentially allow an attacker to take control of the affected system.

In the Adobe Security Bulletin we read ‘We are aware of reports that this vulnerability is being actively exploited in the wild via drive-by-download attacks against systems running Internet Explorer and Firefox on Windows 8 and below.’

Drive-by-download (DbD) attacks are a often used technology to exploit vulnerabilities in programs. In his post ‘How malware works: Anatomy of a drive-by download web attack’ John Zorabedian from SOPHOS gives a detailed description about how DbD attacks work.

The shocking fact is: It’s not even necessary to click a link on the malicious site. If you just load the site the malware download could start, automatically and silently in the background.

The good news is that we could almost completely deactivate this feature, namely without considerable comfort loss. The Security Technical Implementation Guide (STIG) for Internet Explorer 11 shows the direction.

STIG’s are primarily used to secure the information systems of the Departments of Defense, but this should not deter us from using STIGs to secure our systems at home, and of course in our businesses.

STIGs are available from http://www.stigviewer.com/stigs for operating systems, web servers, databases or applications. They are an excellent means to secure the devices that are connected to the internet against malicious attacks. But, be aware that 100% safety could not be achieved.

Applying STIGs to Microsoft operating systems and applications is very easy if you are familiar with the registry editor regedit.exe and the local group policy editor gpedit.msc. Since only standard windows security options are used the recommended settings could be applied to all computers.

Back to the Drive-by-Download attacks. To prevent DbD attacks we have to configure Internet Explorer such that downloads not consented by the user are blocked. Sound’s easy, doesn’t it? We have just to work through the STIG for Internet Explorer 11 and implement the relevant fixes:

Step 1: Block non user-initiated file downloads

The DoD requirements block unconsented downloads from the Restricted Sites Zone and the Internet Zone. Since I would not trust computers in local networks as well I would strongly recommend to block unconsented downloads from all zones.

Implement at least Fixes from Finding Ids V-46705 and V-46643

Step 2: Block non user-initiated file downloads for Internet Explorer Processes

Implement Fixes from Finding IDs V-46779 and V-46781

Step 3: Enforce Protected Mode

Protected Mode protects Internet Explorer from exploited vulnerabilities by reducing the locations Internet Explorer can write to in the registry and the file system. I would recommend to enforce protected mode for all zones.

Implement at least Fixes from Finding IDs V-46685 and V-46681

Step 4: Enforce Enhanced Protected Mode on 64 bit Windows Systems

Implement Fix from Finding ID V-46987

That’s it for today. Please keep in mind that 100% safety could not be achieved, even if you implement the 155 fixes from the IE11 STIG.

Don’t Panic! And have a good weekend.