Skyline Advisor Pro Proactive Findings – June Edition

This post was originally published on this site

Tweet VMware Skyline Advisor Pro releases new Proactive Findings every month. Findings are prioritized by trending issues in VMware Support, issues raised through post escalation review, security vulnerabilities, and issues raised from VMware engineering, and customers. For the month of June, we released 41 new Findings. Of these, there are 37 Findings based on trending … Continued

The post Skyline Advisor Pro Proactive Findings – June Edition appeared first on VMware Support Insider.

AA22-181A: #StopRansomware: MedusaLocker

This post was originally published on this site

Original release date: June 30, 2022


Actions to take today to mitigate cyber threats from ransomware:
• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce multifactor authentication.

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 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), the Department of the Treasury, and the Financial Crimes Enforcement Network (FinCEN) are releasing this CSA to provide information on MedusaLocker ransomware. Observed as recently as May 2022, MedusaLocker actors predominantly rely on vulnerabilities in Remote Desktop Protocol (RDP) to access victims’ networks. The MedusaLocker actors encrypt the victim’s data and leave a ransom note with communication instructions in every folder containing an encrypted file. The note directs victims to provide ransomware payments to a specific Bitcoin wallet address. MedusaLocker appears to operate as a Ransomware-as-a-Service (RaaS) model based on the observed split of ransom payments. Typical RaaS models involve the ransomware developer and various affiliates that deploy the ransomware on victim systems. MedusaLocker ransomware payments appear to be consistently split between the affiliate, who receives 55 to 60 percent of the ransom; and the developer, who receives the remainder. 

Download the PDF version of this report: pdf, 633 kb

Technical Details

MedusaLocker ransomware actors most often gain access to victim devices through vulnerable Remote Desktop Protocol (RDP) configurations [T1133]. Actors also frequently use email phishing and spam email campaigns—directly attaching the ransomware to the email—as initial intrusion vectors [T1566].

MedusaLocker ransomware uses a batch file to execute PowerShell script invoke-ReflectivePEInjection [T1059.001]. This script propagates MedusaLocker throughout the network by editing the EnableLinkedConnections value within the infected machine’s registry, which then allows the infected machine to detect attached hosts and networks via Internet Control Message Protocol (ICMP) and to detect shared storage via Server Message Block (SMB) Protocol. 

MedusaLocker then: 

  • Restarts the LanmanWorkstation service, which allows registry edits to take effect. 
  • Kills the processes of well-known security, accounting, and forensic software. 
  • Restarts the machine in safe mode to avoid detection by security software [T1562.009].
  • Encrypts victim files with the AES-256 encryption algorithm; the resulting key is then encrypted with an RSA-2048 public key [T1486]. 
  • Runs every 60 seconds, encrypting all files except those critical to the functionality of the victim’s machine and those that have the designated encrypted file extension. 
  • Establishes persistence by copying an executable (svhost.exe or svhostt.exe) to the %APPDATA%Roaming directory and scheduling a task to run the ransomware every 15 minutes. 
  • Attempts to prevent standard recovery techniques by deleting local backups, disabling startup recovery options, and deleting shadow copies [T1490].

MedusaLocker actors place a ransom note into every folder containing a file with the victim’s encrypted data. The note outlines how to communicate with the MedusaLocker actors, typically providing victims one or more email address at which the actors can be reached. The size of MedusaLocker ransom demands appears to vary depending on the victim’s financial status as perceived by the actors. 

Indicators of Compromise

Encrypted File Extensions
.1btc .matlock20 .marlock02 .readinstructions
.bec .mylock .marlock11
.cn .NET1 .key1 .fileslocked
.datalock .NZ .lock .lockfilesUS
.deadfilesgr .tyco .lockdata7 .rs
.faratak .uslockhh .lockfiles .tyco
.fileslock .zoomzoom .perfection .uslockhh
.marlock13 n.exe .Readinstruction .marlock08
.marlock25 nt_lock20 .READINSTRUCTION  
.marlock6 .marlock01 .ReadInstructions  


Ransom Note File Names
how_to_ recover_data.html  how_to_recover_data.html.marlock01
instructions.html  READINSTRUCTION.html 
!!!HOW_TO_DECRYPT!!! How_to_recovery.txt
readinstructions.html  readme_to_recover_files
recovery_instructions.html  HOW_TO_RECOVER_DATA.html


Payment Wallets


Email Addresses
willyhill1960@tutanota[.]com  unlockfile@cock[.]li
zlo@keem[.]ne  unlockmeplease@airmail[.]cc 
zlo@keemail[.]me  unlockmeplease@protonmail[.]com 
zlo@tfwno[.]gf  willyhill1960@protonmail[.]com 
support@ypsotecs[.]com support@imfoodst[.]com 


