Skyline Advisor Pro Proactive Findings – March Edition

This post was originally published on this site

Tweet VMware Skyline 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 March, we released 23 new Findings. Of these, there are 14 Findings based on trending issues, 5 … Continued

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

New – Cloud NGFW for AWS

This post was originally published on this site

In 2018 I wrote about AWS Firewall Manager (Central Management for Your Web Application Portfolio) and showed you how you could host multiple applications, perhaps spanning multiple AWS accounts and regions, while maintaining centralized control over your organization’s security settings and profile. In the same way that Amazon Relational Database Service (RDS) supports multiple database engines, Firewall Manager supports multiple types of firewalls: AWS Web Application Firewall, AWS Shield Advanced, VPC security groups, AWS Network Firewall, and Amazon Route 53 DNS Resolver DNS Firewall.

Cloud NGFW for AWS
Today we are introducing support for Palo Alto Networks Cloud NGFW in Firewall Manager. You can now use Firewall Manager to centrally provision & manage your Cloud next-generation firewall resources (also called NGFWs) and monitor for non-compliant configurations, all across multiple accounts and Virtual Private Clouds (VPCs). You get the best-in-class security features offered by Cloud NGFW as a managed service wrapped inside a native AWS experience, with no hardware hassles, no software upgrades, and pay-as-you-go pricing. You can focus on keeping your organization safe and secure, even as you add, change, and remove AWS resources.

Palo Alto Networks pioneered the concept of deep packet inspection in their NGFWs. Cloud NGFW for AWS can decrypt network packets, look inside, and then identify applications using signatures, protocol decoding, behavioral analysis, and heuristics. This gives you the ability to implement fine-grained, application-centric security management that is more effective than simpler models that are based solely on ports, protocols, and IP addresses. Using Advanced URL Filtering, you can create rules that take advantage of curated lists of sites (known as feeds) that distribute viruses, spyware, and other types of malware, and you have many other options for identifying and handling desirable and undesirable network traffic. Finally, Threat Prevention stops known vulnerability exploits, malware, and command-and-control communication.

The integration lets you choose the deployment model that works best with your network architecture:

Centralized – One firewall running in a centralized “inspection” VPC.

Distributed – Multiple firewalls, generally one for each VPC within the scope managed by Cloud NGFW for AWS.

Cloud NGFW protects outbound, inbound, and VPC-to-VPC traffic. We are launching with support for all traffic directions.

AWS Inside
In addition to centralized provisioning and management via Firewall Manager, Cloud NGFW for AWS makes use of many other parts of AWS. For example:

AWS Marketplace – The product is available in SaaS form on AWS Marketplace with pricing based on hours of firewall usage, traffic processed, and security features used. Cloud NGFW for AWS is deployed on a highly available compute cluster that scales up and down with traffic.

AWS Organizations – To list and identify new and existing AWS accounts and to drive consistent, automated cross-account deployment.

AWS Identity and Access Management (IAM) – To create cross-account roles for Cloud NGFW to access log destinations and certificates in AWS Secrets Manager.

AWS Config – To capture changes to AWS resources such as VPCs, VPC route configurations, and firewalls.

AWS CloudFormation – To run a StackSet that onboards each new AWS account by creating the IAM roles.

Amazon S3, Amazon CloudWatch, Amazon Kinesis – Destinations for log files and records.

Gateway Load Balancer – To provide resiliency, scale, and availability for the NGFWs.

AWS Secrets Manager – To store SSL certificates in support of deep packet inspection.

Cloud NGFW for AWS Concepts
Before we dive in and set up a firewall, let’s review a few important concepts:

Tenant – An installation of Cloud NGFW for AWS associated with an AWS customer account. Each purchase from AWS Marketplace creates a new tenant.

NGFW – A firewall resource that spans multiple AWS Availability Zones and is dedicated to a single VPC.

Rulestack – A set of rules that defines the access controls and threat protections for one or more NGFWs.

Global Rulestack – Represented by an FMS policy, contains rules that apply to all of the NGFWs in an AWS Organization.

Getting Started with Cloud NGFW for AWS
Instead of my usual step-by-step walk-through, I am going to show you the highlights of the purchasing and setup process. For a complete guide, read Getting Started with Cloud NGFW for AWS.

I start by visiting the Cloud NGFW Pay-As-You-Go listing in AWS Marketplace. I review the pricing and terms, click Continue to Subscribe, and proceed through the subscription process.

After I subscribe, Cloud NGFW for AWS will send me an email with temporary credentials for the Cloud NGFW console. I use the credential to log in, and then I replace the temporary password with a long-term one:

I click Add AWS Account and enter my AWS account Id. The console will show my account and any others that I subsequently add:

The NGFW console redirects me to the AWS CloudFormation console and prompts me to create a stack. This stack sets up cross-account IAM roles, designates (but does not create) logging destinations, and lets Cloud NGFW access certificates in Secrets Manager for packet decryption.

From here, I proceed to the AWS Firewall Manager console and click Settings. I can see that my cloud NGFW tenant is ready to be associated with my account. I select the radio button next to the name of the firewall, in this case “Palo Alto Networks Cloud NGFW” and then click the Associate button. Note that the subscription status will change to Active in a few minutes.

Screenshot showing the account association process

Once the NGFW tenant is associated with my account I return to the AWS Firewall Manager console and click Security policies to proceed. There are no policies yet, and I click Create policy to make one:

I select Palo Alto Networks Cloud NGFW, choose the Distributed model, pick an AWS region, and click Next to proceed (this model will create a Cloud NGFW endpoint in each in-scope VPC):

I enter a name for my policy (Distributed-1), and select one of the Cloud NGFW firewall policies that are available to my account. I can also click Create firewall policy to navigate to the Palo Alto Networks console and step through the process of creating a new policy. Today I select grs-1:

I have many choices and options when it comes to logging. Each of the three types of logs (Traffic, Decryption, and Threat) can be routed to an S3 bucket, a CloudWatch log group, or a Kinesis Firehose delivery stream. I choose an S3 bucket and click Next to proceed:

A screenshot showing the choices for logging.

Now I choose the Availability Zones where I need endpoints. I have the option to select by name or by ID, and I can optionally designate a CIDR block within each AZ that will be used for the subnets:

The next step is to choose the scope: the set of accounts and resources that are covered by this policy. As I noted earlier, this feature works hand-in-hand with AWS Organizations and gives me multiple options to choose from:

The CloudFormation template linked above is used to create an essential IAM role in each member account. When I run it, I will need to supply values for the CloudNGFW Account ID and ExternalId parameters, both of which are available from within the Palo Alto Networks console. On the next page I can tag my newly created policy:

On the final page I review and confirm all of my choices, and click Create policy to do just that:

My policy is created right away, and it will start to list the in-scope accounts within minutes. Under the hood, AWS Firewall Manager calls Cloud NGFW APIs to create NGFWs for the VPCs in my in-scope accounts, and the global rules are automatically associated with the created NGFWs. When the NGFWs are ready to process traffic, AWS Firewall Manager creates the NGFW endpoints in the subnets.

As new AWS accounts join my organization, AWS Firewall Manager automatically ensures they are compliant by creating new NGFWs as needed.

Next I review the Cloud NGFW threat logs to see what threats are being blocked by Cloud NGFW. In this example Cloud NGFW protected my VPC against SIPVicious scanning activity:

Screenshot showing the threat log detecting SIPVicious activity

And in this example, Cloud NGFW protected my VPC against a malware download:

a screenshot showing the threat log of malware detection

