Tag Archives: Security

Identifying Groups of "Bot" Accounts on LinkedIn, (Tue, Nov 29th)

This post was originally published on this site

As some have noted, LinkedIn has recently removed many accounts after identifying them as "bots" or "disingenuous" [1]. These removals are relatively easy to spot if they affect large companies like Amazon, Apple, and others. But they are a bit more challenging to spot if the fake accounts claim to work for smaller, relatively unknown companies.

Ukraine Themed Twitter Spam Pushing iOS Scareware, (Mon, Nov 28th)

This post was originally published on this site

With the expansion of Russia's invasion of Ukraine in February, Ukraine has made heavy use of social media to demonstrate die ability of the Ukrainian armed forces to repulse the attack. Ukraine often shares video clips showing attacks against Russian troops from drones or action camera footage from the front lines. These videos have been widely distributed, and various social media channels have shared them to build an audience for themselves.

Happy 22nd Birthday DShield.org!, (Fri, Nov 25th)

This post was originally published on this site

Traditionally, I consider the Thanksgiving weekend of 2000 the "Birthday" of DShield. I coded the first version of DShield over that weekend and made it public soon after. My records aren't that great, but here is an early screenshot of DShield.org courtesy of archive.org. There are a couple earlier once, but they are a bit too embarassing to post here :). What is now the Internet Storm Center was known as incidents.org back then.

Attackers Keep Phishing Victims Under Stress, (Thu, Nov 24th)

This post was originally published on this site

Phishing campaigns are very common today, we receive many phishing attempts per day. Why attackers are still flooding our mailboxes with such emails? Because it sill works, and the "return on investment" of sending millions is reached even if only a few victims are lured. However, attackers are always looking for new techniques to make people confident that the message is legit. Many phishing campaigns are pretty well prepared, and the fake mail you receive looks exactly like an official one. Multiple times, I was pretty close to click on a link… Yes, we are all poor humans!

Log4Shell campaigns are using Nashorn to get reverse shell on victim's machines, (Mon, Nov 21st)

This post was originally published on this site

Almost one year later, Log4Shell attacks are still alive and making victims. Log4shell, as you may remember, was the name given to a remote code execution (RCE) vulnerability in the Apache Log4j Java library, first known on December 10th, 2021.  Information on the zero-day (CVE-2021-44228) and malicious campaigns using it were covered here in SANS ISC in different diaries like here and here.

McAfee Fake Antivirus Phishing Campaign is Back!, (Sat, Nov 19th)

This post was originally published on this site

Yesterday I received this email that my McAfee antivirus subscription is expired and that my computer is already infected with 5 viruses (how do they know?). The overall content of this email is simple and direct to the point and is similar to something Xavier posted earlier this year [1]. 

 

The email sound scary (infected with malware), however, a few clues from the email header, the sender is not McAfee, whatever they are asking me to do, indicate I'm the target of a phishing email and they likely want money. 

The body of the email claims I'm already compromised and to resolve the issue is to first run a online scan against my host. I copied the hidden URL in CONTINUE and used wget to get a copy of the site. This is the step-by-step results:

 

 

And it found 35 harmful viruses on my computer.

 

Last, the results of the scan and what malware was found on the PC. The initial email claimed the computer was infected with 5 viruses, then 35 and at last after the final scan, there is only one

 

 

What I found interesting, it didn't matter how many times I ran the scan, it always returned the same results (live scan and with the wget copy). Virustotal has very low detection and with 2 vendors identifying this as spam [2]. I got curious and lookup Tapsnake and it turned out it " is a scareware scam involving coercion to buy protection from a non-existent computer virus that has been distributed in various ways." [3] In the end, I never got a copy of McAfee antivirus.

 

One last thing, I checked the domain Whois information to see when this domain was registered or updated, this can often offer some clues if it is used for malicious purposes. Interesting enough, this domain was updated today. [4][5] Here is summary of the current listing:

 

Domain Name: collectyoursordersnow.com
Registry Domain ID: 2699308613_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namesilo.com
Registrar URL: https://www.namesilo.com/
Updated Date: 2022-11-19T07:00:00Z
Creation Date: 2022-05-26T07:00:00Z
Registrar Registration Expiration Date: 2023-05-26T07:00:00Z
Registrar: NameSilo, LLC

Indicators

https://tuk-vi.collectyoursordersnow[.]com/ga/click/2-76430879-6226-10575-20591-16810-fe164f969b-e290af9b7f

[1] https://isc.sans.edu/diary/McAfee+Phishing+Campaign+with+a+Nice+Fake+Scan/28208
[2] https://www.virustotal.com/gui/url-analysis/u-d83f4cf7d6320d92e653e825e582cfbfc207949bada3e3913128eb6b56377ad3-1668896404
[3] https://en.wikipedia.org/wiki/Tapsnake
[4] https://whois.domaintools.com/collectyoursordersnow.com
[5] https://otx.alienvault.com/indicator/domain/collectyoursordersnow.com

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AA22-321A: #StopRansomware: Hive Ransomware

This post was originally published on this site

Original release date: November 17, 2022

Summary

Actions to Take Today to Mitigate Cyber Threats from Ransomware:

• Prioritize remediating known exploited vulnerabilities.
• Enable and enforce multifactor authentication with strong passwords
• Close unused ports and remove any application not deemed necessary for day-to-day operations.

Note: This joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail various ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Department of Health and Human Services (HHS) are releasing this joint CSA to disseminate known Hive IOCs and TTPs identified through FBI investigations as recently as November 2022.

FBI, CISA, and HHS encourage organizations to implement the recommendations in the Mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents. Victims of ransomware operations should report the incident to their local FBI field office or CISA.

Download the PDF version of this report: pdf, 852.9 kb.

Technical Details

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See MITRE ATT&CK for Enterprise for all referenced tactics and techniques.

As of November 2022, Hive ransomware actors have victimized over 1,300 companies worldwide, receiving approximately US$100 million in ransom payments, according to FBI information. Hive ransomware follows the ransomware-as-a-service (RaaS) model in which developers create, maintain, and update the malware, and affiliates conduct the ransomware attacks. From June 2021 through at least November 2022, threat actors have used Hive ransomware to target a wide range of businesses and critical infrastructure sectors, including Government Facilities, Communications, Critical Manufacturing, Information Technology, and especially Healthcare and Public Health (HPH).

