AA21-148A: Sophisticated Spearphishing Campaign Targets Government Organizations, IGOs, and NGOs

This post was originally published on this site

Original release date: May 28, 2021

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are responding to a spearphishing campaign targeting government organizations, intergovernmental organizations (IGOs), and non-governmental organizations (NGOs). A sophisticated cyber threat actor leveraged a compromised end-user account from Constant Contact, a legitimate email marketing software company, to spoof a U.S.-based government organization and distribute links to malicious URLs.[1] Note: CISA and FBI acknowledge open-source reporting attributing the activity discussed in the report to APT29 (also known as Nobelium, The Dukes, and Cozy Bear).[2,3] However, CISA and FBI are investigating this activity and have not attributed it to any threat actor at this time. CISA and FBI will update this Joint Cybersecurity Advisory as new information becomes available.

This Joint Cybersecurity Advisory contains information on tactics, techniques, and procedures (TTPs) and malware associated with this campaign. For more information on the malware, refer to Malware Analysis Report MAR-10339794-1.v1: Cobalt Strike Beacon.

CISA and FBI urge governmental and international affairs organizations and individuals associated with such organizations to immediately adopt a heightened state of awareness and implement the recommendations in the Mitigations section of this advisory.

For a downloadable list of indicators of compromise (IOCs), refer to AA21-148A.stix, and MAR-10339794-1.v1.stix.

Technical Details

Based on incident reports, malware collection, and trusted third-party reporting, CISA and FBI are responding to a sophisticated spearphishing campaign. A cyber threat actor leveraged a compromised end-user account from Constant Contact, a legitimate email marketing software company, to send phishing emails to more than 7,000 accounts across approximately 350 government organizations, IGOs, and NGOs. The threat actor sent spoofed emails that appeared to originate from a U.S. Government organization. The emails contained a legitimate Constant Contact link that redirected to a malicious URL [T1566.002, T1204.001], from which a malicious ISO file was dropped onto the victim’s machine.

The ISO file contained (1) a malicious Dynamic Link Library (DLL) named Documents.dll [T1055.001], which is a custom Cobalt Strike Beacon version 4 implant, (2) a malicious shortcut file that executes the Cobalt Strike Beacon loader [T1105], and (3) a benign decoy PDF titled “Foreign Threats to the 2020 US Federal Elections” with file name “ICA-declass.pdf” (see figure 1). Note: The decoy file appears to be a copy of the declassified Intelligence Community Assessment pursuant to Executive Order 13848 Section 1(a), which is available at https://www.intelligence.gov/index.php/ic-on-the-record-database/results/1046-foreign-threats-to-the-2020-us-federal-elections-intelligence-community-assessment.

Figure 1: Decoy PDF: ICA-declass.pdf

Cobalt Strike is a commercial penetration testing tool used to conduct red team operations.[4] It contains a number of tools that complement the cyber threat actor’s exploitation efforts, such as a keystroke logger, file injection capability, and network services scanners. The Cobalt Strike Beacon is the malicious implant that calls back to attacker-controlled infrastructure and checks for additional commands to execute on the compromised system [TA0011].

The configuration file for this Cobalt Strike Beacon implant contained communications protocols, an implant watermark, and the following hardcoded command and control (C2) domains:

  • dataplane.theyardservice[.]com/jquery-3.3.1.min.woff2
  • cdn.theyardservice[.]com/jquery-3.3.1.min.woff2
  • static.theyardservice[.]com/jquery-3.3.1.min.woff2
  • worldhomeoutlet[.]com/jquery-3.3.1.min.woff2

The configuration file was encoded via an XOR with the key 0x2e and a 16-bit byte swap.

For more information on the ISO file and Cobalt Strike Beacon implant, including IOCs, refer to Malware Analysis Report MAR-10339794-1.v1: Cobalt Strike Beacon.

Indicators of Compromise