Things to Know
Both AWS Firewall Manager and Cloud NGFW are regional services and my AWS Firewall Manager policy is therefore regional. Cloud NGFW is currently available in the US East (N. Virginia) and US West (N. Califormia) Regions, with plans to expand in the near future.

Jeff;

More Fake/Typosquatting Twitter Accounts Asking for Ukraine Crytocurrency Donations, (Tue, Mar 29th)

This post was originally published on this site

After publishing the post about look-alike Twitter accounts impersonating Olena Zlenska [1], Jesse La Grew, one of our SANS.edu undergraduate interns, wrote scripts to look for more accounts advertising the same cryptocurrency addresses or advertising similar cryptocurrency donations requests. We assume that these requests are fake because they do not advertise addresses used by other legit charities, and they do attempt to impersonate personalities associated with Ukraine's government. The name "Olena Zelenska" may not be unique. We did not flag any accounts using this name as long as they didn't advertise the cryptocurrency addresses used by the original fake account.

XLSB Files: Because Binary is Stealthier Than XML, (Fri, Mar 25th)

This post was originally published on this site

In one of his last diaries[1], Brad mentioned an Excel sheet named with a .xlsb extension. Now, it was my turn to find one… What's the magic behind this file extension? "XLS" means that we are facing an Excel sheet and "B" means that we have a binary workbook file. Within the current Microsoft office files format, data are stored in XML. In this case, they are stored in binary. For Microsoft Office, to open a normal or binary file is the same… but for an attacker, the plus-value is the increased level of obfuscation! Indeed, it's more difficult to extract interesting information like… strings!

AWS Lambda Now Supports Up to 10 GB Ephemeral Storage

This post was originally published on this site

Serverless applications are event-driven, using ephemeral compute functions ranging from web APIs, mobile backends, and streaming analytics to data processing stages in machine learning (ML) and high-performance applications. While AWS Lambda includes a 512 MB temporary file system (/tmp) for your code, this is an ephemeral scratch resource not intended for durable storage such as Amazon Elastic File System (Amazon EFS).

However, extract, transform, and load (ETL) jobs and content generation workflows such as creating PDF files or media transcoding require fast, scalable local storage to process large amounts of data quickly. Data-intensive applications require large amounts of temporary data specific to the invocation or cached data that can be reused for all invocation in the same execution environment in a highly performant manner. With the previous limit of 512 MB, customers had to selectively load data from Amazon Simple Storage Service (Amazon S3) and Amazon EFS, or increase the allocated function memory and thus increase their cost, just to handle large objects downloaded from Amazon S3. Since customers could not cache larger data locally in the Lambda execution environment, every function invoke had to read data in parallel, which made scaling out harder for customers.

Today, we are announcing that AWS Lambda now allows you to configure ephemeral storage (/tmp) between 512 MB and 10,240 MB. You can now control the amount of ephemeral storage a function gets for reading or writing data, allowing you to use AWS Lambda for ETL jobs, ML inference, or other data-intensive workloads.

With increased AWS Lambda ephemeral storage, you get access to a secure, low-latency ephemeral file system up to 10 GB. You can continue to use up to 512 MB for free and are charged for the amount of storage you configure over the free limit for the duration of invokes.

Setting Larger Ephemeral Storage for Your Lambda Function
To configure your Lambda function with larger ephemeral storage, choose the Configuration tab under the General Configuration section in the AWS Lambda Console. You will see a new configuration for Ephemeral storage setting at 512MB by default.

When you click the Edit button, you can configure the ephemeral storage from 512 MB to 10,240 MB in 1 MB increments for your Lambda functions.

With AWS Command Line Interface (AWS CLI), you can update your desired size of ephemeral storage using theupdate-function-configuration command.

$ aws lambda update-function-configuration --function-name PDFGenerator 
              --ephemeral-storage '{"Size": 10240}'

You can configure ephemeral storage using Lambda API via AWS SDK, AWS Cloud Development Kit (AWS CDK), AWS Serverless Application Model (AWS SAM), and AWS CloudFormation. To learn more, see Configuring function options in the AWS Documentation.

As a review, AWS Lambda provides a comprehensive range of storage options. To learn more, see a great blog post, Choosing between AWS Lambda data storage options in web apps, written by my colleague James Beswick. I want to quote the table to show the differences between these options and common use-cases to help you choose the right one for your own applications.

Features Ephemeral Storage (/tmp) Lambda Layers Amazon EFS Amazon S3
Maximum size 10,240 MB 50 MB (direct upload) Elastic Elastic
Persistence Ephemeral Durable Durable Durable
Content Dynamic Static Dynamic Dynamic
Storage type File system Archive File system Object
Lambda event source integration N/A N/A N/A Native
Operations supported Any file system operation Immutable Any file system operation Atomic with versioning
Object tagging and metadata
N N N Y
Pricing model Included in Lambda
(Charged over 512MB)
Included in Lambda Storage + data transfer + throughput Storage + requests + data transfer
Shared across all invocations N Y Y Y
Sharing/permissions model Function-only IAM IAM + NFS IAM
Source for AWS Glue and Amazon Quicksight
N N N Y
Relative data access speed from Lambda Fastest Fastest Very fast Fast

Available Now
You can now configure up to 10 GB of ephemeral storage per Lambda function instance in all Regions where AWS Lambda is available. With 10 GB container image support, 10 GB function memory, and now 10 GB of ephemeral function storage, you can support workloads such as using large temporal files, data and media processing, machine learning inference, and financial analysis.

Support is also available through many AWS Lambda Partners such as HashiCorp (Terraform), Pulumi, Datadog, Splunk (SignalFx), Lumigo, Thundra, Dynatrace, Slalom, Cloudwiry, and Contino.

For this feature, you are charged for the storage you configure over the 512 MB free limit for the duration of your function invokes. To learn more, visit AWS Lambda product and pricing page and send feedback through the AWS re:Post for AWS Lambda or your usual AWS Support contacts.

Channy

AA22-083A: Tactics, Techniques, and Procedures of Indicted State-Sponsored Russian Cyber Actors Targeting the Energy Sector

This post was originally published on this site

Original release date: March 24, 2022

Summary

Actions to Take Today to Protect Energy Sector Networks:
• Implement and ensure robust network segmentation between IT and ICS networks.
• Enforce MFA to authenticate to a system.
• Manage the creation of, modification of, use of—and permissions associated with—privileged accounts.

This joint Cybersecurity Advisory (CSA)—coauthored by the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and the Department of Energy (DOE)—provides information on multiple intrusion campaigns conducted by state-sponsored Russian cyber actors from 2011 to 2018 and targeted U.S. and international Energy Sector organizations. CISA, the FBI, and DOE responded to these campaigns with appropriate action in and around the time that they occurred. CISA, the FBI, and DOE are sharing this information in order to highlight historical tactics, techniques, and procedures (TTPs) used by adversaries to target U.S. and international Energy Sector organizations.

On March 24, 2022, the U.S. Department of Justice unsealed indictments of three Russian Federal Security Service (FSB) officers and a Russian Federation Central Scientific Research Institute of Chemistry and Mechanics (TsNIIKhM) employee for their involvement in the following intrusion campaigns against U.S. and international oil refineries, nuclear facilities, and energy companies.[1]

  • Global Energy Sector Intrusion Campaign, 2011 to 2018: the FSB conducted a multi-stage campaign in which they gained remote access to U.S. and international Energy Sector networks, deployed ICS-focused malware, and collected and exfiltrated enterprise and ICS-related data. 
    • One of the indicted FSB officers was involved in campaign activity that involved deploying Havex malware to victim networks. 
    • The other two indicted FSB officers were involved in activity targeting U.S. Energy Sector networks from 2016 through 2018.
  • Compromise of Middle East-based Energy Sector organization with TRITON Malware, 2017: Russian cyber actors with ties to the TsNIIKhM gained access to and leveraged TRITON (also known as HatMan) malware to manipulate a foreign oil refinery’s ICS controllers. TRITON was designed to specifically target Schneider Electric’s Triconex Tricon safety systems and is capable of disrupting those systems. Schneider Electric has issued a patch to mitigate the risk of the TRITON malware’s attack vector; however, network defenders should install the patch and remain vigilant against these threat actors’ TTPs.
    • The indicted TsNIIKhM cyber actor is charged with attempt to access U.S. protected computer networks and to cause damage to an energy facility.
    • The indicted TsNIIKhM cyber actor was a co-conspirator in the deployment of the TRITON malware in 2017.