The method of initial intrusion will depend on which affiliate targets the network. Hive actors have gained initial access to victim networks by using single factor logins via Remote Desktop Protocol (RDP), virtual private networks (VPNs), and other remote network connection protocols [T1133]. In some cases, Hive actors have bypassed multifactor authentication (MFA) and gained access to FortiOS servers by exploiting Common Vulnerabilities and Exposures (CVE) CVE-2020-12812. This vulnerability enables a malicious cyber actor to log in without a prompt for the user’s second authentication factor (FortiToken) when the actor changes the case of the username.

Hive actors have also gained initial access to victim networks by distributing phishing emails with malicious attachments [T1566.001] and by exploiting the following vulnerabilities against Microsoft Exchange servers [T1190]:

  • CVE-2021-31207 – Microsoft Exchange Server Security Feature Bypass Vulnerability
  • CVE-2021-34473 – Microsoft Exchange Server Remote Code Execution Vulnerability
  • CVE-2021-34523 – Microsoft Exchange Server Privilege Escalation Vulnerability

After gaining access, Hive ransomware attempts to evade detention by executing processes to:

  • Identify processes related to backups, antivirus/anti-spyware, and file copying and then terminating those processes to facilitate file encryption [T1562].
  • Stop the volume shadow copy services and remove all existing shadow copies via vssadmin on command line or via PowerShell [T1059] [T1490].
  • Delete Windows event logs, specifically the System, Security and Application logs [T1070].

Prior to encryption, Hive ransomware removes virus definitions and disables all portions of Windows Defender and other common antivirus programs in the system registry [T1112].

Hive actors exfiltrate data likely using a combination of Rclone and the cloud storage service Mega.nz [T1537]. In addition to its capabilities against the Microsoft Windows operating system, Hive ransomware has known variants for Linux, VMware ESXi, and FreeBSD.

During the encryption process, a file named *.key (previously *.key.*) is created in the root directory (C: or /root/). Required for decryption, this key file only exists on the machine where it was created and cannot be reproduced. The ransom note, HOW_TO_DECRYPT.txt is dropped into each affected directory and states the *.key file cannot be modified, renamed, or deleted, otherwise the encrypted files cannot be recovered [T1486]. The ransom note contains a “sales department” .onion link accessible through a TOR browser, enabling victim organizations to contact the actors through a live chat panel to discuss payment for their files. However, some victims reported receiving phone calls or emails from Hive actors directly to discuss payment.

The ransom note also threatens victims that a public disclosure or leak site accessible on the TOR site, “HiveLeaks”, contains data exfiltrated from victim organizations who do not pay the ransom demand (see figure 1 below). Additionally, Hive actors have used anonymous file sharing sites to disclose exfiltrated data (see table 1 below).

 

Table 1: Anonymous File Sharing Sites Used to Disclose Data

https://anonfiles[.]com

https://mega[.]nz

https://send.exploit[.]in

https://ufile[.]io

https://www.sendspace[.]com

https://privatlab[.]net

https://privatlab[.]com

 

Once the victim organization contacts Hive actors on the live chat panel, Hive actors communicate the ransom amount and the payment deadline. Hive actors negotiate ransom demands in U.S. dollars, with initial amounts ranging from several thousand to millions of dollars. Hive actors demand payment in Bitcoin.

Hive actors have been known to reinfect—with either Hive ransomware or another ransomware variant—the networks of victim organizations who have restored their network without making a ransom payment.

Indicators of Compromise

Threat actors have leveraged the following IOCs during Hive ransomware compromises. Note: Some of these indicators are legitimate applications that Hive threat actors used to aid in further malicious exploitation. FBI, CISA, and HHS recommend removing any application not deemed necessary for day-to-day operations. See tables 2–3 below for IOCs obtained from FBI threat response investigations as recently as November 2022.

Table 2: Known IOCs as of November 2022

Known IOCs – Files

HOW_TO_DECRYPT.txt typically in directories with encrypted files

*.key typically in the root directory, i.e., C: or /root

hive.bat

shadow.bat

asq.r77vh0[.]pw – Server hosted malicious HTA file

asq.d6shiiwz[.]pw Server referenced in malicious regsvr32 execution

asq.swhw71un[.]pw Server hosted malicious HTA file

asd.s7610rir[.]pw – Server hosted malicious HTA file

Windows_x64_encrypt.dll

Windows_x64_encrypt.exe

Windows_x32_encrypt.dll

Windows_x32_encrypt.exe

Linux_encrypt

Esxi_encrypt

Known IOCs – Events

System, Security and Application Windows event logs wiped

Microsoft Windows Defender AntiSpyware Protection disabled

Microsoft Windows Defender AntiVirus Protection disabled

Volume shadow copies deleted

Normal boot process prevented

Known IOCs – Logged Processes

wevtutil.exe cl system

wevtutil.exe cl security

wevtutil.exe cl application

vssadmin.exe delete shadows /all /quiet

wmic.exe SHADOWCOPY /nointeractive

wmic.exe shadowcopy delete

bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures

bcdedit.exe /set {default} recoveryenabled no

 

Table 3: Potential IOC IP Addresses as of November 2022 Note: Some of these observed IP addresses are more than a year old. FBI and CISA recommend vetting or investigating these IP addresses prior to taking forward-looking action like blocking.

Potential IOC IP Addresses for Compromise or Exfil:

84.32.188[.]57

84.32.188[.]238

93.115.26[.]251

185.8.105[.]67

181.231.81[.]239

185.8.105[.]112

186.111.136[.]37

192.53.123[.]202

158.69.36[.]149

46.166.161[.]123

108.62.118[.]190

46.166.161[.]93

185.247.71[.]106

46.166.162[.]125

5.61.37[.]207

46.166.162[.]96

185.8.105[.]103

46.166.169[.]34

5.199.162[.]220

93.115.25[.]139

5.199.162[.]229

93.115.27[.]148

89.147.109[.]208

83.97.20[.]81

5.61.37[.]207

5.199.162[.]220

5.199.162[.]229;