The following IOCS were derived from trusted third parties and open-source research. For a downloadable list of IOCs, refer to AA21-148A.stix and MAR-10339794-1.v1.stix.

  • URL: https[:]//r20.rs6.net/tn.jsp?f=
    Host IP: 208.75.122[.]11 (US)
    Owner: Constant Contact, Inc.
    Activity: legitimate Constant Contact link found in phishing email that redirects victims to actor-controlled infrastructure at https[:]//usaid.theyardservice.com/d/<target_email_address>
     
  • URL: https[:]//usaid.theyardservice.com/d/<target_email_address>
    Host IP: 83.171.237[.]173 (Germany)
    Owner: [redacted]
    First Seen: May 25, 2021
    Activity: actor-controlled URL that was redirected from https[:]//r20.rs6.net/tn.jsp?f=; the domain usaid[.]theyardservice.com was detected as a malware site; hosted a malicious ISO file “usaid[.]theyardservice.com”
     
  • File: ICA-declass.iso [MD5: cbc1dc536cd6f4fb9648e229e5d23361]
    File Type: Macintosh Disk Image
    Detection: Artemis!7EDF943ED251, Trojan:Win32/Cobaltstrike!MSR, or other malware
    Activity: ISO file container; contains a custom Cobalt Strike Beacon loader; communicated with multiple URLs, domains, and IP addresses
     
  • File: /d/ [MD5: ebe2f8df39b4a94fb408580a728d351f]
    File Type: Macintosh Disk Image
    Detection: Cobalt, Artemis!7EDF943ED251, or other malware
    Activity: ISO file container; contains a custom Cobalt Strike Beacon loader; communicated with multiple URLs, domains, and IP addresses
     
  • File: ICA-declass.iso [MD5: 29e2ef8ef5c6ff95e98bff095e63dc05]
    File Type: Macintosh Disk Image
    Detection: Cobalt Strike, Rozena, or other malware
    Activity: ISO file container; contains a custom Cobalt Strike Beacon loader; communicated with multiple URLs, domains, and IP addresses
     
  • File: Reports.lnk [MD5: dcfd60883c73c3d92fceb6ac910d5b80]
    File Type: LNK (Windows shortcut)
    Detection: Worm: Win32-Script.Save.df8efe7a, Static AI – Suspicious LNK, or other malware
    Activity: shortcut contained in malicious ISO files; executes a custom Cobalt Strike Beacon loader
     
  • File: ICA-declass.pdf [MD5: b40b30329489d342b2aa5ef8309ad388]
    File Type: PDF
    Detection: undetected
    Activity: benign, password-protected PDF displayed to victim as a decoy; currently unrecognized by antivirus software
     
  • File: DOCUMENT.DLL [MD5: 7edf943ed251fa480c5ca5abb2446c75]
    File Type: Win32 DLL
    Detection: Trojan: Win32/Cobaltstrike!MSR, Rozena, or other malware
    Activity: custom Cobalt Strike Beacon loader contained in malicious ISO files; communicating with multiple URLs, domains, and IP addresses by antivirus software
     
  • File: DOCUMENT.DLL [MD5: 1c3b8ae594cb4ce24c2680b47cebf808]
    File Type: Win32 DLL
    Detection: Cobalt Strike, Razy, Khalesi, or other malware
    Activity: Custom Cobalt Strike Beacon loader contained in malicious ISO files; communicating with multiple URLs, domains, and IP addresses by antivirus software
     
  • Domain: usaid[.]theyardservice.com
    Host IP: 83.171.237[.]173 (Germany)
    First Seen: May 25, 2021
    Owner: Withheld for Privacy Purposes
    Activity: subdomain used to distribute ISO file according to the trusted third party; detected as a malware site by antivirus programs
     
  • Domain: worldhomeoutlet.com
    Host IP: 192.99.221[.]77 (Canada)
    Created Date: March 11, 2020
    Owner: Withheld for Privacy Purposes by Registrar
    Activity: Cobalt Strike C2 subdomain according to the trusted third party; categorized as suspicious and observed communicating with multiple malicious files according to antivirus software; associated with Cobalt Strike malware
     
  • Domain: dataplane.theyardservice[.]com
    Host IP: 83.171.237[.]173 (Germany)
    First Seen: May 25, 2021
    Owner: [redacted]
    Activity: Cobalt Strike C2 subdomain according to the trusted third party; categorized as suspicious and observed communicating with multiple malicious files according to antivirus software; observed in phishing, malware, and spam activity
     
  • Domain: cdn.theyardservice[.]com
    Host IP: 83.171.237[.]173 (Germany)
    First Seen: May 25, 2021
    Owner: Withheld for Privacy Purposes by Registrar
    Activity: Cobalt Strike C2 subdomain according to the trusted third party; categorized as suspicious and observed communicating with multiple malicious files according to antivirus software
     
  • Domain: static.theyardservice[.]com
    Host IP: 83.171.237[.]173 (Germany)
    First Seen: May 25, 2021
    Owner: Withheld for Privacy Purposes
    Activity: Cobalt Strike C2 subdomain according to the trusted third party; categorized as suspicious and observed communicating with multiple malicious files according to antivirus software
     
  • IP: 192.99.221[.]77
    Organization: OVH SAS
    Resolutions: 7
    Geolocation: Canada
    Activity: detected as a malware site; hosts a suspicious domain worldhomeoutlet[.]com; observed in Cobalt Strike activity
     
  • IP: 83.171.237[.]173
    Organization: Droptop GmbH
    Resolutions: 15
    Geolocation: Germany
    Activity: Categorized as malicious by antivirus software; hosted multiple suspicious domains and multiple malicious files were observed downloaded from this IP address; observed in Cobalt Strike and activity
     
  • Domain: theyardservice[.]com
    Host IP: 83.171.237[.]173 (Germany)
    Created Date: January 27, 2010
    Owner: Withheld for Privacy Purposes
    Activity: Threat actor controlled domain according to the trusted third party; categorized as suspicious by antivirus software; observed in Cobalt Strike activity

 