This CSA provides the TTPs used by indicted FSB and TsNIIKhM actors in cyber operations against the global Energy Sector. Specifically, this advisory maps TTPs used in the global Energy Sector campaign and the compromise of the Middle East-based Energy Sector organization to the MITRE ATT&CK for Enterprise and ATT&CK for ICS frameworks.

CISA, the FBI, and DOE assess that state-sponsored Russian cyber operations continue to pose a threat to U.S. Energy Sector networks. CISA, the FBI, and DOE urge the Energy Sector and other critical infrastructure organizations to apply the recommendations listed in the Mitigations section of this advisory and Appendix A to reduce the risk of compromise. 

For more information on Russian state-sponsored malicious cyber activity, see CISA’s Russia Cyber Threat Overview and Advisories webpage. For more information on the threat of Russian state-sponsored malicious cyber actors to U.S. critical infrastructure as well as additional mitigation recommendations, see joint CSA Understanding and Mitigating Russian State-Sponsored Cyber Threats to U.S. Critical Infrastructure and CISA’s Shields Up Technical Guidance webpage. 

Rewards for Justice Program

If you have information on state-sponsored Russian cyber operations targeting U.S. critical infrastructure, contact the Department of State’s (DOS) Rewards for Justice program. You may be eligible for a reward of up to $10 million, which DOS is offering for information leading to the identification or location of any person who, while acting under the direction or control of a foreign government, participates in malicious cyber activity against U.S. critical infrastructure in violation of the Computer Fraud and Abuse Act (CFAA). Contact +1-202-702-7843 on WhatsApp, Signal, or Telegram, or send information via the Rewards for Justice secure Tor-based tips line located on the Dark Web. For more details refer to rewardsforjustice.net.

Click here for a PDF version of this report. 

Technical Details

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 10, and the ATT&CK for ICSs framework. See the ATT&CK for Enterprise and ATT&CK for ICS frameworks for all referenced threat actor tactics and techniques.

Global Energy Sector Intrusion Campaign, 2011 to 2018

From at least 2011 through 2018, the FSB (also known as Berserk Bear, Energetic Bear, TeamSpy, Dragonfly, Havex, Crouching Yeti, and Koala) conducted an intrusion campaign against international and U.S. Energy Sector organizations. The threat actor gained remote access to and deployed malware designed to collect ICS-related information on compromised Energy Sector networks, and exfiltrated enterprise and ICS data.

Beginning in 2013 and continuing through 2014, the threat actor leveraged Havex malware on Energy Sector networks. The threat actor gained access to these victim networks via spearphishing emails, redirects to compromised websites, and malicious versions of legitimate software updates on multiple ICS vendor websites. The new software updates contained installations of Havex malware, which infected systems of users who downloaded the compromised updates.

Havex is a remote access Trojan (RAT) that communicates with a command and control (C2) server. The C2 server deploys payloads that enumerate all collected network resources and uses the Open Platform Communications (OPC) standard to gather information about connected control systems devices and resources within the network. Havex allowed the actor to install additional malware and extract data, including system information, lists of files and installed programs, e-mail address books, and virtual private network (VPN) configuration files. The Havex payload can cause common OPC platforms to crash, which could cause a denial-of-service condition on applications that rely on OPC communications. Note: for additional information on Havex, see to CISA ICS Advisory ICS Focused Malware and CISA ICS Alert ICS Focused Malware (Update A).

Beginning in 2016, the threat actor began widely targeting U.S. Energy Sector networks. The actor conducted these attacks in two stages: first targeting third-party commercial organizations (such as vendors, integrators, and suppliers) and then targeting Energy Sector organizations. The threat actor used the compromised third-party infrastructure to conduct spearphishing, watering hole, and supply chain attacks to harvest Energy Sector credentials and to pivot to Energy Sector enterprise networks. After obtaining access to the U.S. Energy Sector networks, the actor conducted network discovery, moved laterally, gained persistence, then collected and exfiltrated information pertaining to ICS from the enterprise, and possibly operational technology (OT), environments. Exfiltrated information included: vendor information, reference documents, ICS architecture, and layout diagrams.

For more detailed information on FSB targeting of U.S. Energy Sector networks, See CISA Alert Russian Government Cyber Activity Targeting Energy Sector and Other Critical Infrastructure Sectors.  

Refer to Appendix A for TTPs of Havex malware and TTPs used by the actor in the 2016 to 2018 targeting of U.S. Energy Sector networks, as well as associated mitigations.

Compromise of Middle East-based Energy Sector Organization with TRITON Malware, 2017

In 2017, Russian cyber actors with ties to TsNIIKhM gained access to and manipulated a foreign oil refinery’s safety devices. TsNIIKhM actors used TRITON malware on the ICS controllers, which resulted in the refinery shutting down for several days. 

TRITON is a custom-built, sophisticated, multi-stage malware affecting Schneider Electric’s Triconex Tricon, a safety programmable logic controller (PLC) (also referred to as a safety instrumented system [SIS]), which monitors industrial processes to prevent hazardous conditions. TRITON is capable of directly interacting with, remotely controlling, and compromising these safety systems. As these systems are used in a large number of environments, the capacity to disable, inhibit, or modify the ability of a process to fail safely could result in physical consequences. Note: for additional information on affected products, see to CISA ICS Advisory Schneider Electric Triconex Tricon (Update B).

TRITON malware affects Triconex Tricon PLCs by modifying in-memory firmware to add additional programming. The extra functionality allows an attacker to read/modify memory contents and execute custom code, disabling the safety system. 

TRITON malware has multiple components, including a custom Python script, four Python modules, and malicious shellcode that contains an injector and a payload. For detailed information on TRITON’s components, refer to CISA Malware Analysis Report (MAR): HatMan: Safety System Targeted Malware (Update B).

Note: the indicted TsNIIKhM cyber actor was also involved in activity targeting U.S. Energy Sector companies in 2018, and other TsNIIKhM-associated actors have targeted a U.S.-based company’s facilities in an attempt to access the company’s OT systems. To date, CISA, FBI, and DOE have no information to indicate these actors have intentionally disrupted any U.S. Energy Sector infrastructure. 

Refer to Appendix A for TTPs used by TRITON as well as associated mitigations. 

Mitigations

Enterprise Environment

CISA, the FBI, and DOE recommend Energy Sector and other critical infrastructure organizations implement the following mitigations to harden their corporate enterprise network. These mitigations are tailored to combat multiple enterprise techniques observed in these campaigns (refer to Appendix A for observed TTPs and additional mitigations).

Privileged Account Management 
  • Manage the creation of, modification of, use of—and permissions associated with—privileged accounts, including SYSTEM and root.
Password Policies
  • Set and enforce secure password policies for accounts.
Disable or Remove Features or Programs
  • Remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries.
Audit 
  • Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc., to identify potential weaknesses.