46.166.161[.]93

46.166.161[.]123;

46.166.162[.]96

46.166.162[.]125

46.166.169[.]34

83.97.20[.]81

84.32.188[.]238

84.32.188[.]57

89.147.109[.]208

93.115.25[.]139;

93.115.26[.]251

93.115.27[.]148

108.62.118[.]190

158.69.36[.]149/span>

181.231.81[.]239

185.8.105[.]67

185.8.105[.]103

185.8.105[.]112

185.247.71[.]106

186.111.136[.]37

192.53.123[.]202

 

MITRE ATT&CK TECHNIQUES

See table 4 for all referenced threat actor tactics and techniques listed in this advisory.

Table 4: Hive Actors ATT&CK Techniques for Enterprise

Initial Access

Technique Title

ID

Use

External Remote Services

T1133

Hive actors gain access to victim networks by using single factor logins via RDP, VPN, and other remote network connection protocols.

Exploit Public-Facing Application

T1190

Hive actors gain access to victim network by exploiting the following Microsoft Exchange vulnerabilities: CVE-2021-34473, CVE-2021-34523, CVE-2021-31207, CVE-2021-42321.

Phishing

T1566.001

Hive actors gain access to victim networks by distributing phishing emails with malicious attachments.

Execution

Technique Title

ID

Use

Command and Scripting Interpreter

T1059

Hive actors looks to stop the volume shadow copy services and remove all existing shadow copies via vssadmin on command line or PowerShell.

Defense Evasion

Technique Title

ID

Use

Indicator Removal on Host

T1070

Hive actors delete Windows event logs, specifically, the System, Security and Application logs.

Modify Registry

T1112

Hive actors set registry values for DisableAntiSpyware and DisableAntiVirus to 1.

Impair Defenses

T1562

Hive actors seek processes related to backups, antivirus/anti-spyware, and file copying and terminates those processes to facilitate file encryption.

Exfiltration

Technique Title

ID

Use

Transfer Data to Cloud Account

T1537

Hive actors exfiltrate data from victims, using a possible combination of Rclone and the cloud storage service Mega.nz.

Impact

Technique Title

 

Use

Data Encrypted for Impact

T1486

Hive actors deploy a ransom note HOW_TO_DECRYPT.txt into each affected directory which states the *.key file cannot be modified, renamed, or deleted, otherwise the encrypted files cannot be recovered.

Inhibit System Recovery

T1490

Hive actors looks to stop the volume shadow copy services and remove all existing shadow copies via vssadmin via command line or PowerShell.

Mitigations

FBI, CISA, and HHS recommend organizations, particularly in the HPH sector, implement the following to limit potential adversarial use of common system and network discovery techniques and to reduce the risk of compromise by Hive ransomware:

  • Verify Hive actors no longer have access to the network.
  • Install updates for operating systems, software, and firmware as soon as they are released. Prioritize patching VPN servers, remote access software, virtual machine software, and known exploited vulnerabilities. Consider leveraging a centralized patch management system to automate and expedite the process.
  • Require phishing-resistant MFA for as many services as possible—particularly for webmail, VPNs, accounts that access critical systems, and privileged accounts that manage backups.
  • If used, secure and monitor RDP.
    • Limit access to resources over internal networks, especially by restricting RDP and using virtual desktop infrastructure.
    • After assessing risks, if you deem RDP operationally necessary, restrict the originating sources and require MFA to mitigate credential theft and reuse.
    • If RDP must be available externally, use a VPN, virtual desktop infrastructure, or other means to authenticate and secure the connection before allowing RDP to connect to internal devices.
    • Monitor remote access/RDP logs, enforce account lockouts after a specified number of attempts to block brute force campaigns, log RDP login attempts, and disable unused remote access/RDP ports.
    • Be sure to properly configure devices and enable security features.
    • Disable ports and protocols not used for business purposes, such as RDP Port 3389/TCP.
  • Maintain offline backups of data, and regularly maintain backup and restoration. By instituting this practice, the organization ensures they will not be severely interrupted, and/or only have irretrievable data.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure. Ensure your backup data is not already infected.,
  • Monitor cyber threat reporting regarding the publication of compromised VPN login credentials and change passwords/settings if applicable.
  • Install and regularly update anti-virus or anti-malware software on all hosts.
  • Enable PowerShell Logging including module logging, script block logging and transcription.
  • Install an enhanced monitoring tool such as Sysmon from Microsoft for increased logging.
  • Review the following additional resources.
    • The joint advisory from Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity provides additional guidance when hunting or investigating a network and common mistakes to avoid in incident handling.
    • The Cybersecurity and Infrastructure Security Agency-Multi-State Information Sharing & Analysis Center Joint Ransomware Guide covers additional best practices and ways to prevent, protect, and respond to a ransomware attack.
    • StopRansomware.gov is the U.S. Government’s official one-stop location for resources to tackle ransomware more effectively.

If your organization is impacted by a ransomware incident, FBI, CISA, and HHS recommend the following actions.

  • Isolate the infected system. Remove the infected system from all networks, and disable the computer’s wireless, Bluetooth, and any other potential networking capabilities. Ensure all shared and networked drives are disconnected.
  • Turn off other computers and devices. Power-off and segregate (i.e., remove from the network) the infected computer(s). Power-off and segregate any other computers or devices that share a network with the infected computer(s) that have not been fully encrypted by ransomware. If possible, collect and secure all infected and potentially infected computers and devices in a central location, making sure to clearly label any computers that have been encrypted. Powering-off and segregating infected computers and computers that have not been fully encrypted may allow for the recovery of partially encrypted files by specialists.
  • Secure your backups. Ensure that your backup data is offline and secure. If possible, scan your backup data with an antivirus program to check that it is free of malware.

In addition, FBI, CISA, and HHS urge all organizations to apply the following recommendations to prepare for, mitigate/prevent, and respond to ransomware incidents.

Preparing for Cyber Incidents

  • Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity.
  • Implement listing policies for applications and remote access that only allow systems to execute known and permitted programs under an established security policy.
  • Document and monitor external remote connections. Organizations should document approved solutions for remote management and maintenance, and immediately investigate if an unapproved solution is installed on a workstation.
  • Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, the cloud).