Email Addresses
traceytevin@protonmail[.]com  support@itwgset[.]com
unlock_file@aol[.]com  support@novibmaker[.]com
unlock_file@outlook[.]com  support@securycasts[.]com 
support@exoprints[.]com rewmiller-1974@protonmail[.]com
support@exorints[.]com  rpd@keemail[.]me
support@fanbridges[.]com  soterissylla@wyseil[.]com 
support@faneridges[.]com support@careersill[.]com 
perfection@bestkoronavirus[.]com  karloskolorado@tutanota[.]com
pool1256@tutanota[.]com  kevynchaz@protonmail[.]com 
rapid@aaathats3as[.]com korona@bestkoronavirus[.]com
rescuer@tutanota[.]com lockPerfection@gmail[.]com
ithelp01@decorous[.]cyou lockperfection@gmail[.]com 
ithelp01@wholeness[.]business mulierfagus@rdhos[.]com
ithelp02@decorous[.]cyou [rescuer]@cock[.]li 
ithelp02@wholness[.]business 107btc@protonmail[.]com 
ithelpresotre@outlook[.]com 33btc@protonmail[.]com 
cmd@jitjat[.]org  777decoder777@protonmail[.]com
coronaviryz@gmail[.]com 777decoder777@tfwno[.]gf
dec_helper@dremno[.]com andrewmiller-1974@protonmail[.]com
dec_helper@excic[.]com  angelomartin-1980@protonmail[.]com
dec_restore@prontonmail[.]com  ballioverus@quocor[.]com
dec_restore1@outlook[.]com beacon@jitjat[.]org
bitcoin@sitesoutheat[.]com  beacon@msgsafe[.]io
briansalgado@protonmail[.]com best666decoder@tutanota[.]com 
bugervongir@outlook[.]com bitcoin@mobtouches[.]com 
best666decoder@protonmail[.]com  encrypt2020@outlook[.]com 
decoder83540@cock[.]li fast-help@inbox[.]lv
decra2019@gmail[.]com  fuc_ktheworld1448@outlook[.]com
diniaminius@winrof[.]com  fucktheworld1448@cock[.]li
dirhelp@keemail[.]me  gartaganisstuffback@gmail[.]com 


Email Addresses[.]ma gavingonzalez@protonmail[.]com
emd@jitjat[.]org gsupp@onionmail[.]org
encrypt2020@cock[.]li  gsupp@techmail[.]info
best666decoder@protonmail[.]com  helper@atacdi[.]com 
ithelp@decorous[.]cyou helper@buildingwin[.]com 
ithelp@decorous[.]cyoum helprestore@outlook[.]com
ithelp@wholeness[.]business helptorestore@outlook[.]com


TOR Addresses
http://gvlay6u4g53rxdi5. onion/8-MO0Q7O97Hgxvm1YbD7OMnimImZJXEWaG-RbH4TvdwVTGQB3X6VOUOP3lgO6YOJEOW


Disclaimer: Many of these observed IP addresses are several years old and have been historically linked to MedusaLocker ransomware. We recommend these IP addresses be investigated or vetted by organizations prior to taking action, such as blocking.

IP Address Last Observed Nov-2021 Nov-2021 Nov-2021 Nov-2021 Nov-2021 Sep-2021 Sep-2021 Sep-2021 Sep-2021 Sep-2021 Sep-2021 Jul-2021 Apr-2021 Apr-2021 Apr-2021 Jan-2021 Dec-2020 Dec-2020 Oct-2020 Aug-2020 Mar-2020 Mar-2020 Mar-2020 Nov-2019


MITRE ATT&CK Techniques

MedusaLocker actors use the ATT&CK techniques listed in Table 1.

Table 1: MedusaLocker Actors ATT&CK Techniques for Enterprise

Initial Access
Technique Title ID Use
External Remote Services T1133 MedusaLocker actors gained access to victim devices through vulnerable RDP configurations.
Phishing T1566 MedusaLocker actors used phishing and spearphishing to obtain access to victims’ networks.
Technique Title ID Use
Command and Scripting Interpreter: PowerShell


MedusaLocker actors may abuse PowerShell commands and scripts for execution.
Defense Evasion
Technique Title ID Use
Impair Defenses: Safe Mode Boot