Table 1 provides a summary of the MITRE ATT&CK techniques observed.

Table 1: MITRE ATT&CK techniques observed

Technique Title

Technique ID

Process Injection: Dynamic-link Library Injection

T1055.001

Ingress Tool Transfer

T1105

User Execution: Malicious Link

T1204.001

Phishing: Spearphishing Link

T1566.002

Mitigations

CISA and FBI urge CI owners and operators to apply the following mitigations.

  • Implement multi-factor authentication (MFA) for every account. While privileged accounts and remote access systems are critical, it is also important to ensure full coverage across SaaS solutions. Enabling MFA for corporate communications platforms (as with all other accounts) provides vital defense against these types of attacks and, in many cases, can prevent them.
  • Keep all software up to date. The most effective cybersecurity programs quickly update all of their software as soon as patches are available. If your organization is unable to update all software shortly after a patch is released, prioritize implementing patches for CVEs that are already known to be exploited.
  • Implement endpoint and detection response (EDR) tools. EDR allows a high degree of visibility into the security status of endpoints and is can be an effective tool against threat actors.
    Note: Organizations using Microsoft Defender for Endpoint or Microsoft 365 Defense should refer to Microsoft: Use attack surface reduction rules to prevent malware infection for more information on hardening the enterprise attack surface.
  • Implement centralized log management for host monitoring. A centralized logging application allows technicians to look out for anomalous activity in the network environment, such as new applications running on hosts, out-of-place communication between devices, or unaccountable login failures on machines. It also aids in troubleshooting applications or equipment in the event of a fault. CISA and the FBI recommend that organizations:
    • Forward logs from local hosts to a centralized log management server—often referred to as a security information and event management (SIEM) tool.
    • Ensure logs are searchable. The ability to search, analyze, and visualize communications will help analysts diagnose issues and may lead to detection of anomalous activity.
    • Correlate logs from both network and host security devices. By reviewing logs from multiple sources, an organization can better triage an individual event and determine its impact to the organization as a whole.
    • Review both centralized and local log management policies to maximize efficiency and retain historical data. Organizations should retain critical logs for a minimum of 30 days.
  • Deploy signatures to detect and/or block inbound connection from Cobalt Strike servers and other post-exploitation tools.
  • Implement unauthorized execution prevention by disabling macro scripts from Microsoft Office files transmitted via email. Consider using Office Viewer software to open Microsoft Office files transmitted via email instead of full Microsoft Office suite applications.
  • Configure and maintain user and administrative accounts using a strong account management policy.
    • Use administrative accounts on dedicated administration workstations.
    • Limit access to and use of administrative accounts.
    • Use strong passwords. For more information on strong passwords, refer to CISA Tip: Choosing and Protecting Passwords and National Institute of Standards (NIST) SP 800-63: Digital Identity Guidelines: Authentication and Lifecycle Management.
    • Remove default accounts if unneeded. Change the password of default accounts that are needed.
    • Disable all unused accounts.
  • Implement a user training program and simulated attacks for spearphishing to discourage users from visiting malicious websites or opening malicious attachments and re-enforce the appropriate user responses to spearphishing emails.

RESOURCES

Contact Information

To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. 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 request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

This document is marked TLP:WHITE. Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol, see http://www.us-cert.gov/tlp/.

 

References

Revisions

  • Initial version: May 28, 2021

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

SecretManagement Module v1.1.0 preview update

This post was originally published on this site

Microsoft.PowerShell.SecretManagement 1.1.0-preview

The next 1.1.0 version of SecretManagement has a number of minor fixes, but also two significant changes, one of which is a potentially breaking change for extension authors.
For more information on the changes in this release, see the CHANGELOG document.
This blog discusses the primary changes, why one is potentially breaking, and is especially relevant for extension vault owners who may want to test their vault and make any changes while these updates are in a preview state.

SecretManagement extension vault modules hosting change

SecretManagement extension vaults are PowerShell modules that conform to a special format.
Currently, when SecretManagement loads an extension vault module for use, it loads the module into the current user session.
However, this method of hosting extension vault modules prevented SecretManagement from running in ConstrainedLanguage (CL) mode.
To fix this problem, v1.1.0 of SecretManagement now hosts extension vaults in a separate runspace session.
Changing how the extension module is hosted, has the potential to break existing extension vaults.

What are the effects of the hosting change?