Identity and Access Management

  • Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute of Standards and Technology (NIST) standards for developing and managing password policies.
    • Use longer passwords consisting of at least 8 characters and no more than 64 characters in length.
    • Store passwords in hashed format using industry-recognized password managers.
    • Add password user “salts” to shared login credentials.
    • Avoid reusing passwords.
    • Implement multiple failed login attempt account lockouts.
    • Disable password “hints.”
    • Refrain from requiring password changes more frequently than once per year unless a password is known or suspected to be compromised.
      Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
    • Require administrator credentials to install software.
  • Require phishing-resistant multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
  • Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
  • Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege.
  • Implement time-based access for accounts set at the admin level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task. 

Protective Controls and Architecture

  • Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
  • Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.

Vulnerability and Configuration Management

  • Consider adding an email banner to emails received from outside your organization.
  • Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally.
  • Ensure devices are properly configured and that security features are enabled
  • Restrict Server Message Block (SMB) Protocol within the network to only access necessary servers and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.

REFERENCES

INFORMATION REQUESTED

The FBI, CISA, and HHS do not encourage paying a ransom to criminal actors. Paying a ransom may embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. However, the FBI, CISA, and HHS understand that when businesses are faced with an inability to function, executives will evaluate all options to protect their shareholders, employees, and customers. Regardless of whether you or your organization decide to pay the ransom, the FBI, CISA, and HHS urge you to promptly report ransomware incidents to your local FBI field office, or to CISA at report@cisa.gov or (888) 282-0870. Doing so provides investigators with the critical information they need to track ransomware attackers, hold them accountable under US law, and prevent future attacks. 

The FBI may seek the following information that you determine you can legally share, including:

  • Recovered executable files
  • Live random access memory (RAM) capture
  • Images of infected systems
  • Malware samples
  • IP addresses identified as malicious or suspicious
  • Email addresses of the attackers
  • A copy of the ransom note
  • Ransom amount
  • Bitcoin wallets used by the attackers
  • Bitcoin wallets used to pay the ransom
  • Post-incident forensic reports

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. FBI, CISA, and HHS do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by FBI, CISA, or HHS.

 

Revisions

  • Initial Version: November 17, 2022

This product is provided subject to this Notification and this Privacy & Use policy.

Lessons Learned from Automatic Failover: When 8.8.8.8 "disappears". IPv6 to the Rescue?, (Thu, Nov 17th)

This post was originally published on this site

A famous XKCD cartoon talks about the importance of the often taken for granted "8.8.8.8" Google DNS server. Like many, I use it often as a quick connectivity check. 8.8.8.8 is an anycast address that exists many times around the globe. I also started to use it for automatic failover on my OPNSense firewall/router.

I am using two uplinks. My primary connection uses Comcast, and recently I started using T-Mobile's 5G Home service as a backup. Overall, I was pleasantly surprised by the T-Mobile service. It competed well with my Comcast service for download speed. I even configured my router to use the T-Mobile service as "primary" for some movie streaming, as it does not have a data cap.

To detect if one of the connections is "down," I am using 75.75.75.75 for the Comcast connection (Comcast's default DNS server) and 8.8.8.8 for T-Mobile. Well… until one day, I had odd issues with the T-Mobile connection. OPNSense had marked it as "down," but the connection appeared to work fine for streaming and other data (also, DNS to 8.8.8.8 didn't work). Just "ping" had high packet loss and the couple of packets that made it had very high latencies:

% ping -c 100 8.8.8.8
...
--- 8.8.8.8 ping statistics ---
100 packets transmitted, 19 packets received, 81.0% packet loss
round-trip min/avg/max/stddev = 114.412/181.239/302.607/40.971 ms

Luckily, Google also runs DoH endpoints on its public DNS servers, so we can verify the results using hping3 and TCP SYN Packets:

% sudo hping -S -p 443 8.8.8.8 -c 100
HPING 8.8.8.8 (en5 8.8.8.8): S set, 40 headers + 0 data bytes
len=44 ip=8.8.8.8 ttl=115 DF id=36841 sport=443 flags=SA seq=0 win=65535 rtt=52.8 ms
len=44 ip=8.8.8.8 ttl=114 DF id=37609 sport=443 flags=SA seq=1 win=65535 rtt=50.9 ms
...
--- 8.8.8.8 hping statistic ---
100 packets transmitted, 100 packets received, 0% packet loss
round-trip min/avg/max = 32.2/64.6/96.4 ms

No packet loss! Reasonably latency! And a "speedtest.com" test showed download speeds of around 200 MBit/sec.

I did some more tests pinging a colocated server and got similar results. The colocated server allowed me to test various other packets:

  • Empty ICMP packets (no ICMP header, no payload)
  • ICMP error packets
  • various random ICMP traffic (fragments, misc type and code combinations, different payload sizes)

None of the packets appear to make it. This is, in particular, an issue if ICMP errors are blocked. Like most LTE/5G ISPs, T-Mobile also does carrier-grade NAT, which adds additional "wrinkles" to their network. I could theoretically use IPv6 over T-Mobile, but the modem they provide only offers a /64 and no "Bridge" mode, so you cannot use IPv6 if you are using your own router with IPv6.

Connecting a system directly to the T-Mobile modem via Wi-Fi shows that ICMPv6 is not blocked:

% ping6 2001:4860:4860::8888 -c 100
PING6(56=40+8+8 bytes) 2607:fb90:be84:750f:285b:6b41:63c6:dc46 --> 2001:4860:4860::8888
16 bytes from 2001:4860:4860::8888, icmp_seq=0 hlim=114 time=101.936 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=1 hlim=114 time=57.622 ms
16 bytes from 2001:4860:4860::8888, icmp_seq=2 hlim=114 time=55.386 ms
...
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 33.788/67.714/153.129/22.813 ms

For connection status detection, ICMPv6 will do for now, but there is no way to route T-Mobile IPv6 into my network, and IPv6 failover for a setup like this doesn't exist :(.

 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Evil Maid Attacks – Remediation for the Cheap, (Wed, Nov 16th)

This post was originally published on this site

[This is a guest diary submitted by Gebhard. For feedback, you can connect with Gebhard via our DShield slack]

Preliminary note