MedusaLocker actors may abuse Windows safe mode to disable endpoint defenses. Safe mode starts up the Windows operating system with a limited set of drivers and services.
Technique Title ID Use
Data Encrypted for Impact T1486 MedusaLocker actors encrypt data on target systems or on large numbers of systems in a network to interrupt availability to system and network resources.
Inhibit System Recovery T1490 MedusaLocker actors may deny access to operating systems containing features that can help fix corrupted systems, such as backup catalog, volume shadow copies, and automatic repair.



  • Implement a recovery plan that maintains and retains multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (i.e., hard drive, storage device, or the cloud).
  • Implement network segmentation and maintain offline backups of data to ensure limited interruption to the organization.
  • Regularly back up data and password protect backup copies stored offline. Ensure copies of critical data are not accessible for modification or deletion from the system where the data resides.
  • Install, regularly update, and enable real time detection for antivirus software on all hosts.
  • Install updates for operating systems, software, and firmware as soon as possible.
  • 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. 
  • Disable unused ports.
  • Consider adding an email banner to emails received from outside your organization.
  • Disable hyperlinks in received emails.
  • Enforce multifactor authentication (MFA).
  • Use 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 unless there is evidence of password compromise. Note: NIST guidance suggests favoring longer passwords and no longer require 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.
  • Only use secure networks; avoid using public Wi-Fi networks.
  • Consider installing and using a virtual private network (VPN) to establish secure remote connections.
  • Focus on cybersecurity awareness and training. Regularly provide users with training on information security principles and techniques as well as overall emerging cybersecurity risks and vulnerabilities, such as ransomware and phishing scams.


  • is a whole-of-government approach that gives one central location for ransomware resources and alerts.
  • Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide
  • No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment


  • To report an incident and request technical assistance, contact CISA at or 888-282-0870, or FBI through a local field office. 
  • Financial Institutions must ensure compliance with any applicable Bank Secrecy Act requirements, including suspicious activity reporting obligations. Indicators of compromise (IOCs), such as suspicious email addresses, file names, hashes, domains, and IP addresses, can be provided under Item 44 of the Suspicious Activity Report (SAR) form. For more information on mandatory and voluntary reporting of cyber events via SARs, see FinCEN Advisory FIN-2016-A005, Advisory to Financial Institutions on Cyber-Events and Cyber-Enabled Crime, October 25, 2016; and FinCEN Advisory FIN-2021-A004, Advisory on Ransomware and the Use of the Financial System to Facilitate Ransom Payments, November 8, 2021, which updates FinCEN Advisory FIN-2020-A006.
  • The U.S. Department of State’s Rewards for Justice (RFJ) program offers a reward of up to $10 million for reports of foreign government malicious activity against U.S. critical infrastructure. See the RFJ website for more information and how to report information securely.

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at When available, please include the following information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact. To report incidents and anomalous activity or to request incident response resources or technical assistance related to this threat, contact CISA at


  • June 30, 2022: Initial Version

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

Hosting PowerShell in a Python script

This post was originally published on this site

Yes Virginia, languages other than PowerShell do exist.

I was working with a partner group here at Microsoft and they explained that they wanted to parse PowerShell scripts from Python.
Their natural approach was to invoke the PowerShell executable and construct a command-line that did what they needed.
I thought there might be a better way as creating a new PowerShell process each time is expensive, so I started doing a bit of research to see something could be done.
I’ve been aware of IronPython (Python that tightly integrates .NET) for a long time, and
we met with Jim Hugunin shortly after he arrived at Microsoft and PowerShell was just getting underway,
but the group is using cPython so I went hunting for Python modules that host .NET and found the pythonnet module.

The pythonnet package gives Python developers extremely easy access to the dotnet runtime from Python.
I thought this package might be the key for accessing PowerShell,
after some investigation I found that it has exactly what I needed to host PowerShell in a Python script.

The guts

I needed to figure out a way to load the PowerShell engine.
First, there are a couple of requirements to make this all work.
Dotnet has to be available, as does PowerShell and pythonnet provides a way to specify where to look for dotnet.
Setting the environment variable DOTNET_ROOT to the install location,
enables pythonnet a way find the assemblies and other support files to host .NET.

import os
os.environ["DOTNET_ROOT"] = "/root/.dotnet"

