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.

Case Study: Cobalt Strike Server Lives on After Its Domain Is Suspended, (Thu, Jun 30th)

This post was originally published on this site


How do threat actors behind a Cobalt Strike server keep it running after its domain is taken down?  If the server is not hosted through the domain registrar, it merely keeps running on the same IP address.

Today's diary is a case study where Cobalt Strike remained active on the same IP address at least one week after its domain was suspended.

Traffic Forensics

On Tuesday 2022-06-28, I generated a Qakbot infection in my lab and saw Cobalt Strike HTTPS traffic on 147.78.47[.]223 over TCP port 443 as shown below.

Shown above:  Traffic from a Qakbot infection with Cobalt Strike on Tuesday 2022-06-28 filtered in Wireshark.

Examining the certificate in Wireshark reveals it's a Let's Encrypt certificate for moros[.]icu.  Let's Encrypt is a legitimate free, automated, and open certificate authority (CA).  While used by many valid websites, this service is commonly abused by threat actors, including those behind malicious Cobalt Strike activity.

Shown above:  Reviewing certificate issuer data associated with Cobalt Strike traffic on 147.78.47[.]223 in Wireshark.

Investigating the Malicious Server

Viewing the certificate from 147.78.47[.]223 in a web browser reveals it was originally issued for moros[.]icu through Let's Encrypt on 2022-06-20 and is no longer valid for that IP.

Shown above:  Connecting to the Cobalt Strike server using a web browser.

Shown above:  Certificate data for moros[.]icu shown in a web browser.

The domain moros[.]icu was reported and suspended less than one day after it was registered through Namecheap, but its server was set up through a legitimate hosting provider at Flyservers.  Kudos to @ian_kenefick and Namecheap for quickly taking action and suspending this malicious domain!

Shown above: Tweets showing moros[.]icu was suspended on 2022-06-21.

Shown above:  My own confirmation that moros[.]icu no longer works.

Shown above:  Whois lookup for 147.78.47[.]223 using

The certificate's validity did not matter for Cobalt Strike activity I found on Tuesday 2022-06-28.  Since the traffic was generated by malware instead of a web browser, HTTPS still worked.

Flyservers has been a hosting provider since 2001, and it appears to be a legitimate company.  I've emailed their abuse address to report the malicious server on 147.78.47[.]223.

Final Words

Threat actors continually abuse legitimate hosting providers and certificate authorities (CAs), presumably through fraudulent accounts.  Both free and paid services are incredibly susceptible to criminal abuse.  Even Cobalt Strike is a legitimate red team tool commonly abused by various threat actors.

Security professionals can quickly report abuse cases, and service providers can rapidly shut down individual violations.  However, threat actors can easily recover, and malware-related servers will continue to be an issue for defenders everywhere.

This case study reveals how criminal activity can circumvent domain takedowns.  It also illustrates how time-intensive the associated investigation and corrective actions can be.

Brad Duncan
brad [at]

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

Possible Scans for HiByMusic Devices, (Tue, Jun 28th)

This post was originally published on this site

HiBy is a brand of portable music players built around the Android operating system. Probably a bit comparable to the now-defunct iPod touch, the device does use a close to "stock" version of Android and adds its own "HiByMusic" application as a music player. The hardware includes a Snapdragon ARM CPU standard on Android devices and attempts to distinguish itself with DACs claimed to be better than those found in other devices.

image of hiby music device
Image of HiBy device from



The device offers a feature to load custom network radio station URLs via a "radio.txt" file. The file is a simple text file with a list of URLs. For example:

Radio Dismuke 1920s-30s pop/jazz,
SomaFM: Heavyweight Reggae,
SomaFM: Groove Salad,
SomaFM: Groove Salad Classic,
(sample of a radio.txt file found here:

I was a bit surprised that we recently started seeing some scans looking for radio.txt files based on our "First Seen" report. The number of submissions is small. (see the URL History for radio.txt)

So the question is: why?

  • I found one vulnerability specific to HiByMusic: %%CVE:2021-44124%% . It is a simple directory traversal and may result in information leakage. I don't think this is all that interesting but sure. Maybe other vulnerabilities have not yet been made public, or the attacker is looking for generic Android issues
  • radio.txt files may include internal audio sources that are not openly advertised. This could leak information.
  • Or just someone essentially trying to build a "radio station spider" to find as many publicly available radio stations as possible. Anybody knows if this "radio.txt" file is unique to HiByMusic, or if other players use files like this?

At least one more report is not linked to our data observing requests for radio.txt.

Any ideas about what's going on here? 

Johannes B. Ullrich, Ph.D. , Dean of Research,

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

AWS Week in Review – June 27, 2022

This post was originally published on this site

This post is part of our Week in Review series. Check back each week for a quick roundup of interesting news and announcements from AWS!

It’s the beginning of a new week, and I’d like to start with a recap of the most significant AWS news from the previous 7 days. Last week was special because I had the privilege to be at the very first EMEA AWS Heroes Summit in Milan, Italy. It was a great opportunity of mutual learning as this community of experts shared their thoughts with AWS developer advocates, product managers, and technologists on topics such as containers, serverless, and machine learning.

Participants at the EMEA AWS Heroes Summit 2022

Last Week’s Launches
Here are the launches that got my attention last week:

Amazon Connect Cases (available in preview) – This new capability of Amazon Connect provides built-in case management for your contact center agents to create, collaborate on, and resolve customer issues. Learn more in this blog post that shows how to simplify case management in your contact center.

Many updates for Amazon RDS and Amazon AuroraAmazon RDS Custom for Oracle now supports Oracle database 12.2 and 18c, and Amazon RDS Multi-AZ deployments with one primary and two readable standby database instances now supports M5d and R5d instances and is available in more Regions. There is also a Regional expansion for RDS Custom. Finally, PostgreSQL 14, a new major version, is now supported by Amazon Aurora PostgreSQL-Compatible Edition.

AWS WAF Captcha is now generally available – You can use AWS WAF Captcha to block unwanted bot traffic by requiring users to successfully complete challenges before their web requests are allowed to reach resources.

Private IP VPNs with AWS Site-to-Site VPN – You can now deploy AWS Site-to-Site VPN connections over AWS Direct Connect using private IP addresses. This way, you can encrypt traffic between on-premises networks and AWS via Direct Connect connections without the need for public IP addresses.

AWS Center for Quantum Networking – Research and development of quantum computers have the potential to revolutionize science and technology. To address fundamental scientific and engineering challenges and develop new hardware, software, and applications for quantum networks, we announced the AWS Center for Quantum Networking.

Simpler access to sustainability data, plus a global hackathon – The Amazon Sustainability Data Initiative catalog of datasets is now searchable and discoverable through AWS Data Exchange. As part of a new collaboration with the International Research Centre in Artificial Intelligence, under the auspices of UNESCO, you can use the power of the cloud to help the world become sustainable by participating to the Amazon Sustainability Data Initiative Global Hackathon.

For a full list of AWS announcements, be sure to keep an eye on the What’s New at AWS page.

Other AWS News
A couple of takeaways from the Amazon re:MARS conference:

Amazon CodeWhisperer (preview) – Amazon CodeWhisperer is a coding companion powered by machine learning with support for multiple IDEs and languages.

Synthetic data generation with Amazon SageMaker Ground TruthGenerate labeled synthetic image data that you can combine with real-world data to create more complete training datasets for your ML models.

Some other updates you might have missed:

AstraZeneca’s drug design program built using AWS wins innovation award – AstraZeneca received the BioIT World Innovative Practice Award at the 20th anniversary of the Bio-IT World Conference for its novel augmented drug design platform built on AWS. More in this blog post.

Large object storage strategies for Amazon DynamoDB – A blog post showing different options for handling large objects within DynamoDB and the benefits and disadvantages of each approach.

Amazon DevOps Guru for RDS under the hoodSome details of how DevOps Guru for RDS works, with a specific focus on its scalability, security, and availability.

AWS open-source news and updates – A newsletter curated by my colleague Ricardo to bring you the latest open-source projects, posts, events, and more.

Upcoming AWS Events
It’s AWS Summits season and here are some virtual and in-person events that might be close to you:

On June 30, the AWS User Group Ukraine is running an AWS Tech Conference to discuss digital transformation with AWS. Join to learn from many sessions including a fireside chat with Dr. Werner Vogels, CTO at

That’s all from me for this week. Come back next Monday for another Week in Review!


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.

Encrypted Client Hello: Anybody Using it Yet?, (Mon, Jun 27th)

This post was originally published on this site

The first payload sent by a TLS client to a TLS server is a "Client Hello." It includes several parameters supported by the client, such as available cipher suites, to start negotiating a compatible set of TLS parameters with the server. 

One particular option, the "Server Name Indication" (SNI), lists the hostname the client is looking for. The client hello is sent in the clear and has often been considered a privacy issue or, for some network defenders, the last straw to hold on to gain insight into TLS encrypted traffic.

Encrypted SNI (ESNI) was an initial solution to the privacy problem. As the name implies, it encrypts the SNI option in the client hello. The encryption uses a key communicated via DNS. You will first see a DNS lookup for a TXT record _esni.[domain name]. This TXT record will return the public key to encrypt the SNI option.

ESNI solves a significant part of the client hello privacy problem. But other client-hello options may be used to fingerprint clients. Encrypting the entire client hello message is the next obvious option. This idea, Encrypted Client Hello (ECH), is currently an IETF draft [ECH]. The encrypted client hello options are wrapped into an unencrypted "Client Hello Outer" that is used as a vessel to transport the encrypted blob. This blob will look like any other client hello option to a server not capable of ECH. 

Instead of a TXT record to communicate the key, ECH uses new SVCB and HTTPS records. This record provides more flexibility to advertise different options and keys [HTTPSRR].

Despite these standards in the draft stage, browsers are adding support for them. For the most part, ESNI is considered "dead" at this point, and browsers actively support ECH, but it may not be enabled by default. One feature that may lead to SVCB and HTTPS records being more commonly used than similar protocols like DANE is that SVCB/HTTPS does not require DNSSEC. The client will be able to verify the authenticity of the server using the usual TLS certificates. The DNS messages remain unprotected. As pointed out in the IETF draft, a hostile resolve will be able to downgrade the DNS responses.

But back to the title: Is anybody using these fancy standards? I took a look at my DNS logs to see how many requests I am seeing (and how many of them result in answers):

DNS requests for HTTPS records are undoubtedly popular, with about one HTTPS request for every 4 A record requests. Also, about 20% of the responses to HTTPS queries include at least one answer. So this looks pretty good, but the answer section of the response will not provide an answer here. None of the answers included an HTTPS record. They exclusively include A or CNAME records, which is also perfectly legal.

And a little side note if you want to play with this: The "dig" utility, at least the version I used (9.16.1-Ubuntu), does not fully understand the HTTPS record type.

$ dig -t HTTPS
;; Warning, ignoring invalid type HTTPS

This warning is easily overlooked. Instead, try:

$dig -t TYPE65

;; ANSWER SECTION:    18    IN    TYPE65    # 67 0001000001000C0268330568332D323902683200040008681229AEAC 40925200060020260647004400000000000000681229AE2606470044 00000000000000AC409252

To query HTTPS records.

But the short answer to the headline question: No. Clients try to use it, but servers are not yet supporting encrypted client hello. Know of any example sites using it? Any comments or other suggestions to improve the methodology? Please leave a comment.

Oh. And, of course, this looks like yet another DNS covert channel opportunity. 


Johannes B. Ullrich, Ph.D. , Dean of Research,

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.

More Decoding Analysis, (Sun, Jun 26th)

This post was originally published on this site

I received several reactions to my diary entry "Decoding Obfuscated BASE64 Statistically" and accompanying video.

I also made another example, this time with hexadecimal encoding.

The blog post: "Another Exercise In Encoding Reversing"

The video:


Didier Stevens
Senior handler
Microsoft MVP

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.