In this diary, we are assuming PC-like devices with state-of-the-art disk encryption (full disk encryption, FDE) and a "normal" desktop OS (Linux, Windows, …).

What is the evil maid attack?

The so-called evil maid attack is an attack against hardware devices utilizing hard- and/or software. It is carried out when the hardware is left unattended, e.g., in a hotel room when you're out for breakfast. The attacker manipulates the device in a malicious way, e.g.:

  • if the device is running: cool down and take out RAM to copy it (e.g., to find sensitive information)
  • manipulate the mainboard / BIOS (e.g., to add a backdoor)
  • manipulate the content from the unencrypted bootloader (e.g., to add a backdoor)

The last attack may even work with secure boot enabled because of 0-day vulnerabilities in the signed boot code or known vulnerabilities in the signed boot code, which is not disabled due to outdated revocation lists in the BIOS.

Your possible options

There are several ways to minimize the risk of an unnoticed, successful evil maid attack. Which road you go depends on your personal threat model (and your budget, of course).

  1. Take the risk

    If evil maid attacks do not matter in your situation, e.g., because you're using a disposable device that is already assumed to be compromised, then you can simply take the risk.

  2. Adequate hardware

    You can buy (or prepare yourself) special hardened devices (e.g. NitroPad) which make evil maid attacks nearly impossible to go undetected:

    • sealed screws
    • alternate BIOS/firmware (Coreboot (https://www.coreboot.org/) and Heads (https://osresearch.net/FAQ/))
    • deactivated Intel Management Engine
    • hardware key for checking signatures/integrity of boot files with your personal PGP key
    • full disk encryption

    These devices make the boot process more trustworthy than using stock consumer hardware:

    • Solely open-source BIOS and firmware code
    • boot code signed with your personal PGP key stored on a USB hardware device and only attached temporarily to the system to carry out the signature checks
    • full disc encryption
    • optional (but cool ? ): Qubes OS
  3. Leave your device up and running

    If you leave your device running the OS on the one hand, you would probably notice if the device got turned out or rebooted: you may e.g., just have an editor open with some individual unsaved text and the screen locked. But on the other hand with a running OS you have a very broad attack surface because all device functionality is active (e.g., peripheral interfaces). So an attacker may e.g. add a USB LAN card and mess with the system trying to connect to the LAN controlled by the attacker. Or the three-letter agency can apply the publicly unknown exploit for the next 0-Day of the OS or a driver.

  4. Remediation for the cheap

    If you want to have a cheap solution to be reasonably sure nobody messes unnoticed with your device when you have to leave it alone, you may carry out some countermeasures, e.g.:

    • seal all screws with nail polish or glue with glitter pieces in it, and take pictures that are stored offline so that you will be able to spot manipulations
    • seal not needed peripheral interfaces (e.g. USB ports)
    • lock needed peripheral ports with tamper-proof solutions (e.g. one-time locks which have to be destroyed to access the port)
    • Leave the device in the bootup password prompt of the FDE:
      1. (re-) boot your device to the FDE password prompt
      2. and enter the first few chars of the correct password (important!)
      3. make sure the device stays in this mode till you return (e.g. has enough power or the power supply is plugged in, disable energy saving settings, …)

    When you're back, enter the rest of the FDE password, and if the device boots, then you could be reasonably sure it hasn't been tampered with. Of course, you have to examine the device physically thoroughly, e.g., the screws, peripheral ports, seals, etc. One important precondition for this to work is that the FDE boot code allows the password prompt to stay as it is after entering some chars. Fedora 7 and Ubuntu 20.04 seem to work, but Bitlocker (Windows) does not. Is this bulletproof? No. Will this be reasonably secure? Depends on your threat model. But it's definitely better than doing nothing, having the OS left up and running, or having the device powered off completely. Stay safe and secure!

Feel free to send in your own tips and hints.

 

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

AA22-320A: Iranian Government-Sponsored APT Actors Compromise Federal Network, Deploy Crypto Miner, Credential Harvester

This post was originally published on this site

Original release date: November 16, 2022

Summary

From mid-June through mid-July 2022, CISA conducted an incident response engagement at a Federal Civilian Executive Branch (FCEB) organization where CISA observed suspected advanced persistent threat (APT) activity. In the course of incident response activities, CISA determined that cyber threat actors exploited the Log4Shell vulnerability in an unpatched VMware Horizon server, installed XMRig crypto mining software, moved laterally to the domain controller (DC), compromised credentials, and then implanted Ngrok reverse proxies on several hosts to maintain persistence. CISA and the Federal Bureau of Investigation (FBI) assess that the FCEB network was compromised by Iranian government-sponsored APT actors.

CISA and FBI are releasing this Cybersecurity Advisory (CSA) providing the suspected Iranian government-sponsored actors’ tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help network defenders detect and protect against related compromises.

CISA and FBI encourage all organizations with affected VMware systems that did not immediately apply available patches or workarounds to assume compromise and initiate threat hunting activities. If suspected initial access or compromise is detected based on IOCs or TTPs described in this CSA, CISA and FBI encourage organizations to assume lateral movement by threat actors, investigate connected systems (including the DC), and audit privileged accounts. All organizations, regardless of identified evidence of compromise, should apply the recommendations in the Mitigations section of this CSA to protect against similar malicious cyber activity.

For more information on Iranian government-sponsored Iranian malicious cyber activity, see CISA’s Iran Cyber Threat Overview and Advisories webpage and FBI’s Iran Threats webpage.

Download the PDF version of this report: pdf, 528 kb.

For a downloadable copy of the Malware Analysis Report (MAR) accompanying this report, see: MAR 10387061-1.v1.

Technical Details

Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 11. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques with corresponding mitigation and/or detection recommendations.

Overview

In April 2022, CISA conducted retrospective analysis using EINSTEIN—an FCEB-wide intrusion detection system (IDS) operated and monitored by CISA—and identified suspected APT activity on an FCEB organization’s network. CISA observed bi-directional traffic between the network and a known malicious IP address associated with exploitation of the Log4Shell vulnerability (CVE-2021-44228) in VMware Horizon servers. In coordination with the FCEB organization, CISA initiated threat hunting incident response activities; however, prior to deploying an incident response team, CISA observed additional suspected APT activity. Specifically, CISA observed HTTPS activity from IP address 51.89.181[.]64 to the organization’s VMware server. Based on trusted third-party reporting, 51.89.181[.]64 is a Lightweight Directory Access Protocol (LDAP) server associated with threat actors exploiting Log4Shell. Following HTTPS activity, CISA observed a suspected LDAP callback on port 443 to this IP address. CISA also observed a DNS query for us‐nation‐ny[.]cf that resolved back to 51.89.181[.]64 when the victim server was returning this Log4Shell LDAP callback to the actors’ server.

CISA assessed that this traffic indicated a confirmed compromise based on the successful callback to the indicator and informed the organization of these findings; the organization investigated the activity and found signs of compromise. As trusted-third party reporting associated Log4Shell activity from 51.89.181[.]64 with lateral movement and targeting of DCs, CISA suspected the threat actors had moved laterally and compromised the organization’s DC.

From mid-June through mid-July 2022, CISA conducted an onsite incident response engagement and determined that the organization was compromised as early as February 2022, by likely Iranian government-sponsored APT actors who installed XMRig crypto mining software. The threat actors also moved laterally to the domain controller, compromised credentials, and implanted Ngrok reverse proxies.

Threat Actor Activity

In February 2022, the threat actors exploited Log4Shell [T1190] for initial access [TA0001] to the organization’s unpatched VMware Horizon server. As part of their initial exploitation, CISA observed a connection to known malicious IP address 182.54.217[.]2 lasting 17.6 seconds.

The actors’ exploit payload ran the following PowerShell command [T1059.001] that added an exclusion tool to Windows Defender [T1562.001]:

powershell try{Add-MpPreference -ExclusionPath ‘C:’; Write-Host ‘added-exclusion’} catch {Write-Host ‘adding-exclusion-failed’ }; powershell -enc “$BASE64 encoded payload to download next stage and execute it”

The exclusion tool allowlisted the entire c:drive, enabling threat actors to download tools to the c:drive without virus scans. The exploit payload then downloaded mdeploy.text from 182.54.217[.]2/mdepoy.txt to C:userspublicmde.ps1 [T1105]. When executed, mde.ps1 downloaded file.zip from 182.54.217[.]2 and removed mde.ps1 from the disk [T1070.004].

file.zip contained XMRig cryptocurrency mining software and associated configuration files.

  • WinRing0x64.sys – XMRig Miner driver
  • wuacltservice.exe – XMRig Miner
  • config.json – XMRig miner configuration
  • RuntimeBroker.exe – Associated file. This file can create a local user account [T1136.001] and tests for internet connectivity by pinging 8.8.8.8 [T1016.001]. The exploit payload created a Scheduled Task [T1053.005] that executed RuntimeBroker.exe daily as SYSTEM. Note: By exploiting Log4Shell, the actors gained access to a VMware service account with administrator and system level access. The Scheduled Task was named RuntimeBrokerService.exe to masquerade as a legitimate Windows task.

See MAR 10387061-1.v1 for additional information, including IOCs, on these four files.

After obtaining initial access and installing XMRig on the VMWare Horizon server, the actors used RDP [T1021.001] and the built-in Windows user account DefaultAccount [T1078.001] to move laterally [TA0008] to a VMware VDI-KMS host. Once the threat actor established themselves on the VDI-KMS host, CISA observed the actors download around 30 megabytes of files from transfer[.]sh server associated with 144.76.136[.]153. The actors downloaded the following tools:

  • PsExec – a Microsoft signed tool for system administrators.
  • Mimikatz – a credential theft tool.
  • Ngrok – a reverse proxy tool for proxying an internal service out onto an Ngrok domain, which the user can then access at a randomly generated subdomain at *.ngrok[.]io. CISA has observed this tool in use by some commercial products for benign purposes; however, this process bypasses typical firewall controls and may be a potentially unwanted application in production environments. Ngrok is known to be used for malicious purposes.[1]

The threat actors then executed Mimikatz on VDI-KMS to harvest credentials and created a rogue domain administrator account [T1136.002]. Using the newly created account, the actors leveraged RDP to propagate to several hosts within the network. Upon logging into each host, the actors manually disabled Windows Defender via the Graphical User Interface (GUI) and implanted Ngrok executables and configuration files. The threat actors were able to implant Ngrok on multiple hosts to ensure Ngrok’s persistence should they lose access to a machine during a routine reboot. The actors were able to proxy [T1090] RDP sessions, which were only observable on the local network as outgoing HTTPS port 443 connections to tunnel.us.ngrok[.]com and korgn.su.lennut[.]com (the prior domain in reverse). It is possible, but was not observed, that the threat actors configured a custom domain, or used other Ngrok tunnel domains, wildcarded here as *.ngrok[.]com, *.ngrok[.]io, ngrok.*.tunnel[.]com, or korgn.*.lennut[.]com.

Once the threat actors established a deep foothold in the network and moved laterally to the domain controller, they executed the following PowerShell command on the Active Directory to obtain a list of all machines attached to the domain [T1018]:

Powershell.exe get-adcomputer -filter * -properties * | select name,operatingsystem,ipv4address >

The threat actors also changed the password for the local administrator account [T1098] on several hosts as a backup should the rogue domain administrator account get detected and terminated. Additionally, the threat actor was observed attempting to dump the Local Security Authority Subsystem Service (LSASS) process [T1003.001] with task manager but this was stopped by additional anti-virus the FCEB organization had installed.

MITRE ATT&CK TACTICS AND TECHNIQUES

See table 1 for all referenced threat actor tactics and techniques in this advisory, as well as corresponding detection and/or mitigation recommendations. For additional mitigations, see the Mitigations section.

Table 1: Cyber Threat Actors ATT&CK Techniques for Enterprise

Initial Access

Technique Title

ID

Use

Recommendations

Exploit Public-Facing Application

T1190

The actors exploited Log4Shell for initial access to the organization’s VMware Horizon server.

Mitigation/Detection: Use a firewall or web-application firewall and enable logging to prevent and detect potential Log4Shell exploitation attempts [M1050].

Mitigation: Perform regular vulnerability scanning to detect Log4J vulnerabilities and update Log4J software using vendor provided patches [M1016],[M1051].

Execution

Technique Title

ID

Use

Recommendation

Command and Scripting Interpreter: PowerShell

T1059.001

The actors ran PowerShell commands that added an exclusion tool to Windows Defender.

The actors executed PowerShell on the AD to obtain a list of machines on the domain.

Mitigation: Disable or remove PowerShell for non-administrative users [M1042],[M1026] or enable code-signing to execute only signed scripts [M1045].

Mitigation: Employ anti-malware to automatically detect and quarantine malicious scripts [M1049].

Persistence

Technique Title

ID

Use

Recommendations

Account Manipulation

T1098

The actors changed the password for the local administrator account on several hosts.

Mitigation: Use multifactor authentication for user and privileged accounts [M1032].

Detection: Monitor events for changes to account objects and/or permissions on systems and the domain, such as event IDs 4738, 4728, and 4670. Monitor for modification of accounts in correlation with other suspicious activity [DS0002].

Create Account: Local Account

T1136.001

The actors’ malware can create local user accounts.

Mitigation: Configure access controls and firewalls to limit access to domain controllers and systems used to create and manage accounts.

Detection: Monitor executed commands and arguments for actions that are associated with local account creation, such as net user /add , useradd, and dscl -create [DS0017].

Detection: Enable logging for new user creation [DS0002].

Create Account: Domain Account

T1136.002

The actors used Mimikatz to create a rogue domain administrator account.

Mitigation: Configure access controls and firewalls to limit access to domain controllers and systems used to create and manage accounts.

Detection: Enable logging for new user creation, especially domain administrator accounts [DS0002].

Scheduled Task/Job: Scheduled Task

T1053.005

The actors’ exploit payload created Scheduled Task RuntimeBrokerService.exe, which executed RuntimeBroker.exe daily as SYSTEM.

Mitigation: Configure settings for scheduled tasks to force tasks to run under the context of the authenticated account instead of allowing them to run as SYSTEM [M1028].

Detection: Monitor for newly constructed processes and/or command-lines that execute from the svchost.exe in Windows 10 and the Windows Task Scheduler taskeng.exe for older versions of Windows [DS0009]

Detection: Monitor for newly constructed scheduled jobs by enabling the Microsoft-Windows-TaskScheduler/Operational setting within the event logging service [DS0003].

Valid Accounts: Default Accounts

T1078.001

The actors used built-in Windows user account DefaultAccount.

Mitigation: Change default usernames and passwords immediately after the installation and before deployment to a production environment [M1027].

Detection: Develop rules to monitor logon behavior across default accounts that have been activated or logged into [DS0028].

Defense Evasion

Technique Title

ID

Use

Recommendations

Impair Defenses: Disable or Modify Tools

           

T1562.001

The actors added an exclusion tool to Windows Defender. The tool allowlisted the entire c:drive, enabling the actors to bypass virus scans for tools they downloaded to the c:drive.

The actors manually disabled Windows Defender via the GUI.

Mitigation: Ensure proper user permissions are in place to prevent adversaries from disabling or interfering with security services. [M1018].

Detection: Monitor for changes made to Windows Registry keys and/or values related to services and startup programs that correspond to security tools such as HKLM:SOFTWAREPoliciesMicrosoftWindows Defender [DS0024].

Detection: Monitor for telemetry that provides context for modification or deletion of information related to security software processes or services such as Windows Defender definition files in Windows and System log files in Linux [DS0013].

Detection: Monitor processes for unexpected termination related to security tools/services [DS0009].

Indicator Removal on Host: File Deletion

T1070.004

The actors removed malicious file mde.ps1 from the dis.

Detection: Monitor executed commands and arguments for actions that could be utilized to unlink, rename, or delete files [DS0017].

Detection: Monitor for unexpected deletion of files from the system [DS0022].

Credential Access

Technique Title

ID

Use

Recommendations

OS Credential Dumping: LSASS Memory

T1003.001

The actors were observed trying to dump LSASS process.

Mitigation: With Windows 10, Microsoft implemented new protections called Credential Guard to protect the LSA secrets that can be used to obtain credentials through forms of credential dumping [M1043]

Mitigation: On Windows 10, enable Attack Surface Reduction (ASR) rules to secure LSASS and prevent credential stealing [M1040].

Mitigation: Ensure that local administrator accounts have complex, unique passwords across all systems on the network [M1027].

Detection: Monitor for unexpected processes interacting with LSASS.exe. Common credential dumpers such as Mimikatz access LSASS.exe by opening the process, locating the LSA secrets key, and decrypting the sections in memory where credential details are stored. [DS0009].

Detection: Monitor executed commands and arguments that may attempt to access credential material stored in the process memory of the LSASS [DS0017].

Credentials from Password Stores

T1555

The actors used Mimikatz to harvest credentials.

Mitigation: Organizations may consider weighing the risk of storing credentials in password stores and web browsers. If system, software, or web browser credential disclosure is a significant concern, technical controls, policy, and user training may be used to prevent storage of credentials in improper locations [M1027].

Detection: Monitor for processes being accessed that may search for common password storage locations to obtain user credentials [DS0009].

Detection: Monitor executed commands and arguments that may search for common password storage locations to obtain user credentials [DS0017].

Discovery

Technique Title

ID

Use

Recommendations

Remote System Discovery

T1018

The actors executed a PowerShell command on the AD to obtain a list of all machines attached to the domain.

Detection: Monitor executed commands and arguments that may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for lateral movement [DS0017].

Detection: Monitor for newly constructed network connections associated with pings/scans that may attempt to get a listing of other systems by IP address, hostname, or other logical identifier on a network that may be used for lateral movement [DS0029].

Detection: Monitor for newly executed processes that can be used to discover remote systems, such as ping.exe and tracert.exe, especially when executed in quick succession [DS0009].

System Network Configuration Discovery: Internet Connection Discovery

T1016.001

The actors’ malware tests for internet connectivity by pinging 8.8.8.8.

Mitigation: Monitor executed commands, arguments [DS0017] and executed processes (e.g., tracert or ping) [DS0009] that may check for internet connectivity on compromised systems.

Lateral Movement

Technique Title

ID

Use

Recommendations

Remote Services: Remote Desktop Protocol

T1021.001

The actors used RDP to move laterally to multiple hosts on the network.

Mitigation: Use MFA for remote logins [M1032].

Mitigation: Disable the RDP service if it is unnecessary [M1042].

Mitigation: Do not leave RDP accessible from the internet. Enable firewall rules to block RDP traffic between network security zones within a network [M1030].

Mitigation: Consider removing the local Administrators group from the list of groups allowed to log in through RDP [M1026].

Detection: Monitor for user accounts logged into systems associated with RDP (ex: Windows EID 4624 Logon Type 10). Other factors, such as access patterns (ex: multiple systems over a relatively short period of time) and activity that occurs after a remote login, may indicate suspicious or malicious behavior with RDP [DS0028].

Command and Control

Technique Title

ID

Use

Recommendations

Proxy

T1090

The actors used Ngrok to proxy RDP connections and to perform command and control.

Mitigation: Traffic to known anonymity networks and C2 infrastructure can be blocked through the use of network allow and block lists [M1037].

Detection: Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g., extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure) [DS0029].

Ingress Tool Transfer

T1105

The actors downloaded malware and multiple tools to the network, including PsExec, Mimikatz, and Ngrok.

Mitigation: Employ anti-malware to automatically detect and quarantine malicious scripts [M1049].

 

 

INCIDENT RESPONSE

If suspected initial access or compromise is detected based on IOCs or TTPs in this CSA, CISA encourages organizations to assume lateral movement by threat actors and investigate connected systems and the DC.

CISA recommends organizations apply the following steps before applying any mitigations, including patching.

  1. Immediately isolate affected systems.
  2. Collect and review relevant logs, data, and artifacts. Take a memory capture of the device(s) and a forensic image capture for detailed analysis.
  3. Consider soliciting support from a third-party incident response organization that can provide subject matter expertise to ensure the actor is eradicated from the network and to avoid residual issues that could enable follow-on exploitation.
  4. Report incidents to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870) or your local FBI field office, or FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov.
     