Now that we know where dotnet is, we need to load up the CLR and set up the runtime configuration.
The runtime configuration describes various aspects of how we’ll run.
We can create a very simple pspython.runtimeconfig.json

  "runtimeOptions": {
    "tfm": "net6.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "6.0.0"

The combination of the DOTNET_ROOT and the runtime configuration enables
loading the CLR with the get_coreclr and set_runtime functions.

# load up the clr
from clr_loader import get_coreclr
from pythonnet import set_runtime
rt = get_coreclr("/root/pspython.runtimeconfig.json")

Now that we have the CLR loaded, we need to load the PowerShell engine.
This was a little non-obvious.
Initially, I just attempted to load System.Management.Automation.dll but that failed
due to a strong name validation error.
However, If I loaded Microsoft.Management.Infrastructure.dll first, I can avoid that error.
I’m not yet sure about why I need to load this assembly first, that’s still something
I need to determine.

import clr
import sys
import System
from System import Environment
from System import Reflection

psHome = r'/opt/microsoft/powershell/7/'

mmi = psHome + r'Microsoft.Management.Infrastructure.dll'
from Microsoft.Management.Infrastructure import *

full_filename = psHome + r'System.Management.Automation.dll'
from System.Management.Automation import *
from System.Management.Automation.Language import Parser

Eventually I would like to make the locations of dotnet and PSHOME configurable,
but for the moment, I have what I need.

Now that the PowerShell engine is available to me,
I created a couple of helper functions to make handling the results easier from Python.
I also created a PowerShell object (PowerShell.Create()) that I will use in some of my functions.

ps = PowerShell.Create()
def PsRunScript(script):
    result = ps.Invoke()
    rlist = []
    for r in result:
    return rlist

class ParseResult:
    def __init__(self, scriptDefinition, tupleResult):
        self.ScriptDefinition = scriptDefinition
        self.Ast = tupleResult[0]
        self.Tokens = tupleResult[1]
        self.Errors = tupleResult[2]

    def PrintAst(self):

    def PrintErrors(self):
        for e in self.Errors:

    def PrintTokens(self):
        for t in self.Tokens:

    def FindAst(self, astname):
        Func = getattr(System, "Func`2")
        func = Func[System.Management.Automation.Language.Ast, bool](lambda a : type(a).__name__ == astname)
        asts = self.Ast.FindAll(func, True)
        return asts

def ParseScript(scriptDefinition):
    token = None
    error = None
    # this returns a tuple of ast, tokens, and errors rather than the c# out parameter
    ast = Parser.ParseInput(scriptDefinition, token, error)
    # ParseResult will bundle the 3 parts into something more easily consumed.
    pr = ParseResult(scriptDefinition, ast)
    return pr

def ParseFile(filePath):
    token = None
    error = None
    # this returns a tuple of ast, tokens, and errors rather than the c# out parameter
    ast = Parser.ParseFile(filePath, token, error)
    # ParseResult will bundle the 3 parts into something more easily consumed.
    pr = ParseResult(filePath, ast)
    return pr

def PrintResults(result):
    for r in result:

I really wanted to mimic the PowerShell AST methods with some more friendly Python functions.
To create the FindAst() function, I needed to combine the delegate in c# with the lambda feature in Python.
Normally, in PowerShell, this would look like:

$ast.FindAll({$args[0] -is [System.Management.Automation.Language.CommandAst]}, $true)

But I thought from a Python script, it would easier to use the name of the type.
You still need to know the name of the type,
but bing is great for that sort of thing.
As I said, I don’t really know the Python language,
so I expect there are better ways to handle the Collection[PSObject] that Invoke() returns.
I found that I had to iterate over the result no matter what, so I built it into the convenience function.
Anyone with suggestions is more than welcome to improve this.

The glory

Now that we have the base module together, we can write some pretty simple Python to
execute our PowerShell scripts.
Invoking a PowerShell script is now as easy as:


from pspython import *

scriptDefinition = 'Get-ChildItem'
print(f"Run the script: '{scriptDefinition}")
result = PsRunScript(scriptDefinition)

You’ll notice that the output is not formatted by PowerShell.
This is because Python is just taking the .NET objects and (essentially) calling ToString() on them.

It’s also possible to retrieve objects and then manage formatting via PowerShell.
This example retrieves objects via Get-ChildItem,
selects those files that start with “ps” in Python,
and then creates a string result in table format.

scriptDefinition = 'Get-ChildItem'
result = list(filter(lambda r: r.BaseObject.Name.startswith('ps'), PsRunScript(scriptDefinition)))
ps.Commands.AddCommand("Out-String").AddParameter("Stream", True).AddParameter("InputObject", result)
strResult = ps.Invoke()
# print results
    Directory: /root

UnixMode   User             Group                 LastWriteTime           Size Name
--------   ----             -----                 -------------           ---- ----
-rwxr-xr-x root             dialout             6/17/2022 01:30           1117
-rwxr-xr-x root             dialout             6/16/2022 18:55           2474
-rwxr-xr-x root             dialout             6/16/2022 21:43            684

But that’s not all

We can also call static methods on PowerShell types.
Those of you that noticed in my module there are a couple of language related functions.
The ParseScript and ParseFile functions allow us to call the PowerShell language parser
enabling some very interesting scenarios.

Imagine I wanted to determine what commands a script is calling.
The PowerShell AST makes that a breeze, but first we have to use the parser.
In PowerShell, that would be done like this:

$tokens = $errors = $null
$AST = [System.Management.Automation.Language.Parser]::ParseFile("myscript.ps1", [ref]$tokens, [ref]$errors)

The resulting AST is stored in $AST, the tokens in $tokens, and the errors in $errors.
With this Python module, I encapsulate that into the Python function ParseFile,
which returns an object containing all three of those results in a single element.
I also created a couple of helper functions to print the tokens and errors more easily.
Additionally, I created a function that allows me to look for any type of AST (or sub AST)
in any arbitrary AST.

parseResult = ParseFile(scriptFile)
commandAst = parseResult.FindAst("CommandAst")
commands = set()
for c in commandAst:
    commandName = c.GetCommandName()
    # sometimes CommandName is null, don't include those
    if commandName != None:

Note that there is a check for commandName not being null.
This is because when & $commandName is used, the command name cannot be
determined via static analysis since the command name is determined at run-time.

…a few, uh, provisos, uh, a couple of quid pro quo

First, you have to have dotnet installed (via the install-dotnet),
as well as a full installation of PowerShell.
pythonnet doesn’t run on all versions of Python,
I’ve tested it only on Python 3.8 and Python 3.9 on Ubuntu20.04.
As of the time I wrote this, I couldn’t get it to run on Python 3.10.
There’s more info on pythonnet at the pythonnet web-site.
Also, this is a hosted instance of PowerShell.
Some things, like progress, and verbose, and errors may act a bit differently than you
would see from pwsh.exe.
Over time, I will probably add additional helper functions to retrieve more runtime information
from the engine instance.
If you would like to pitch in, I’m happy to take Pull Requests or to simply understand your use cases integrating PowerShell and Python.

Take it out for a spin

I’ve wrapped all of this up and added a Dockerfile (running on Ubuntu 20.04) on
To create the docker image, just run
Docker build --tag pspython:demo .
from the root of the repository.

The post Hosting PowerShell in a Python script appeared first on PowerShell Team.

AA22-174A: Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems

This post was originally published on this site

Original release date: June 23, 2022


Actions to take today:
• Install fixed builds, updating all affected VMware Horizon and UAG systems to the latest versions. If updates or workarounds were not promptly applied following VMware’s release of updates for Log4Shell in December 2021, treat all affected VMware systems as compromised.
• Minimize the internet-facing attack surface by hosting essential services on a segregated demilitarized (DMZ) zone, ensuring strict network perimeter access controls, and implementing regularly updated web application firewalls (WAFs) in front of public-facing services

The Cybersecurity and Infrastructure Security Agency (CISA) and United States Coast Guard Cyber Command (CGCYBER) are releasing this joint Cybersecurity Advisory (CSA) to warn network defenders that cyber threat actors, including state-sponsored advanced persistent threat (APT) actors, have continued to exploit CVE-2021-44228 (Log4Shell) in VMware Horizon® and Unified Access Gateway (UAG) servers to obtain initial access to organizations that did not apply available patches or workarounds.

Since December 2021, multiple threat actor groups have exploited Log4Shell on unpatched, public-facing VMware Horizon and UAG servers. As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command and control (C2). In one confirmed compromise, these APT actors were able to move laterally inside the network, gain access to a disaster recovery network, and collect and exfiltrate sensitive data.

This CSA provides the suspected APT actors’ tactics, techniques, and procedures (TTPs), information on the loader malware, and indicators of compromise (IOCs). The information is derived from two related incident response engagements and malware analysis of samples discovered on the victims’ networks.

CISA and CGCYBER recommend all organizations with affected systems that did not immediately apply available patches or workarounds to assume compromise and initiate threat hunting activities using the IOCs provided in this CSA, Malware Analysis Report (MAR)-10382580-1, and MAR-10382254-1. If potential compromise is detected, administrators should apply the incident response recommendations included in this CSA and report key findings to CISA.

See the list below to download copies of IOCs: 

Download the pdf version of this report: [pdf, 483 kb]

Technical Details

Note: this advisory uses the MITRE ATT&CK for Enterprise framework, version 11. See Appendix A for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques.

Log4Shell is a remote code execution vulnerability affecting the Apache® Log4j library and a variety of products using Log4j, such as consumer and enterprise services, websites, applications, and other products, including certain versions of VMware Horizon and UAG. The vulnerability enables malicious cyber actors to submit a specially crafted request to a vulnerable system, causing the system to execute arbitrary code. The request allows the malicious actors to take full control of the affected system. (For more information on Log4Shell, see CISA’s Apache Log4j Vulnerability Guidance webpage and VMware advisory VMSA-2021-0028.13.) 

VMware made fixes available in December 2021 and confirmed exploitation in the wild on December 10, 2021.[1] Since December 2021, multiple cyber threat actor groups have exploited [T1190] Log4Shell on unpatched, public-facing VMware Horizon and UAG servers to obtain initial access [TA0001] to networks. 

After obtaining access, some actors implanted loader malware on compromised systems with embedded executables enabling remote C2. These actors connected to known malicious IP address 104.223.34[.]198.[2] This IP address uses a self-signed certificate CN: WIN-P9NRMH5G6M8. In at least one confirmed compromise, the actors collected and exfiltrated sensitive information from the victim’s network. 

The sections below provide information CISA and CGCYBER obtained during incident response activities at two related confirmed compromises.

Victim 1

CGCYBER conducted a proactive threat-hunting engagement at an organization (Victim 1) compromised by actors exploiting Log4Shell in VMware Horizon. After obtaining access, threat actors uploaded malware, hmsvc.exe, to a compromised system. During malware installation, connections to IP address 104.223.34[.]198 were observed. 

CISA and CGCYBER analyzed a sample of hmsvc.exe from the confirmed compromise. hmsvc.exe masquerades as a legitimate Microsoft® Windows® service (SysInternals LogonSessions software) [T1036.004] and appears to be a modified version of SysInternals LogonSessions software embedded with malicious packed code. When discovered, the analyzed sample of hmsvc.exe was running as NT AUTHORITYSYSTEM, the highest privilege level on a Windows system. It is unknown how the actors elevated privileges. 

hmsvc.exe is a Windows loader containing an embedded executable, 658_dump_64.exe. The embedded executable is a remote access tool that provides an array of C2 capabilities, including the ability to log keystrokes [T1056.001], upload and execute additional payloads [T1105], and provide graphical user interface (GUI) access over a target Windows system’s desktop. The malware can function as a C2 tunneling proxy [T1090], allowing a remote operator to pivot to other systems and move further into a network.

When first executed, hmsvc.exe creates the Scheduled Task [T1053.005], C:WindowsSystem32TasksLocal Session Updater, which executes malware every hour. When executed, two randomly named *.tmp files are written to the disk at the location C:Users<USER>AppDataLocalTemp and the embedded executable attempts to connect to hard-coded C2 server 192.95.20[.]8 over port 4443, a non-standard port [TT571]. The executable’s inbound and outbound communications are encrypted with a 128-bit key [T1573.001].

For more information on hmsvc.exe, including IOCs and detection signatures, see MAR-10382254-1.

Victim 2

From late April through May 2022, CISA conducted an onsite incident response engagement at an organization (Victim 2) where CISA observed bi-directional traffic between the organization and suspected APT IP address 104.223.34[.]198. During incident response, CISA determined Victim 2 was compromised by multiple threat actor groups. 

The threat actors using IP 104.223.34[.]198 gained initial access to Victim 2’s production environment in late January 2022, or earlier. These actors likely obtained access by exploiting Log4Shell in an unpatched VMware Horizon server. On or around January 30, likely shortly after the threat actors gained access, CISA observed the actors using PowerShell scripts [T1059.001] to callout to 109.248.150[.]13 via Hypertext Transfer Protocol (HTTP) [T1071.001] to retrieve additional PowerShell scripts. Around the same period, CISA observed the actors attempt to download [T1105] and execute a malicious file from 109.248.150[.]13. The activity started from IP address 104.155.149[.]103, which appears to be part of the actors’ C2 [TA0011] infrastructure. 

After gaining initial access to the VMware Horizon server, the threat actors moved laterally [TA0008] via Remote Desktop Protocol (RDP) [T1021.001] to multiple other hosts in the production environment, including a security management server, a certificate server, a database containing sensitive law enforcement data, and a mail relay server. The threat actors also moved laterally via RDP to the organization’s disaster recovery network. The threat actors gained credentials [TA0006] for multiple accounts, including administrator accounts. It is unknown how these credentials were acquired. 

After moving laterally to other production environment hosts and servers, the actors implanted loader malware on compromised servers containing executables enabling remote C2. The threat actors used compromised administrator accounts to run the loader malware. The loader malware appears to be modified versions of SysInternals LogonSessions, Du, or PsPing software. The embedded executables belong to the same malware family, are similar in design and functionality to 658_dump_64.exe, and provide C2 capabilities to a remote operator. These C2 capabilities include the ability to remotely monitor a system’s desktop, gain reverse shell access, exfiltrate data, and upload and execute additional payloads. The embedded executables can also function as a proxy. 

CISA found the following loader malware:

  • SvcEdge.exe is a malicious Windows loader containing encrypted executable f7_dump_64.exe. When executed, SvcEdge.exe decrypts and loads f7_dump_64.exe into memory. During runtime, f7_dump_64.exe connects to hard-coded C2 server 134.119.177[.]107 over port 443
  • odbccads.exe is a malicious Windows loader containing an encrypted executable. When executed, odbccads.exe decrypts and loads the executable into memory. The executable attempts communication with the remote C2 address 134.119.177[.]107
  • praiser.exe is a Windows loader containing an encrypted executable. When executed, praiser.exe decrypts and loads the executable into memory. The executable attempts connection to hard-coded C2 address 162.245.190[.]203.
  • fontdrvhosts.exe is a Windows loader that contains an encrypted executable. When executed, fontdrvhosts.exe decrypts and loads the executable into memory. The executable attempts connection to hard-coded C2 address 155.94.211[.]207.
  • winds.exe is a Windows loader containing an encrypted malicious executable and was found on a server running as a service. During runtime, the encrypted executable is decrypted and loaded into memory. The executable attempts communication with hard-coded C2 address 185.136.163[.]104. winds.exe has complex obfuscation, hindering the analysis of its code structures. The executable’s inbound and outbound communications are encrypted with an XOR key [T1573.001].

For more information on these malware samples, including IOCs and detection signatures, see MAR-10382580-1.

Additionally, CISA identified a Java® Server Pages (JSP) application (error_401.js) functioning as a malicious webshell [T505.003] and a malicious Dynamic Link Library (DLL) file:

  • error_401.jsp is a webshell designed to parse data and commands from incoming HTTP requests, providing a remote operator C2 capabilities over compromised Linux and Windows systems. error_401.jsp allows actors to retrieve files from the target system, upload files to the target system, and execute commands on the target system. rtelnet is used to execute commands on the target system. Commands and data sent are encrypted via RC4 [T1573.001]. For more information on error_401.jsp, including IOCs, see [MAR-10382580 2].
  • newdev.dll ran as a service in the profile of a known compromised user on a mail relay server. The malware had path: C:Users<user>AppDataRoamingnewdev.dll. The DLL may be the same newdev.dll attributed to the APT actors in open-source reporting; however, CISA was unable to recover the file for analysis. 

Threat actors collected [TA0009] and likely exfiltrated [TA0010] data from Victim 2’s production environment. For a three week period, the security management and certificate servers communicated with the foreign IP address 92.222.241[.]76. During this same period, the security management server sent more than 130 gigabytes (GB) of data to foreign IP address 92.222.241[.]76, indicating the actors likely exfiltrated data from the production environment. CISA also found .rar files containing sensitive law enforcement investigation data [T1560.001] under a known compromised administrator account.

Note: the second threat actor group had access to the organization’s test and production environments, and on or around April 13, 2022, leveraged CVE-2022-22954 to implant the Dingo J-spy webshell. According to trusted third-party reporting, multiple large organizations have been targeted by cyber actors leveraging CVE-2022-22954 and CVE-2022-22960. For more information on exploitation of CVE-2022-22954 and CVE-2022-22960, see CISA CSA Threat Actors Chaining Unpatched VMware Vulnerabilities for Full System Control.

Incident Response

If administrators discover system compromise, CISA and CGCYBER recommend:

  1. Immediately isolating affected systems. 
  2. Collecting and reviewing relevant logs, data, and artifacts.
  3. Considering soliciting support from a third-party incident response organization that can provide subject matter expertise, ensure the actor is eradicated from the network, and avoid residual issues that could enable follow-on exploitation.
  4. Reporting incidents to CISA via CISA’s 24/7 Operations Center ( or 888-282-0870). To report cyber incidents to the Coast Guard pursuant to 33 CFR Section 101.305,  contact the U.S. Coast Guard (USCG) National Response Center (NRC) ( or 800-424-8802). 


CISA and CGCYBER recommend organizations 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 without parameters to ensure that no vulnerabilities remain. See KB87073 for details. 

Additionally, CISA and CGCYBER recommend organizations:

  • 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 non-essential to business operations. Where possible, implement regularly updated WAFs 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 multifactor authentication (MFA), enforcing use of strong passwords, and limiting user access through the principle of least privilege.

Contact Information

Recipients of this report are encouraged to contribute any additional information related to this threat.

  • To request incident response resources or technical assistance related to these threats, email CISA at To contact Coast Guard Cyber Command in relation to these threats, email
  • To report cyber incidents to the Coast Guard pursuant to 33 CFR Section 101.305  contact the USCG NRC ( or 800-424-8802).



[1] VMware Security Advisory VMSA-2021-0028.13
[2] Fortinet’s blog New Milestones for Deep Panda: Log4Shell and Digitally Signed Fire Chili Rootkits

Appendix A: Indicators of Compromise

See MAR-10382580-1 and MAR-10382254-1 and Table 1 for IOCs. See the list below to download copies of these IOCs: 

Table 1: Indicators of Compromise

Type Indicator Description
IP Address 104.223.34[.]198   IP address closely associated with the installation of malware on victims.
92.222.241[.]76  Victim 2 servers communicated with this IP address and sent data to it during a three-week period.
109.248.150[.]13  Actors attempting to download and execute a malicious file from this address.
104.155.149[.]103  Appears to be a part of the actors’ C2 infrastructure. 
Network Port 192.95.20[.]8:80    Same description as IP 192.95.20[.]8, but includes the specific destination port of 80, which was identified in logs and during malware analysis.
1389  This was the most common destination port for Log4Shell exploitation outbound connections.  Multiple unique destination addresses were used for Log4Shell callback.
104.223.34[.]198:443  IP address closely associated to the installation of malware on victims with the specific destination port of 443.
Scheduled Task C:WindowsSystem32TasksLocal Session Update  Scheduled task created by hmsvc.exe to execute the program hourly.
File Path C:WindowsTemplnk{4_RANDOM_CHARS}.tmp  File created by hmsvc.exe with a random four-character filename.
C:WindowsTemplnk<4_RANDOM_NUMS_CHAR S>.tmp File created by hmsvc.exe with a random four-character filename.

Appendix B: Threat Actor TTPs

See Table 2 for the threat actors’ tactics and techniques identified in this CSA. See the MITRE ATT&CK for Enterprise framework, version 11, for all referenced threat actor tactics and techniques.

Table 2: Tactics and Techniques

Tactic Technique
Initial Access [TA0001] Exploit Public-Facing Application [T1190

Execution [TA0002]

Command and Scripting Interpreter: PowerShell [T1059.001]
Scheduled Task/Job: Scheduled Task [T1053.005]
Persistence [TA0003] Server Software Component: Web Shell [T1505.003]
Defense Evasion [TA0005] Masquerading: Masquerade Task or Service [T1036.004]
Credential Access [TA0006]  
Lateral Movement [TA0008] Remote Services: Remote Desktop Protocol [T1021.001]
Collection [TA0009 Archive Collected Data: Archive via Utility [T1560.001]
Input Capture: Keylogging [T1056.001]
Command and Control [TA0011] Application Layer Protocol: Web Protocols [T1071.001]
Encrypted Channel: Symmetric Cryptography [1573.001]
Ingress Tool Transfer [T1105]
Non-Standard Port [T1571]
  Proxy [T1090]


© 2021 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.


CISA and CGCYBER would like to thank VMware and Secureworks for their contributions to this CSA.


  • June 23, 2022: Initial version

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

FLOSS 2.0 Has Been Released, (Thu, Jun 23rd)

This post was originally published on this site

When you have to deal with malware in your day job, for research purposes, or just for fun, one of the key points is to have a lab ready to be launched. Your sandbox must be properly protected and isolated to detonate your samples in a safe way but it must also be fulfilled with tools, and scripts. This toolbox is yours and will be based on your preferred tools but starting from zero is hard, that's why there are specific Linux distributions built for this purpose. The one that I use in FOR610 and for my daily investigations is REMnux[1], created and maintained by Lenny Zeltser[2]. This environment offers tons of tools that help to perform all the malware analysis steps from static analysis up to code reversing and debugging.

Skyline Collector – Send Syslog Data to Centralized Log Host

This post was originally published on this site

Tweet In most cases, you don’t need to make any changes to your Skyline Collector.  For some environments, you have a mandate to ensure that all syslog are sent to a centralized repository for audit analysis.  It doesn’t matter if that centralized syslog server is a VMware Log Insight, Splunk, or ELK.  Here are the … Continued

The post Skyline Collector – Send Syslog Data to Centralized Log Host appeared first on VMware Support Insider.

Skyline Insights API – How To Get List and Details with PowerCLI

This post was originally published on this site

Tweet In the previous blog entries, I have shown how to get (a) get list of findings and (b) how to get the details (affected objects) using curl.   You can find that blog here.   Now I want to show the same information. This time, I am using Powershell/Powercli for our fellow Windows-based administrators.  To get … Continued

The post Skyline Insights API – How To Get List and Details with PowerCLI appeared first on VMware Support Insider.