This change mostly affects extension vault authors because they can no longer assume their loaded vault module has access to current user session state.
Generally, extension vaults should never rely on shared user session state.
But if an extension did have this dependency, it would no longer work with this next version of SecretManagement.
We tested some extension vault modules on the PowerShellGallery, but found only one module that was affected by this change (SecretManagement.KeePass).

SecretManagement.KeePass extension vault

The SecretManagement.KeePass extension vault currently relies on its module being loaded in the user session in order to support its vault unlock operation via the Unlock-KeePassSecretVault command.
With the new SecretManagement version, the Unlock-KeePassSecretVault cmdlet is no longer effective, and the user is always prompted for a password when required by the vault.
This can be problematic for scripts being run unattended that do not support user interaction.

The KeePass vault needed to use this user shared state approach due to a deficiency in SecretManagement.
SecretManagement did not support a vault unlock operation, and required vaults that needed it to implement their own.
So one of the changes in this release is to add a new extension vault function, Unlock-SecretVault, that allows extension vaults to provide this functionality directly through SecretManagement.
With this new function, the KeePass vault no longer needs to leverage shared state with the user session.

New Unlock-SecretVault command

SecretManagement now supports a new Unlock-SecretVault command.
Extension vaults that require unlocking can optionally support this by implementing the Unlock-SecretVault function in their extension.
SecretManagement.KeePass extension vault module will be updated to use this new function, mitigating the problem.
For more information see SecretManagement Readme and Design documentation.

Other differences you may notice

Since the extension vaults are no longer loaded in the user session, you will no longer see them listed when you run the Get-Module command, which lists the currently loaded modules in your session.
This is arguably a good thing, since users generally don’t want or need to know about extension vault modules, and don’t need to see them in their current session.
Seeing extension vault modules unexpectedly loaded in their sessions may be confusing to users.

Some extension vault modules, such as Microsoft.PowerShell.SecretStore and SecretManagement.KeePass, include additional commands for the user.
The Microsoft.PowerShell.SecretStore vault provides additional commands for configuring the vault.
The SecretManagement.KeepPass vault provides additional commands for unlocking and registering the vault.
These commands will continue to work.
When these commands are run, the extension vault module will be visible from Get-Module because the commands are run in the current user session.
But that is the only time the extension vault modules will be loaded in the user session.

What is a runspace?

A PowerShell runspace encompasses the session context in which PowerShell scripts run, and can be thought of as an individual PowerShell session.
The PowerShell command shell usually has just a single session, but can support any number of sessions via multiple runspaces.
The runspace isolates multiple running scripts from each other within a single process.

What is CL mode?

Constrained Language is a PowerShell language mode that restricts language elements which can be used to invoke arbitrary APIs.
It is commonly used within a system wide application control policy, such as Windows AppLocker or Windows Defender Application Control, that restricts what applications are available and what scripts are trusted on the system.
Untrusted scripts run in ConstrainedLanguage while trusted scripts run in FullLanguage mode.

Feedback and Support

Community feedback has been essential to the iterative development of these modules.
Thank you to everyone who has contributed issues, and feedback thus far!
To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository.
For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

The post SecretManagement Module v1.1.0 preview update appeared first on PowerShell Team.

Announcing PlatyPS 2.0.0-Preview1

This post was originally published on this site

PlatyPS is the primary tool for creating the PowerShell help displayed using Get-Help.

What is PlatyPS

PowerShell external help files have been authored by hand or using complex tool chains and stored as
MAML XML for use as console help.
MAML is cumbersome to edit by
hand, and common tools and editors don’t support it for complex scenarios like they do with
markdown. Markdown is adopted widely by
Open Source, supported by many editors including
Visual Studio Code, and with minimal rules, easier to author.
PlatyPS is provided as a solution to allow documenting PowerShell help in any editor or tool
that supports markdown.