Mitigations

CISA and FBI recommend implementing the mitigations below and in Table 1 to improve your organization’s cybersecurity posture on the basis of threat actor behaviors.

  • Install updated builds to ensure affected VMware Horizon and UAG systems are updated to the latest version.
    • If updates or workarounds were not promptly applied following VMware’s release of updates for Log4Shell in December 2021, treat those VMware Horizon systems as compromised. Follow the pro-active incident response procedures outlined above prior to applying updates. If no compromise is detected, apply these updates as soon as possible.
      • See VMware Security Advisory VMSA-2021-0028.13 and VMware Knowledge Base (KB) 87073 to determine which VMware Horizon components are vulnerable.
      • Note: Until the update is fully implemented, consider removing vulnerable components from the internet to limit the scope of traffic. While installing the updates, ensure network perimeter access controls are as restrictive as possible.
      • If upgrading is not immediately feasible, see KB87073 and KB87092 for vendor-provided temporary workarounds. Implement temporary solutions using an account with administrative privileges. Note that these temporary solutions should not be treated as permanent fixes; vulnerable components should be upgraded to the latest build as soon as possible.
      • Prior to implementing any temporary solution, ensure appropriate backups have been completed.
      • Verify successful implementation of mitigations by executing the vendor supplied script Horizon_Windows_Log4j_Mitigations.zip without parameters to ensure that no vulnerabilities remain. See KB87073 for details.
  • Keep all software up to date and prioritize patching known exploited vulnerabilities (KEVs).
  • Minimize the internet-facing attack surface by hosting essential services on a segregated DMZ, ensuring strict network perimeter access controls, and not hosting internet-facing services that are not essential to business operations. Where possible, implement regularly updated web application firewalls (WAF) in front of public-facing services. WAFs can protect against web-based exploitation using signatures and heuristics that are likely to block or alert on malicious traffic.
  • Use best practices for identity and access management (IAM) by implementing phishing resistant multifactor authentication (MFA), enforcing use of strong passwords, regularly auditing administrator accounts and permissions, and limiting user access through the principle of least privilege. Disable inactive accounts uniformly across the AD, MFA systems, etc.
    • If using Windows 10 version 1607 or Windows Server 2016 or later, monitor or disable Windows DefaultAccount, also known as the Default System Managed Account (DSMA).
  • Audit domain controllers to log successful Kerberos Ticket Granting Service (TGS) requests and ensure the events are monitored for anomalous activity.  
    • Secure accounts.
    • Enforce the principle of least privilege. Administrator accounts should have the minimum permission necessary to complete their tasks.
    • Ensure there are unique and distinct administrative accounts for each set of administrative tasks.
    • Create non-privileged accounts for privileged users and ensure they use the non-privileged accounts for all non-privileged access (e.g., web browsing, email access).
  • Create a deny list of known compromised credentials and prevent users from using known-compromised passwords.
  • Secure credentials by restricting where accounts and credentials can be used and by using local device credential protection features. 
    • Use virtualizing solutions on modern hardware and software to ensure credentials are securely stored.
    • Ensure storage of clear text passwords in LSASS memory is disabled. Note: For Windows 8, this is enabled by default. For more information see Microsoft Security Advisory Update to Improve Credentials Protection and Management.
    • Consider disabling or limiting NTLM and WDigest Authentication.
    • Implement Credential Guard for Windows 10 and Server 2016 (refer to Microsoft: Manage Windows Defender Credential Guard for more information). For Windows Server 2012R2, enable Protected Process Light for Local Security Authority (LSA).
    • Minimize the AD attack surface to reduce malicious ticket-granting activity. Malicious activity such as “Kerberoasting” takes advantage of Kerberos’ TGS and can be used to obtain hashed credentials that threat actors attempt to crack.
       

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, CISA and FBI recommend exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA and FBI recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

  1. Select an ATT&CK technique described in this advisory (see table 1).
  2. Align your security technologies against the technique.
  3. Test your technologies against the technique.
  4. Analyze your detection and prevention technologies performance.
  5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
  6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

CISA and FBI recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

References

Revisions

  • Initial Version: November 16, 2022

This product is provided subject to this Notification and this Privacy & Use policy.