Operating System Configuration 
  • Make configuration changes related to the operating system or a common feature of the operating system that result in system hardening against techniques.
Multifactor Authentication
  • Enforce multifactor authentication (MFA) by requiring users to provide two or more pieces of information (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.
Filter Network Traffic    
  • Use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic.
Network Segmentation
  • Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a demilitarized zone (DMZ) to contain any internet-facing services that should not be exposed from the internal network.
Limit Access to Resources over the Network
  • Prevent access to file shares, remote access to systems, and unnecessary services. Mechanisms to limit access may include use of network concentrators, Remote Desktop Protocol (RDP) gateways, etc.
Execution Prevention
  • Block execution of code on a system through application control, and/or script blocking.

Industrial Control System Environment

CISA, the FBI, and DOE recommend Energy Sector and other critical infrastructure organizations implement the following mitigations to harden their ICS/OT environment.

Network Segmentation
  • Implement and ensure robust network segmentation between IT and ICS networks to limit the ability of cyber threat actors to move laterally to ICS networks if the IT network is compromised. 
    • Implement a network topology for ICS that has multiple layers, with the most critical communications occurring in the most secure and reliable layer. For more information refer to National Institute of Standard and Technology Special Publication 800-82: Guide to Industrial Control Systems (ICS) Security. Further segmentation should be applied to portions of the network that are reliant on one another by functionality. Figure 5 on page 26 of the CISA ICS Defense in Depth Strategy document describes this architecture.
    • Use one-way communication diodes to prevent external access, whenever possible.
    • Set up DMZs to create a physical and logical subnetwork that acts as an intermediary for connected security devices to avoid exposure.
    • Employ reliable network security protocols and services where feasible.
  • Consider using virtual local area networks (VLANs) for additional network segmentation, for example, by placing all printers in separate, dedicated VLANs and restricting users’ direct printer access. This same principle can be applied to segmentation of portions of the process for which devices are used. As an example, systems that are only involved in the creation of one component within an assembly line that is not directly related to another component can be on separate VLANs, which allows for identification of any unexpected communication, as well as segmentation against potential risk exposure on a larger scale.
  • Implement perimeter security between network segments to limit the ability of cyber threat actors to move laterally. 
    • Control traffic between network segments by using firewalls, intrusion detection systems (IDSs), and rules for filtering traffic on routers and switches.
    • Implement network monitoring at key chokepoints—including egress points to the internet, between network segments, core switch locations—and at key assets or services (e.g., remote access services).
    • Configure an IDS to create alarms for any ICS traffic outside normal operations (after establishing a baseline of normal operations and network traffic).
    • Configure security incident and event monitoring to monitor, analyze, and correlate event logs from across the ICS network to identify intrusion attempts.
ICS Best Practices
  • Update all software. Use a risk-based assessment strategy to determine which ICS networks, assets, and zones should participate in the patch management program. 
  • Test all patches in out-of-band testing environments before implementation into production environments.
  • Implement application allow listing on human machine interfaces and engineering workstations.
  • Harden software configuration on field devices, including tablets and smartphones.
  • Replace all end-of-life software and hardware devices.
  • Disable unused ports and services on ICS devices (after testing to ensure this will not affect ICS operation).
  • Restrict and manage remote access software. Enforce MFA for remote access to ICS networks.
  • Configure encryption and security for network protocols within the ICS environment.
  • Do not allow vendors to connect their devices to the ICS network. Use of a compromised device could introduce malware. 
  • Disallow any devices that do not live solely on the ICS environment from communicating on the platform. ‘Transient devices’ provide risk exposure to the ICS environment from malicious activity in the IT or other environments to which they connect.
  • Maintain an ICS asset inventory of all hardware, software, and supporting infrastructure technologies. 
  • Maintain robust host logging on critical devices within the ICS environment, such as jump boxes, domain controllers, repository servers, etc. These logs should be aggregated into a centralized log server for review. 
  • Ensure robust physical security is in place to prevent unauthorized personal from accessing controlled spaces that house ICS equipment.
  • Regularly test manual controls so that critical functions can be kept running if ICS/OT networks need to be taken offline.

Contact Information

All organizations should report incidents and anomalous activity to CISA 24/7 Operations Center at report@cisa.gov or (888) 282-0870 and/or to the FBI via your local FBI field office or the FBI’s 24/7 CyWatch at (855) 292-3937 or CyWatch@fbi.gov.

References

[1] https://www.justice.gov/opa/pr/four-russian-government-employees-charged-two-historical-hacking-campaigns-targeting-critical
[2] https://collaborate.mitre.org/attackics/index.php/Software/S0003 
[3] https://collaborate.mitre.org/attackics/index.php/Software/S0003
[4] https://collaborate.mitre.org/attackics/index.php/Software/S0013 

APPENDIX A: CAMPAIGN AND MALWARE TACTICS, TECHNIQUES, AND PROCEDURES

Global Energy Sector Campaign: Havex Malware 

Table 1 maps Havex’s capabilities to the ATT&CK for Enterprise framework, and table 2 maps Havex’s capabilities to the ATT&CK for ICS framework. Table 1 also provides associated mitigations. For additional mitigations, refer to the Mitigations section of this advisory.

Table 1: Enterprise Domain Tactics and Techniques for Havex [2]

Tactic Technique Use Detection/Mitigations

Persistence [TA0003]

Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder [T1547.001]

Havex adds Registry Run keys to achieve persistence.

Monitor: monitor Registry for changes to run keys that do not correlate with known software, patch cycles, etc. Monitor the start folder for additions or changes. Tools such as Sysinternals Autoruns may also be used to detect system changes that could be attempts at persistence, including listing the run keys’ Registry locations and startup folders. Suspicious program execution as startup programs may show up as outlier processes that have not been seen before when compared against historical data.

Privilege Escalation [TA0004]

Process Injection [T1055]

Note: this technique also applies to:

  • Tactic: Defense Evasion [TA0005]

Havex injects itself into explorer.exe.

Behavior Prevention on End Point: use capabilities to prevent suspicious behavior patterns from occurring on endpoint systems. This could include suspicious process, file, Application Programming Interface (API) call, etc., behavior.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

Defense Evasion [TA0005]

Indicator Removal on Host: File Deletion [T1070.004]

Havex contains a cleanup module that removes traces of itself from victim networks.

Monitor: monitoring for command-line deletion functions to correlate with binaries or other files that an adversary may drop and remove may lead to detection of malicious activity. Another good practice is monitoring for known deletion and secure deletion tools that are not already on systems within an enterprise network, which an adversary could introduce. Some monitoring tools may collect command-line arguments but may not capture DEL commands since DEL is a native function within cmd.exe.

Credential Access [TA0006]

Credentials from Password Stores: Credentials from Web Browsers [T1555.003]

Havex may contain a publicly available web browser password recovery tool.

Password Policies: set and enforce secure password policies for accounts.

Discovery [TA0007]

Account Discovery: Email Account [T1087.003]

Havex collects address book information from Outlook

Monitor: monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as Windows Management Instrumentation (WMI) and PowerShell.

File and Directory Discovery [T1083]

Havex collects information about available drives, default browser, desktop file list, My Documents, internet history, program files, and root of available drives.

Monitor: monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as WMI and PowerShell.

Process Discovery [T1057]

Havex collects information about running processes.

Monitor: normal, benign system and network events that look like process discovery may be uncommon, depending on the environment and how they are used. Monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as WMI and PowerShell.

System Information Discovery [T1082]

Havex collects information about the OS and computer name.

Monitor: monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as WMI and PowerShell.

In cloud-based systems, native logging can be used to identify access to certain APIs and dashboards that may contain system information. Depending on how the environment is used, that data alone may not be useful due to benign use during normal operations.

System Network Configuration Discovery [T1016]

Havex collects information about the internet adapter configuration.

Monitor: monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information. Information may also be acquired through Windows system management tools such as WMI and PowerShell.
System Owner/User Discovery [T1033] Havex collects usernames.

Collection [TA0009]

Archive Collected Data [T1560]

Havex writes collected data to a temporary file in an encrypted form before exfiltration to a C2 server.

Audit: audit or scan systems, permissions, insecure software, insecure configurations, etc., to identify potential weaknesses.

Command and Control [TA0011]

Data Encoding: Standard Encoding [T1132.001]

Havex uses standard Base64 + bzip2 or standard Base64 + reverse XOR + RSA-2048 to decrypt data received from C2 servers.

Detect: analyze network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes using the network that do not normally have network communication or have never been seen before are suspicious. Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.

 

Table 2: ICS Domain Tactics and Techniques for Havex [3]

Tactic Technique Use
Initial Access Spearphishing Attachment [T0865] Havex is distributed through a Trojanized installer attached to emails.

Supply Chain Compromise [T0862]

Note: this activity also applies to Tactic: Drive by Compromise [T0817]

Havex is distributed through Trojanized installers planted on compromised vendor websites.
Execution User Execution [T0863] Execution of Havex relies on a user opening a Trojanized installer attached to an email.
Discovery Remote System Discovery [T0846] Havex uses Windows networking (WNet) to discover all the servers, including OPC servers that are reachable by the compromised machine over the network.
Remote System Information Discovery [T0888] Havex gathers server information, including CLSID, server name, Program ID, OPC version, vendor information, running state, group count, and server bandwidth.
Collection Automated Collection [T0802] Havex gathers information about connected control systems devices.
Point & Tag Identification [T0861] Havex can enumerate OPC tags; specifically tag name, type, access, and ID.
Inhibit Response Function Denial of Service [T0814] Havex has caused multiple common OPC platforms to intermittently crash. 
Impact Denial of Control [T0813] Havex can cause PLCs inability to control connected systems.

 

Global Energy Sector Campaign: 2016 to 2018 U.S. Energy Sector Targeting

Table 3 maps the 2016 to 2018 U.S. Energy Sector targeting activity to the MITRE ATT&CK Enterprise framework. Mitigations for techniques are also provided in table. For additional mitigations, refer to the Mitigations section of this advisory.

Table 3: Energy Sector Campaign, 2016 to 2018 targeting U.S. Energy Sector: Observed MITRE ATT&CK Enterprise Tactics and Techniques

Tactic Technique Use  Detection/Mitigations
Reconnaissance [TA0043] Gather Victim Identity Information: Credentials [T1589.001]

The threat actor harvested credentials of third-party commercial organizations by sending spearphishing emails that contained a PDF attachment. The PDF attachment contained a shortened URL that, when clicked, led users to a website that prompted the user for their email address and password.
The threat actor harvested credentials of Energy Sector targets by sending spearphishing emails with a malicious Microsoft Word document or links to the watering holes created on compromised third-party websites.

Note: this activity also applies to: 

  • Tactic: Reconnaissance [TA0043], Technique: Phishing for Information [T1598]:

Software Configuration: implement configuration changes to software (other than the operating system) to mitigate security risks associated to how the software operates.

User Training: train users to be aware of access or manipulation attempts by an adversary to reduce the risk of successful spearphishing, social engineering, and other techniques that involve user interaction.

Resource Development [TA0042] Compromise Infrastructure: Server [T1584.004] The threat actor created watering holes on compromised third-party organizations’ domains. This activity typically takes place outside the visibility of target organizations, making detection of this behavior difficult. Ensure that users browse the internet securely. Prevent intentional and unintentional download of malware or rootkits, and users from accessing infected or malicious websites. Treat all traffic as untrusted, even if it comes from a partner website or popular domain.
Initial Access [TA0001] Valid Accounts [T1078] The threat actor obtained access to Energy Sector targets by leveraging compromised third-party infrastructure and previously compromised Energy Sector credentials against remote access services and infrastructure—specifically VPN, RDP, and Outlook Web Access—where MFA was not enabled.

Network Segmentation: architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

Update Software: perform regular software updates to mitigate exploitation risk.

Exploit Protection: use capabilities to detect and block conditions that may lead to or be indicative of a software exploit occurring.

Application Isolation and Sandboxing: restrict execution of code to a virtual environment on or in transit to an endpoint system.

External Remote Services [T1133] The threat actor installed VPN clients on compromised third-party targets to connect to Energy Sector networks.

Network Segmentation: architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Limit Access to Resource Over Network: prevent access to file shares, remote access to systems, and unnecessary services. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc.

Disable or Remove Program: remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries.

Execution 
[TA0002]
Command and Scripting Interpreter: PowerShell [T1059.001]

During an RDP session, the threat actor used a PowerShell Script to create an account within a victim’s Microsoft Exchange Server. 

Note: this activity also applies to: 

  • Tactic: Persistence [TA0003], Technique: Create Account: Local Account [T1136.001

Antivirus/Antimalware: use signatures or heuristics to detect malicious software.

Code Signing: enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.

Disable or Remove Program: remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

Command and Scripting Interpreter: Windows Command Shell [T1059.003]

The threat actor used a JavaScript with an embedded Command Shell script to:

  • Create a local administrator account; 
  • Disable the host-based firewall;
  • Globally open port 3389 for RDP access; and
  • Attempt to add the newly created account to the administrators group to gain elevated privileges. 

Note: this activity also applies to: 

  • Tactic: Credential Access [TA0006], Technique: Input Capture [T1056]
  • Tactic: Execution [TA0002], Technique: Command and Scripting Interpreter: JavaScript [T1059.007]
  • Tactic: Persistence [TA0003], Technique: Create Account: Local Account [T1136.001]
Execution Prevention: block execution of code on a system through application control, and/or script blocking.
Scheduled Task/Job: Scheduled Task [T1053.005] The threat actor created a Scheduled Task to automatically log out of a newly created account every eight hours.

Audit: audit or scan systems, permissions, insecure software, insecure configurations, etc., to identify potential weaknesses.

Harden Operating System Configuration: make configuration changes related to the operating system or a common feature of the operating system that result in system hardening against techniques.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

User Account Management: manage the creation of, modification of, use of, and permissions associated with user accounts.

Persistence [TA0003] Create Account: Local Account [T1136.001 The threat actor created local administrator accounts on previously compromised third-party organizations for reconnaissance and to remotely access Energy Sector targets.    MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

Server Software Component: Web Shell [T1505.003] The threat actor created webshells on Energy Sector targets’ publicly accessible email and web servers. Detect: the portion of the webshell that is on the server may be small and look innocuous. Process monitoring may be used to detect Web servers that perform suspicious actions such as running cmd.exe or accessing files that are not in the Web directory. File monitoring may be used to detect changes to files in the Web directory of a Web server that do not match with updates to the Web server’s content and may indicate implantation of a Web shell script. Log authentication attempts to the server and any unusual traffic patterns to or from the server and internal network.
Defense Evasion [TA0005] Indicator Removal on Host: Clear Windows Event Logs [T1070.001]

The threat actor created new accounts on victim networks to perform cleanup operations. The accounts created were used to clear the following Windows event logs: System, Security, Terminal Services, Remote Services, and Audit. 

The threat actor also removed applications they installed while they were in the network along with any logs produced. For example, the VPN client installed at one third-party commercial facility was deleted along with the logs that were produced from its use. Finally, data generated by other accounts used on the systems accessed were deleted.

Note: this activity also applies to:

  • Tactic: Persistence [TA0003], Technique: Create Account: Local Account [T1136.001]

Encrypt Sensitive Information: protect sensitive information with strong encryption.

Remote Data Storage: use remote security log and sensitive file storage where access can be controlled better to prevent exposure of intrusion detection log data or sensitive information.

Restrict File and Directory Permissions: restrict access by setting directory and file permissions that are not specific to users or privileged accounts.

Indicator Removal on Host: File Deletion [T1070.004]

The threat actor cleaned up target networks by deleting created screenshots and specific registry keys. 

The threat actor also deleted all batch scripts, output text documents, and any tools they brought into the environment, such as scr.exe.

Note: this activity also applies to:

  • Technique: Modify Registry [T1112]
Monitor: monitoring for command-line deletion functions to correlate with binaries or other files that an adversary may drop and remove may lead to detection of malicious activity. Another good practice is monitoring for known deletion and secure deletion tools that are not already on systems within an enterprise network that an adversary could introduce. Some monitoring tools may collect command-line arguments, but may not capture DEL commands since DEL is a native function within cmd.exe.
 
Technique: Masquerading [T1036] After downloading tools from a remote server, the threat actor renamed the extensions.

Restrict File and Directory Permissions: restrict access by setting directory and file permissions that are not specific to users or privileged accounts.

Code Signing: enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.

Execution Prevention: block execution of code on a system through application control, and/or script blocking.

Credential Access [TA0006] Brute Force: Password Cracking [T1110.002]

The threat actor used password-cracking techniques to obtain the plaintext passwords from obtained credential hashes.

The threat actor dropped and executed open-source and free password cracking tools such as Hydra, SecretsDump, and CrackMapExec, and Python.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Password Policies: set and enforce secure password policies for accounts.

Forced Authentication [T1187] Microsoft Word attachments sent via spearphishing emails leveraged legitimate Microsoft Office functions for retrieving a document from a remote server over Server Message Block (SMB) using Transmission Control Protocol ports 445 or 139. As a part of the standard processes executed by Microsoft Word, this request authenticates the client with the server, sending the user’s credential hash to the remote server before retrieving the requested file. (Note: transfer of credentials can occur even if the file is not retrieved.)

Password Policies: set and enforce secure password policies for accounts.

Filter Network Traffic: use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic.

The threat actor’s watering hole sites contained altered JavaScript and PHP files that requested a file icon using SMB from an IP address controlled by the threat actors.

The threat actor manipulated LNK files to repeatedly gather user credentials. Default Windows functionality enables icons to be loaded from a local or remote Windows repository. The threat actor exploited this built-in Windows functionality by setting the icon path to a remote server controller by the actors. When the user browses to the directory, Windows attempts to load the icon and initiate an SMB authentication session. During this process, the active user’s credentials are passed through the attempted SMB connection.
 

Note: this activity also applies to:

  • Tactic: Persistence [TA0003], Technique: Boot or Logon Autostart Execution: Shortcut Modification [T1547.009]
OS Credential Dumping: Local Security Authority Subsystem Service (LSASS) Memory [T1003.001] The threat actor used an Administrator PowerShell prompt to enable the WDigest authentication protocol to store plaintext passwords in the LSASS memory. With this enabled, credential harvesting tools can dump passwords from this process’s memory.

Operating System Configuration: make configuration changes related to the operating system or a common feature of the operating system that result in system hardening against techniques.

Password Policies: set and enforce secure password policies for accounts.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

Privileged Process Integrity: protect processes with high privileges that can be used to interact with critical system components through use of protected process light, anti-process injection defenses, or other process integrity enforcement measures.

User Training: train users to be aware of access or manipulation attempts by an adversary to reduce the risk of successful spearphishing, social engineering, and other techniques that involve user interaction.

Credential Access Protection: use capabilities to prevent successful credential access by adversaries; including blocking forms of credential dumping.

OS Credential Dumping: NTDS [T1003.003] The threat actor collected the files ntds.dit. The file ntds.dit is the Active Directory (AD) database that contains all information related to the AD, including encrypted user passwords.

Monitor: monitor processes and command-line arguments for program execution that may be indicative of credential dumping, especially attempts to access or copy the NTDS.dit.

Privileged Account Management: manage the creation of, modification of, se of, and permissions associated with privileged accounts, including SYSTEM and root.

User Training: train users to be aware of access or manipulation attempts by an adversary to reduce the risk of successful spearphishing, social engineering, and other techniques that involve user interaction.

Discovery [TA0007] Remote System Discovery [T1018]

The threat actor used privileged credentials to access the Energy Sector victim’s domain controller. Once on the domain controller, the threat actors used batch scripts dc.bat and dit.bat to enumerate hosts, users, and additional information about the environment. 

Note: this activity also applies to: 

  • Tactic: Persistence [TA0003], Technique: Valid Accounts: Domain Accounts [T1078.002]
  • Tactic: Discovery [TA0007], Technique: System Owner/User Discovery [T1033]

Monitor: normal, benign system and network events related to legitimate remote system discovery may be uncommon, depending on the environment and how they are used.

Monitor processes and command-line arguments for actions that could be taken to gather system and network information.

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

The threat actor accessed workstations and servers on corporate networks that contained data output from control systems within energy generation facilities. The threat actors accessed files pertaining to ICS or supervisory control and data acquisition (SCADA) systems. 

The actor targeted and copied profile and configuration information for accessing ICS systems on the network. The threat actor copied Virtual Network Connection (VNC) profiles that contained configuration information on accessing ICS systems and took screenshots of a Human Machine Interface (HMI).

Note: this activity also applies to

  • Tactic: Discovery [TA0007], Technique File and Directory Discovery [T1083]
  • Tactic: [TA0009], Technique: Screen Capture [T1113]
File and Directory Discovery [T1083]

The actor used dirsb.bat to gather folder and file names from hosts on the network.

Note: this activity also applies to: 

  • Tactic: Execution [TA0002], Command and Scripting Interpreter: Windows Command Shell [T1059.003]
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features. Monitor processes and command-line arguments for actions that could be taken to gather system and network information. Remote access tools with built-in features may interact directly with the Windows API to gather information.
The threat actor conducted reconnaissance operations within the network. The threat actor focused on identifying and browsing file servers within the intended victim’s network.
Lateral Movement [TA0008] Lateral Tool Transfer [T1570]

The threat actor moved laterally via PsExec, batch scripts, RDP, VNC, and admin shares.

Note: this activity also applies to:

  • Tactic: Lateral Movement [TA0008], Techniques: 
    • Remote Services: Remote Desktop Protocol [T1021.001]
    • Remote Services: SMB/Windows Admin Shares [T1021.002]
    • Remote Services: VNC [T1021.005]

Network Intrusion Prevention: use intrusion detection signatures to block traffic at network boundaries.

Network Segmentation: architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network.

Operating System Configuration: make configuration changes related to the operating system or a common feature of the operating system that result in system hardening against techniques.

Privileged Account Management: manage the creation of, modification of, use of, and permissions associated with privileged accounts, including SYSTEM and root.

User Account Management: manage the creation of, modification o, se of, and permissions associated with user accounts.

Disable or Remove Feature or Program: remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries.

Audit: audit or scan systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Limit Access to Resource Over Network: prevent access to file shares, remote access to systems, and unnecessary services. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc.

Filter Network Traffic: use network appliances to filter ingress or egress traffic and perform protocol-based filtering. Configure software on endpoints to filter network traffic.

Limit Software Installation: block users or groups from installing unapproved software.

Collection [TA0009] Data from Local System [T1005 The threat actor collected the Windows SYSTEM registry hive file, which contains host configuration information.

Monitor: monitor processes and command-line arguments for actions that could be taken to collect files from a system. Remote access tools with built-in features may interact directly with the Windows API to gather data.

Data may also be acquired through Windows system management tools such as WMI and PowerShell.

Archive Collected Data: Archive via Utility [T1560.001] The threat actor compressed the ntds.dit file and the SYSTEM registry hive they had collected into archives named SYSTEM.zip and comps.zip. Audit: audit or scan systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses.
Screen Capture [T1113]

The threat actor used Windows’ Scheduled Tasks and batch scripts, to execute scr.exe and collect additional information from hosts on the network. The tool scr.exe is a screenshot utility that the threat actor used to capture the screen of systems across the network.

Note: this activity also applies to: 

  • Tactic: Execution [TA0002], Techniques: 
    • Command and Scripting Interpreter: Windows Command Shell [T1059.003]
    • Scheduled Task/Job: Scheduled Task [T1053.005]

Network Segmentation: architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network.

MFA: enforce use of two or more pieces of evidence (such as username and password plus a token, e.g., a physical smart card or token generator) to authenticate to a system.

Limit Access to Resource Over Network: prevent access to file shares, remote access to systems, and unnecessary services. Mechanisms to limit access may include use of network concentrators, RDP gateways, etc.

Disable or Remove Feature or Program: remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries.

The actor used batch scripts labeled pss.bat and psc.bat to run the PsExec tool. PsExec was used to execute scr.exe across the network and to collect screenshots of systems in a text file.

Note: this activity also applies to: 

  • Tactic: Execution [TA0002], Techniques: 
    • Command and Scripting Interpreter: Windows Command Shell [T1059.003]
    • System Services: Service Execution [T1569.002]
Command and Control [TA0011] Ingress Tool Transfer [T1105] The threat actor downloaded tools from a remote server.    

Monitor: monitor for file creation and files transferred into the network. Unusual processes with external network connections creating files on-system may be suspicious. Use of utilities, such as File Transfer Protocol, that does not normally occur may also be suspicious.

Analyze network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.

Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.

Use intrusion detection signatures to block traffic at network boundaries.

 

TRITON Malware

Table 4 maps TRITON’s capabilities to the ATT&CK for ICS framework. For mitigations to harden ICS/OT environments, refer to the Mitigations section of this advisory.

Table 4: ICS Domain Tactics and Techniques for TRITON [4]

Initial Access

Engineering Workstation Compromise [T0818]

TRITON compromises workstations within the safety network. 
Execution

Change Operating Mode [T0858]

Note: this technique also applies to Evasion.

TRITON can halt or run a program through the TriStation protocol. (Note: TriStation protocol is the protocol that Triconex System software uses to communicate with the Tricon PLCs.) 

Execution through API [T0871]

TRITON leverages a custom implementation of the TriStation protocol, which triggers APIs related to program download, program allocation, and program changes.

Hooking [T0874]

Note: this technique also applies to Tactic: Privilege Escalation.

TRITON’s injector modifies the address of the handler for a Tristation protocol command so that when the command is received, the payload may be executed instead of normal processing.
Modify Controller Tasking [T0821] Some TRITON components are added to the program table on the Tricon so that they are executed by the firmware once each cycle.
Native API [T0834] TRITON’s payload takes commands from TsHi.ExplReadRam(Ex), TsHi.ExplWriteRam(Ex), and TsHi.ExplExec functions to perform operations on controller memory and registers using syscalls written in PowerPC shellcode.
Scripting [T0853]

TRITON communicates with Triconex Tricon PLCs using its custom Python script. This Python script communicates using four Python modules that collectively implement the TriStation protocol via User Datagram Protocol (UDP) 1502.

Note: this use also applies to:

Persistence 

System Firmware [T0857]

Note: this technique also applies to Tactic: Inhibit Response Function.

TRITON’s injector injects the payload into the Tricon PLCs’ running firmware. A threat actor can use the payload to read and write memory on the PLC and execute code at an arbitrary address within the firmware. If the memory address it writes to is within the firmware region, the malicious payload disables address translation, writes the code at the provided address, flushes the instruction cache, and re-enables address translation. This allows the malware to change the running firmware.
Privilege Escalation Exploitation for Privilege Escalation [T0890] TRITON can gain supervisor-level access and control system states by exploiting a vulnerability.
Evasion Exploitation for Evasion [T0820] TRITON’s injector exploits a vulnerability in the device firmware to escalate privileges and then it disables and (later patches) a firmware RAM/ROM consistency check. 
Indicator Removal on Host [T0872] After running the malicious payload, TRITON’s Python script overwrites the malicious payload with a “dummy” program.

Masquerading [T0849]

TRITON’s Python script masquerades as legitimate Triconex software.
TRITON’s injector masquerades as a standard compiled PowerPC program for the Triconex PLC.
Discovery

Remote System Discovery [T0846]

TRITON’s Python script can autodetect Triconex PLCs on the network by sending a UDP broadcast packet over port 1502.
Lateral Movement Program Download [T0843] TRITON leverages the TriStation protocol to download programs to the Tricon PLCs.
Collection Detect Operating Mode [T0868] A TRITON Python module provides string representations of different features of the TriStation protocol, including message and error codes, key position states, and other values returned by the status functions.

Program Upload [T0845]

TRITON uploads its payload to the Tricon PLCs.
Impair Process Control Unauthorized Command Message [T0855] A threat actor can use TRITON to prevent the Tricon PLC from functioning appropriately.
Impact Loss of Safety [T0880] TRITON can reprogram the safety PLC logic to allow unsafe conditions or state to persist.

Revisions

  • March 24, 2022: Initial Version

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

Malware Delivered Through Free Sharing Tool, (Thu, Mar 24th)

This post was originally published on this site

 File sharing is a classic operation performed by many people on a daily basis. If you can share files using big players like Dropbox or all the *Drive ("One", "Google", etc), there exists a lot of free alternatives that help to easily share files with peers. Because, still today, many organizations do not provide an "official" (read: promoted, supported, and monitored) service, users are always looking for alternatives. There are plenty of tools available like Lufi[1] or transfer.sh[2] (they are plenty of others). The sample that I spotted yesterday was delivered through the second one.

AWS Week in Review – March 21, 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 round up of interesting news and announcements from AWS!

Another week, another round up of the most significant AWS launches from the previous seven days! Among the news, we have new AWS Heroes and a cost reduction. Also, improvements for customers using AWS Lambda and Amazon Elastic Kubernetes Service (EKS), and a new database-to-database connectivity option for Amazon Relational Database Service (RDS).

Last Week’s Launches
Here are some launches that caught my attention last week:

AWS Billing Conductor – This new tool provides customizable pricing and cost visibility for your end customers or business units and helps when you have specific showback and chargeback needs. To get started, see Getting Started with AWS Billing Conductor. And yes, you can call it “ABC.”

Cost Reduction for Amazon Route 53 Resolver DNS Firewall – Starting from the beginning of March, we are introducing a new tiered pricing structure that reduces query processing fees as your query volume increases. We are also implementing internal optimizations to reduce the number of DNS queries for which you are charged without affecting the number of DNS queries that are inspected or introducing any other changes to your security posture. For more info, see the What’s New.

Share Test Events in the Lambda Console With Other Developers – You can now share the test events you create in the Lambda console with other team members and have a consistent set of test events across your team. This new capability is based on Amazon EventBridge schemas and is available in the AWS Regions where both Lambda and EventBridge are available. Have a look at the What’s New for more details.

Use containerd with Windows Worker Nodes Managed by Amazon EKS – containerd is a container runtime that manages the complete container lifecycle on its host system with an emphasis on simplicity, robustness, and portability. In this way, you can get on Windows similar performance, security, and stability benefits to those available for Linux worker nodes. Here’s the What’s New with more info.

Amazon RDS for PostgreSQL databases can now connect and retrieve data from MySQL databases – You can connect your RDS PostgreSQL databases to Amazon Aurora MySQL-compatible, MySQL, and MariaDB databases. This capability works by adding support to mysql_fdw, an extension that implements a Foreign Data Wrapper (FDW) for MySQL. Foreign Data Wrappers are libraries that PostgreSQL databases can use to communicate with an external data source. Find more info in the What’s New.

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

Other AWS News
New AWS Heroes – It’s great to see both new and familiar faces joining the AWS Heroes program, a worldwide initiative that acknowledges individuals who have truly gone above and beyond to share knowledge in technical communities. Get to know them in the blog post!

More Than 400 Points of Presence for Amazon CloudFront – Impressive growth here, doubling the Points of Presence we had in October 2019. This number includes edge locations and mid-tier caches in AWS Regions. Do you know that edge locations are connected to the AWS Regions through the AWS network backbone? It’s a fully redundant, multiple 100GbE parallel fiber that circles the globe and links with tens of thousands of networks for improved origin fetches and dynamic content acceleration.

AWS Open Source News and Updates – A newsletter curated by my colleague Ricardo where he brings you the latest open-source projects, posts, events, and much more. This week he is also sharing a short list of some of the open-source roles currently open across Amazon and AWS, covering a broad range of open-source technologies. Read edition #105 here.

Upcoming AWS Events
Check your calendars and sign up for these AWS events:

The AWS Summits Are Back – Don’t forget to register to the AWS Summits in Brussels (on March 31) and Paris (on April 12). More summits are coming in the next weeks, and we’ll let you know in this weekly posts.

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

Danilo

AA22-076A: Strengthening Cybersecurity of SATCOM Network Providers and Customers

This post was originally published on this site

Original release date: March 17, 2022

Summary

Actions to Take Today:
• Use secure methods for authentication.
• Enforce principle of least privilege.
• Review trust relationships.
• Implement encryption.
• Ensure robust patching and system configuration audits.
• Monitor logs for suspicious activity.
• Ensure incident response, resilience, and continuity of operations plans are in place.

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are aware of possible threats to U.S. and international satellite communication (SATCOM) networks. Successful intrusions into SATCOM networks could create risk in SATCOM network providers’ customer environments.

Given the current geopolitical situation, CISA’s Shields Up initiative requests that all organizations significantly lower their threshold for reporting and sharing indications of malicious cyber activity. To that end, CISA and FBI will update this joint Cybersecurity Advisory (CSA) as new information becomes available so that SATCOM providers and their customers can take additional mitigation steps pertinent to their environments.

CISA and FBI strongly encourages critical infrastructure organizations and other organizations that are either SATCOM network providers or customers to review and implement the mitigations outlined in this CSA to strengthen SATCOM network cybersecurity.

Click here for a PDF version of this report.

Mitigations

CISA and FBI strongly encourages critical infrastructure organizations and other organizations that are either SATCOM network providers or customers to review and implement the following mitigations:

Mitigations for SATCOM Network Providers

  • Put in place additional monitoring at ingress and egress points to SATCOM equipment to look for anomalous traffic, such as:
    • The presence of insecure remote access tools—such as Teletype Network Protocol (Telnet), File Transfer Protocol (FTP), Secure Shell Protocol (SSH), Secure Copy Protocol (SCP), and Virtual Network Computing (VNC)—facilitating communications to and from SATCOM terminals.
    • Network traffic from SATCOM networks to other unexpected network segments.
    • Unauthorized use of local or backup accounts within SATCOM networks.
    • Unexpected SATCOM terminal to SATCOM terminal traffic.
    • Network traffic from the internet to closed group SATCOM networks.
    • Brute force login attempts over SATCOM network segments.
  • See the Office of the Director of National Intelligence (ODNI) Annual Threat Assessment of the U.S. Intelligence Community, February 2022 for specific state-sponsored cyber threat activity relating to SATCOM networks.

Mitigations for SATCOM Network Providers and Customers

  • Use secure methods for authentication, including multifactor authentication where possible, for all accounts used to access, manage, and/or administer SATCOM networks. 
    • Use and enforce strong, complex passwords: Review password policies to ensure they align with the latest NIST guidelines
    • Do not use default credentials or weak passwords.
    • Audit accounts and credentials: remove terminated or unnecessary accounts; change expired credentials.
  • Enforce principle of least privilege through authorization policies. Minimize unnecessary privileges for identities. Consider privileges assigned to individual personnel accounts, as well as those assigned to non-personnel accounts (e.g., those assigned to software or systems). Account privileges should be clearly defined, narrowly scoped, and regularly audited against usage patterns.
  • Review trust relationships. Review existing trust relationships with IT service providers. Threat actors are known to exploit trust relationships between providers and their customers to gain access to customer networks and data.  
    • Remove unnecessary trust relationships. 
    • Review contractual relationships with all service providers. Ensure contracts include appropriate provisions addressing security, such as those listed below, and that these provisions are appropriately leveraged: 
      • Security controls the customer deems appropriate. 
      • Provider should have in place appropriate monitoring and logging of provider-managed customer systems.
      • Customer should have in place appropriate monitoring of the service provider’s presence, activities, and connections to the customer network.
      • Notification of confirmed or suspected security events and incidents occurring on the provider’s infrastructure and administrative networks.
  • Implement independent encryption across all communications links leased from, or provided by, your SATCOM provider. See National Security Agency (NSA) Cybersecurity Advisory: Protecting VSAT Communications for guidance.
  • Strengthen the security of operating systems, software, and firmware.
    • Ensure robust vulnerability management and patching practices are in place and, after testing, immediately patch known exploited vulnerabilities included in CISA’s living catalog of known exploited vulnerabilities. These vulnerabilities carry significant risk to federal agencies as well as public and private sectors entities. 
    • Implement rigorous configuration management programs. Ensure the programs can track and mitigate emerging threats. Regularly audit system configurations for misconfigurations and security weaknesses.
  • Monitor network logs for suspicious activity and unauthorized or unusual login attempts.
    • Integrate SATCOM traffic into existing network security monitoring tools.
    • Review logs of systems behind SATCOM terminals for suspicious activity.
    • Ingest system and network generated logs into your enterprise security information and event management (SIEM) tool. 
    • Implement endpoint detection and response (EDR) tools where possible on devices behind SATCOM terminals, and ingest into the SIEM.
    • Expand and enhance monitoring of network segments and assets that use SATCOM.
    • Expand monitoring to include ingress and egress traffic transiting SATCOM links and monitor for suspicious or anomalous network activity. 
    • Baseline SATCOM network traffic to determine what is normal and investigate deviations, such as large spikes in traffic.
  • Create, maintain, and exercise a cyber incident response plan, resilience plan, and continuity of operations plan so that critical functions and operations can be kept running if technology systems—including SATCOM networks—are disrupted or need to be taken offline.

Contact Information

All organizations should report incidents and anomalous activity to CISA 24/7 Operations Center at report@cisa.gov or (888) 282-0870 and/or to the FBI via your local FBI field office or the FBI’s 24/7 CyWatch at (855) 292-3937 or CyWatch@fbi.gov.

Resources

Revisions

  • March 17, 2022: Initial Version

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