PlatyPS handles PowerShell documentation for complex scenarios (e.g. very large, closed source,
and/or C#/binary modules) where it may be desirable to have documentation abstracted away from the
codebase. PlatyPS does not need source access to generate documentation. PlatyPS solves this
scenario today at Microsoft by delivering
updatable help
files for PowerShell, SCCM, Windows, and other supported modules. Module authors may also use
PlatyPS to create the help that ships with their modules.

Announcing PlatyPS 2.0-Preview1

We are pleased to announce the release of PlatyPS 2.0.0-Preview1.

Our main goal for the 2.0.0 release is to maintain compatibility while fixing long standing issues.
We are re-writing PlatyPS in C# to leverage the existing markdown C# library allowing us to
address many of the open issues and make schema improvements recommended by the community. The main
functionality of PlatyPS remains unchanged except for community suggested bug fixes and
enhancements. We do expect a few necessary breaking changes in future previews.

In this Preview release, we focused on:

  • re-write in C# leveraging Markdig for parsing markdown.
  • updated New-MarkdownHelp
  • updated Get-MarkdownMetadata

Future preview releases will include more performance improvements and cmdlet updates.

What’s supported

PlatyPS 2.0.0-Preview1 is currently available for download from the PowerShell Gallery.

Supported PowerShell versions for PlatyPS 2.0.0:

  • Windows PowerShell 5.1+
  • PowerShell 7.0+

Installing PlatyPS

To begin working with PlatyPS 2.0 Preview1, download and install the PlatyPS module from PSGallery.

Install-Module PlatyPS -AllowPrerelease

Markdown Schema Updates

Markdown is designed to be human-readable, without rendering. This makes writing and editing easy
and efficient. Many editors support markdown including Visual Studio Code. PlatyPS expects
markdown to be authored in a particular way. We have defined a schema to determine how parameters
are described, where scripts examples are shown, and so on.

The schema closely resembles the existing output format of the Get-Help cmdlet in PowerShell. If
you break the schema in your markdown, you will receive error messages.

For more information about the planned changes, see the
PlatyPS Design Specification.
Note, this is a draft specification subject to change.

Documentation to get started

For information about PlatyPS including cmdlet reference, see PlatypS

For additional information and examples of working with PlatyPS, see
Create XML-based help using PlatyPS.

Call to action

Our goal is to make it easier to update and maintain module/cmdlet help files. We value your ideas
and feedback. Stop by our GitHub repository and let us know of any issues or features you would like
added.

For more information about PlatyPS issues and features, see:
PlatyPS on GitHub

Jason Helmick
Program Manager, PowerShell

The post Announcing PlatyPS 2.0.0-Preview1 appeared first on PowerShell Team.

Announcing PSDesiredStateConfiguration on PowerShell Gallery

This post was originally published on this site

Continuing our investment in DSC, we are pleased to announce the release of
PSDesiredStateConfiguration 2.0.5 for DSC as a separate module on PowerShell Gallery. This is in
preparation for publishing previews of the 3.0 version of this module which will have new
capabilities, but also some breaking changes.

DSC is an important platform in configuration management, and we value the feedback we are
receiving from the community. To further the goals of DSC, PSDesiredStateConfiguration module
will no longer be included in the PowerShell package beginning in a future release of PowerShell 7.2
preview. Separating DSC into its own module allows us to invest and develop DSC independent of
PowerShell and reduces the size of the PowerShell package. Users of DSC will enjoy the benefit of
upgrading DSC without the need to upgrade PowerShell, accelerating time to deployment of new DSC
features.

Customers impacted by this change and wishing to remain on DSC v2 can download
PSDesiredStateConfiguration 2.0.5 for Windows PowerShell from the PowerShell Gallery. Customers
working with non-Windows environments can expect cross-platform features in DSC v3. For more
information about DSC and the teams on-going investments for 2021, see
PowerShell Team 2021 Investments

To download PSDesiredStateConfiguration from the PowerShell Gallery:

To install PSDesiredStateConfiguration:

Install-Module -Name PSDesiredStateConfiguration -Repository PSGallery -MaximumVersion 2.99

Warning


Be sure to include the parameter MaximumVersion or you
will receive the latest version of PSDesireStateConfiguration which contains significant
differences.

For more information about DSC v3 and the teams investments for 2021, see
PowerShell Team 2021 Investments

The post Announcing PSDesiredStateConfiguration on PowerShell Gallery appeared first on PowerShell Team.

AA21-131A: DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks

This post was originally published on this site

Original release date: May 11, 2021

Summary

This Advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of a ransomware attack affecting a critical infrastructure (CI) entity—a pipeline company—in the United States. Malicious cyber actors deployed DarkSide ransomware against the pipeline company’s information technology (IT) network.[1] At this time, there is no indication that the entity’s operational technology (OT) networks have been directly affected by the ransomware.

CISA and FBI urge CI asset owners and operators to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this Joint Cybersecurity Advisory, including implementing robust network segmentation between IT and OT networks; regularly testing manual controls; and ensuring that backups are implemented, regularly tested, and isolated from network connections. These mitigations will help CI owners and operators improve their entity’s functional resilience by reducing their vulnerability to ransomware and the risk of severe business degradation if impacted by ransomware.

Click here for a PDF version of this report.

Technical Details

Note: the analysis in this Joint Cybersecurity Advisory is ongoing, and the information provided should not be considered comprehensive. CISA and FBI will update this advisory as new information is available.

After gaining initial access to the pipeline company’s network, DarkSide actors deployed DarkSide ransomware against the company’s IT network. In response to the cyberattack, the company has reported that they proactively disconnected certain OT systems to ensure the systems’ safety.[2] At this time, there are no indications that the threat actor moved laterally to OT systems.

DarkSide is ransomware-as-a-service (RaaS)—the developers of the ransomware receive a share of the proceeds from the cybercriminal actors who deploy it, known as “affiliates.” According to open-source reporting, since August 2020, DarkSide actors have been targeting multiple large, high-revenue organizations, resulting in the encryption and theft of sensitive data. The DarkSide group has publicly stated that they prefer to target organizations that can afford to pay large ransoms instead of hospitals, schools, non-profits, and governments.[3],[4]

According to open-source reporting, DarkSide actors have previously been observed gaining initial access through phishing and exploiting remotely accessible accounts and systems and Virtual Desktop Infrastructure (VDI) (Phishing [T1566], Exploit Public-Facing Application [T1190], External Remote Services [T1133]).[5],[6] DarkSide actors have also been observed using Remote Desktop Protocol (RDP) to maintain Persistence [TA0003].[7]

After gaining access, DarkSide actors deploy DarkSide ransomware to encrypt and steal sensitive data (Data Encrypted for Impact [T1486]). The actors then threaten to publicly release the data if the ransom is not paid.[8],[9] The DarkSide ransomware uses Salsa20 and RSA encryption.[10]

DarkSide actors primarily use The Onion Router (TOR) for Command and Control (C2) [TA0011] (Proxy: Multi-hop Proxy [1090.003]).[11],[12] The actors have also been observed using Cobalt Strike for C2.[13]

Mitigations

CISA and FBI urge CI owners and operators to apply the following mitigations to reduce the risk of compromise by ransomware attacks.

  • Require multi-factor authentication for remote access to OT and IT networks.
  • Enable strong spam filters to prevent phishing emails from reaching end users. Filter emails containing executable files from reaching end users.
  • Implement a user training program and simulated attacks for spearphishing to discourage users from visiting malicious websites or opening malicious attachments and re-enforce the appropriate user responses to spearphishing emails.
  • Filter network traffic to prohibit ingress and egress communications with known malicious IP addresses. Prevent users from accessing malicious websites by implementing URL blocklists and/or allowlists.
  • Update software, including operating systems, applications, and firmware on IT network assets, in a timely manner. Consider using a centralized patch management system; use a risk-based assessment strategy to determine which OT network assets and zones should participate in the patch management program.
  • Limit access to resources over networks, especially by restricting RDP. After assessing risks, if RDP is deemed operationally necessary, restrict the originating sources and require multi-factor authentication.
  • Set antivirus/antimalware programs to conduct regular scans of IT network assets using up-to-date signatures. Use a risk-based asset inventory strategy to determine how OT network assets are identified and evaluated for the presence of malware.
  • Implement unauthorized execution prevention by
    • Disabling macro scripts from Microsoft Office files transmitted via email. Consider using Office Viewer software to open Microsoft Office files transmitted via email instead of full Microsoft Office suite applications.
    • Implementing application allowlisting, which only allows systems to execute programs known and permitted by security policy. Implement software restriction policies (SRPs) or other controls to prevent programs from executing from common ransomware locations, such as temporary folders supporting popular internet browsers or compression/decompression programs, including the AppData/LocalAppData folder.
    • Monitor and/or block inbound connections from Tor exit nodes and other anonymization services to IP addresses and ports for which external connections are not expected (i.e., other than VPN gateways, mail ports, web ports). For more guidance, refer to Joint Cybersecurity Advisory AA20-183A: Defending Against Malicious Cyber Activity Originating from Tor.
    • Deploy signatures to detect and/or block inbound connection from Cobalt Strike servers and other post exploitation tools.

CISA and FBI urge CI owners and operators to apply the following mitigations now to reduce the risk of severe business or functional degradation should their CI entity fall victim to a ransomware attack in the future.

  • Implement and ensure robust network segmentation between IT and OT networks to limit the ability of adversaries to pivot to the OT network even if the IT network is compromised. Define a demilitarized zone that eliminates unregulated communication between the IT and OT networks.
  • Organize OT assets into logical zones by taking into account criticality, consequence, and operational necessity. Define acceptable communication conduits between the zones and deploy security controls to filter network traffic and monitor communications between zones. Prohibit industrial control system (ICS) protocols from traversing the IT network.
  • Identify OT and IT network inter-dependencies and develop workarounds or manual controls to ensure ICS networks can be isolated if the connections create risk to the safe and reliable operation of OT processes. Regularly test contingency plans such as manual controls so that safety critical functions can be maintained during a cyber incident. Ensure that the OT network can operate at necessary capacity even if the IT network is compromised. 
  • Regularly test manual controls so that critical functions can be kept running if ICS or OT networks need to be taken offline.
  • Implement regular data backup procedures on both the IT and OT networks. Backup procedures should be conducted on a frequent, regular basis. The data backup procedures should also address the following best practices:
    • Ensure that backups are regularly tested.
    • Store your backups separately. Backups should be isolated from network connections that could enable the spread of ransomware. It is important that backups be maintained offline as many ransomware variants attempt to find and encrypt or delete accessible backups. Maintaining current backups offline is critical because if your network data is encrypted with ransomware, your organization can restore systems to its previous state. Best practice is to store your backups on a separate device that cannot be accessed from a network, such as on an external hard drive. (See the Software Engineering Institute’s page on ransomware).
    • Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt. This entails maintaining image “templates” that include a preconfigured operating system (OS) and associated software applications that can be quickly deployed to rebuild a system, such as a virtual machine or server.
    • Retain backup hardware to rebuild systems in the event rebuilding the primary system is not preferred. Hardware that is newer or older than the primary system can present installation or compatibility hurdles when rebuilding from images.
    • Store source code or executables. It is more efficient to rebuild from system images, but some images will not install on different hardware or platforms correctly; having separate access to needed software will help in these cases.
  • Ensure user and process accounts are limited through account use policies, user account control, and privileged account management. Organize access rights based on the principles of least privilege and separation of duties.

If your organization is impacted by a ransomware incident, CISA and FBI 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, whether wired or wireless.  
  • 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 shared 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. (See Before You Connect a New Computer to the Internet for tips on how to make a computer more secure before you reconnect it to a network.)
  • 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.
  • Refer to Joint Cybersecurity Advisory: AA20-245A: Technical Approaches to Uncovering and Remediating Malicious Activity for more best practices on incident response.

Note: CISA and the FBI 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 may fund illicit activities. Paying the ransom also does not guarantee that a victim’s files will be recovered. CISA and FBI urge you to report ransomware incidents to your local FBI field office.

CISA offers a range of no-cost cyber hygiene services to help CI organizations assess, identify and reduce their exposure to threats, including ransomware. By requesting these services, organizations of any size could find ways to reduce their risk and mitigate attack vectors.

Resources

Contact Information

Victims of ransomware should report it immediately to CISA at https://us-cert.cisa.gov/report, a local FBI Field Office, or U.S. Secret Service Field Office. To report suspicious or criminal activity related to information found in this Joint Cybersecurity Advisory, contact your local FBI field office at www.fbi.gov/contact-us/field, or the FBI’s 24/7 Cyber Watch (CyWatch) at (855) 292-3937 or by e-mail at CyWatch@fbi.gov. 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 request incident response resources or technical assistance related to these threats, contact CISA at CISAServiceDesk@cisa.dhs.gov.

References

Revisions

  • May 11, 2021: Initial Version

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

Announcing PowerShell Crescendo Preview.2

This post was originally published on this site

We are pleased to announce the second preview of PowerShell Crescendo, a framework to rapidly
develop PowerShell cmdlets for native commands, regardless of platform.

The updated preview releases are now available for download on the PowerShell Gallery:

To install Microsoft.PowerShell.Crescendo:

Install-Module Microsoft.PowerShell.Crescendo -AllowPrerelease

For more information on Microsoft.PowerShell.Crescendo, check out these previous blog posts:

Crescendo Preview 2 Updates

This update to Crescendo adds elevation support for native commands, and generation of a module
manifest when exporting a Crescendo module. Read the full list of changes below:

  • Added support for native command elevation on Windows and Linux platforms. (Issue #50)
  • Export-CrescendoModule now exports a module manifest (psd1) along with the module file (psm1). (Issue #51)
  • Added support for generating aliases for Crescendo cmdlets (Issue #52)
  • Added support for SupportsShouldProcess. Thanks jdhitsolutions! (Issue #59)

Native Command elevation

Native commands may require administrative elevation to perform the requested operation. The
Crescendo schema has been extended to support elevation on Windows and Linux/macOS platforms. The schema
supports the new keyword Elevation that has two properties Command and Arguments.

  • Command: Defines the elevation mechanism to be used to elevate the native command. The function
    Invoke-WindowsNativeAppWithElevation has been included to aid with elevation on Windows. sudo
    has been tested as well.
  • Arguments: These are the parameters to be used in conjunction with the elevation command. This can
    be a collection of parameters.

    • OriginalName: This is the parameter to be used with the elevation command.
    • DefaultValue: The default parameter value.

Windows Native Command Elevation

Elevation on Windows is supported using the built-in function
Invoke-WindowsNativeAppWithElevation. Invoke-WindowsNativeAppWithElevation uses Start-Process
with a PSCredential to invoke the native command and captures the output and errors of the native
command which are returned to the user. This function is inserted into the Crescendo module you
export. In the example below, the PowerShell cmdlet Get-Credential will prompt for credentials
necessary to elevate the native command when the exported Crescendo function is executed.

"Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },

In automation scenarios that require elevation without user interaction, Crescendo supports
retrieving credentials from secured vaults. In the example below, credentials for elevation are
retrieved from SecretManagement and SecretStore.

For more information about storing and managing secrets, see [SecretManagement Announcement](https://devblogs.microsoft.com/powershell/secretmanagement-and-secretstore-are-generally-available/

"Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-secret admin)"
            }
        ]
    },

Elevation can be defined for each cmdlet. When authoring a Crescendo json configuration, include
the elevation definition before the parameters are defined. In the example below, the native command
netsh.exe requires elevation to enable and disable the Windows Firewall.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Set",
    "Noun": "WinFirewall",
    "Platform": ["Windows"],
    "OriginalCommandElements": ["advfirewall", "set", "allprofiles", "state"],
    "OriginalName": "$env:Windir/system32/netsh.exe",
    "Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },
    "DefaultParameterSetName": "Enable",
    "Parameters": [
        {
            "OriginalName": "on",
            "Name": "On",
            "ParameterType": "switch",
            "ParameterSetName": ["Enable"]
        },
        {
            "OriginalName": "off",
            "Name": "Off",
            "ParameterType": "switch",
            "ParameterSetName": ["Disable"]
        }
    ]
}

Linux Native Command Elevation

Native command elevation for Linux and macOS is handled through the command sudo. To enable
elevation for Crescendo, include sudo as the Command value. In the example below, when the
function Get-TimeServer is executed, the user is prompted for the sudo password. The native
command is elevated with sudo privileges. In automation scenarios that require elevation without
user interaction, configure the sudoers file.

{
    "$schema": "../src/Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Get",
    "Noun": "TimeServer",
    "Elevation": {
        "Command": "sudo"
    },
    "OriginalCommandElements": ["-getnetworktimeserver"],
    "OriginalName": "/usr/sbin/systemsetup",
    "Platform": ["MacOS"],
    "OutputHandlers": [
        {
            "ParameterSetName": "Default",
            "Handler": "$args|%{[pscustomobject]@{ TimeServer = $_.Split(':')[1].Trim()}}"
        }
    ]
}

SupportsShouldProcess

Cmdlets that cause change to the system, such as files and service configurations, create a risk
that could negatively impact operations. To help mitigate risk, cmdlets support common parameters
-WhatIf and -Confirm. These parameters provide greater detail about the target of each
change, and provides a confirmation mechanism allowing the user to approve each change. Crescendo
supports this functionality when wrapping native commands though the schema keyword
SupportsShouldProcess.

In the example below, The keyword SupportsShouldProcess accepts a boolean to enable the common
parameters -WhatIf and -Confirm.

{
    "$schema": "../src/Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Remove",
    "Noun": "DockerImage",
    "OriginalName": "docker",
    "SupportsShouldProcess": true,
    "OriginalCommandElements": [
        "image",
        "rm"
    ],
    "Parameters": [
        {
            "Name": "ID",
            "OriginalName": "",
            "Mandatory": true,
            "ValueFromPipelineByPropertyName": true
        }
    ]
}

Executing Remove-DockerImage with the -WhatIf parameter supported by SupportsShouldProcess.

Get-DockerImage | Where-Object {$_.id -match "d70eaf7277ea"} | Remove-DockerImage -WhatIf

When SupportsShouldProcess is set True, the following expected output will result.

What if: Performing the operation "Remove-DockerImage" on target "docker image rm d70eaf7277ea".

Aliases

Aliases for Crecendo wrapped native commands are now supported in the Crescendo schema with the
keyword Aliases. In the snippet below, the cmdlet definition Set-WinFirewall includes the alias
definition SFW. When exported, the Crescendo created module will include the Set-WinFirewall
function and SFW alias.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Verb": "Set",
    "Noun": "WinFirewall",
    "Platform": ["Windows"],
    "OriginalCommandElements": ["advfirewall", "set", "allprofiles", "state"],
    "OriginalName": "$env:Windir/system32/netsh.exe",
    "Aliases": ["SFW"],
    "Elevation": {
        "Command": "Invoke-WindowsNativeAppWithElevation",
        "Arguments": [
            {
                "OriginalName" : "-Credential",
                "DefaultValue": "(get-credential)"
            }
        ]
    },

Future plans

Next/Future plans for preview.3 will be based on feedback and include a few items under investigation:

  • Improved OutputHandler support for building objects from native command string output.
  • Support for multiple cmdlet definitions in a single json configuration.

Our goal is to make it easier to convert your native commands to PowerShell cmdlets and receive the
benefits that PowerShell provides. We value your ideas and feedback and hope you will give Crescendo
a try, then stop by our GitHub repository and let us know of any issues or features you would like
added.

For more information about PowerShell Crescendo issues and features, see:
Crescendo on GitHub

Jason Helmick

Program Manager, PowerShell

The post Announcing PowerShell Crescendo Preview.2 appeared first on PowerShell Team.