AWS IoT SiteWise Edge Is Now Generally Available for Processing Industrial Equipment Data on Premises

This post was originally published on this site

At AWS re:Invent 2020, we announced the preview of AWS IoT SiteWise Edge, a new feature of AWS IoT SiteWise that provides software that runs on premises at industrial sites and makes it easy to collect, process, and monitor equipment data locally before sending the data to AWS Cloud destinations. AWS IoT SiteWise Edge software can be installed on local hardware such as third-party industrial gateways and computers, or on AWS Outposts and AWS Snow Family compute devices. It uses AWS IoT Greengrass, an edge runtime that helps build, deploy, and manage applications.

With AWS IoT SiteWise Edge, you can organize and process your equipment data in the on-premises SiteWise gateway using AWS IoT SiteWise asset models. You can then read the equipment data locally from the gateway using the same application programming interfaces (APIs) that you use with AWS IoT SiteWise in the cloud. For example, you can compute metrics such as Overall Equipment Effectiveness (OEE) locally for use in a production-line monitoring dashboard on the factory floor.

You can use AWS IoT SiteWise Edge for these use cases to quickly assess and demonstrate the value of industrial IoT to your organization:

  • Localized testing of products: The testing of automotive, electronics, or aerospace products might generate thousands of data points per second from multiple sensors embedded in the product and the testing equipment. You can process data locally in the gateway for near-real-time dashboards and store just the results in the cloud to optimize your bandwidth and storage costs.
  • Lean manufacturing in the smart factory: You can compute key performance metrics such as OEE, Mean Time Between Failures (MTBF), and Mean Time to Resolution (MTTR) in the gateway and monitor local dashboards that must continue to work even if the connection of the factory to the cloud is temporarily interrupted. This ensures that factory staff can identify and identify the root cause of every bottleneck as soon as it arises.
  • Improving product quality: Your local applications can read equipment and sensor data from AWS IoT SiteWise Edge on the gateway as it is collected, and combine it with data from other sources like enterprise resource planning (ERP) systems and manufacturing execution systems to help catch defect-causing conditions. The data can be further processed through machine learning models to identify anomalies that are used to trigger alerts for staff on the factory floor.

To securely connect and read sensor data from historian databases or directly from equipment, AWS IoT SiteWise Edge supports three common industrial protocols: OPC-UA (Open Platform Communications Unified Architecture), Modbus TCP, and EtherNet/IP.

After data is collected by the gateway, you can filter, transform, and aggregate the data locally using asset models defined in the cloud. You can also run AWS Lambda functions locally on the gateway to customize how the data is processed. You can keep sensitive data on premises to help comply with data residency requirements, and you can send data to AWS IoT SiteWise or other AWS services in the cloud, such as Amazon S3 and Amazon Timestream, for long term storage and further analysis.

At GA, we added new features and made improvements based on customer feedback during the preview:

  • Easy setup with Edge Gateway Installer: You can obtain an edge device installer from the AWS IoT SiteWise console and run it on your industrial gateway to install AWS IoT SiteWise Edge software and all prerequisites, including the AWS IoT Greengrass v2 runtime, Docker, Python, and Java.
  • Support for AWS IoT Greengrass v2: The OPC-UA data collection and data processing pack will be supported on AWS IoT Greengrass version 2.
  • Integration with LDAP/Active Directory: Edge gateway now integrates with LDAP servers or a local user pool to authenticate users at the edge. These users will use their corporate or Linux credentials to authenticate themselves on OpsHub or monitor portals at the edge.

AWS IoT SiteWise Edge – Getting Started
To get started with AWS IoT SiteWise Edge, complete the following steps to create a gateway that connects to data servers to deliver your industrial data streams to the AWS Cloud:

  1. Create a gateway and an get edge installer.
  2. Install edge software onto your industrial gateway.
  3. Configure your edge gateway from the cloud.
  4. Configure your monitoring applications at the edge and in the cloud.

To create your gateway, from the left navigation pane of the AWS IoT SiteWise console, expand Edge, and choose Gateways. On the Gateways page, choose Create gateway. You can select Greengrass v2 to configure your gateway. If you are existing customer, you can select to make a gateway for Greengrass v1.

To configure your first gateway, enter your gateway name and core device name, and then choose Default setup to create a Greengrass core device for this gateway with default settings. Choose Next.

By default, AWS IoT SiteWise enables the data collection pack to collect and send your equipment data to the AWS Cloud. To compute metrics and transforms using asset models at the edge, choose Data processing pack. You can also give users access to manage this gateway through the command line or the local monitor dashboards of an OpsHub application from the LDAP/Active Directory in your organization. Choose Next.

Optionally, you can add existing OPC-UA data servers to ingest data to the gateway. You can add data sources later. For more information, see Configuring data sources in the AWS IoT SiteWise User Guide. Choose Next.

Review your gateway configuration and choose the operating system of your edge gateway. We currently support the Linux OS distributions of Amazon Linux, Red Hat, or Ubuntu. Choose Generate.

AWS IoT SiteWise will generate an installer with these configuration values for your gateway. We provide an install script that you can download, <Gateway-name>.deploy.sh, where <Gateway-name> is the name of the gateway you just created.

To set up AWS IoT SiteWise Edge on your device, run the install script and verify the AWS IoT Greengrass runtime for your gateway.

Once the gateway is created, you configure its data sources from the gateway detail page. You can configure OPC-UA, Modbus, and EtherNet/IP data sources. To learn more, please see Configuring data sources in AWS IoT SiteWise User Guide.

Now you can see the created gateway, its configuration, edge capabilities, and data sources. Once you have configured your data sources, deploy the AWS IoT Greengrass connectors with “SiteWise” in the title to your device. To learn more, see Configuring a gateway in AWS IoT SiteWise User Guide.

Processing Model Data and Monitoring the Gateway
You can use asset models defined in AWS IoT SiteWise to specify which data, transforms, and metrics to process in the gateway locally, and visualize equipment data using local AWS IoT SiteWise Monitor dashboards served from the gateway.

To add your models to the gateway, in the left navigation pane of the AWS IoT SiteWise console, expand Build, and then choose Models. On the Models page, choose Configure for edge.

There are three options for an edge configuration for an asset model: no edge configuration (that is, all properties are computed in the cloud), compute all properties at the edge, and custom edge configuration.

AWS IoT SiteWise gateway fetches all instances of the asset model from the service and processes all data it is able to collect for measurement. All you need to do is configure the asset models themselves and keep the load guidance in mind.

With AWS IoT SiteWise Edge, you can also deploy AWS IoT SiteWise Monitor web applications locally so users like process engineers can visualize equipment data in near-real time on the factory floor and use this information to improve the uptime of equipment, reduce waste, and increase production output.

At the GA release of AWS IoT SiteWise Edge, we improved the SiteWise Monitor configuration by allowing users to configure which dashboards they want to run at the edge, and to reduce clutter and bandwidth requirements, to make only those dashboards available locally. To learn more, see Getting started with AWS IoT SiteWise Monitor in the AWS IoT SiteWise Monitor Application Guide.

The OpsHub for AWS IoT SiteWise application can be installed on any Windows PC for monitoring and troubleshooting gateways entirely locally. The application connects directly to your gateway over the local network to monitor health metrics (for example, memory, CPU, cloud connectivity), status of edge software (for example, uptime of dashboard applications), and recent data collected from equipment.

We also improved the visualization of gateway health metrics and the ability to download gateway activity logs. To learn more, see Monitor data at the edge in the AWS IoT SiteWise User Guide.

Available Now
AWS IoT SiteWise Edge is available in all AWS Regions where AWS IoT SiteWise is available. AWS IoT SiteWise Edge provides the data collection and processing pack in the gateway for local applications. The data collection pack is free. The data processing pack is charged at $200 per active gateway, per month. See the AWS IoT SiteWise pricing page for details.

To learn more, visit the AWS IoT SiteWise Edge page or see Ingesting data using a gateway in the AWS IoT SiteWise User Guide.

You can send feedback through the AWS IoT SiteWise forum or through your usual AWS Support contacts.

Channy

EC2-Classic is Retiring – Here’s How to Prepare

This post was originally published on this site

Let’s go back to the summer of 2006 and the launch of EC2. We started out with one instance type (the venerable m1.small), security groups, and the venerable US East (N. Virginia) Region. The EC2-Classic network model was flat, with public IP addresses that were assigned at launch time.

Our initial customers saw the value right away and started to put EC2 to use in many different ways. We hosted web sites, supported the launch of Justin.TV, and helped Animoto to scale to a then-amazing 3400 instances when their Facebook app went viral.

Some of the early enhancements to EC2 focused on networking. For example, we added Elastic IP addresses in early 2008 so that addresses could be long-lived and associated with different instances over time if necessary. After that we added Auto Scaling, Load Balancing, and CloudWatch to help you to build highly scalable applications.

Early customers wanted to connect their EC2 instances to their corporate networks, exercise additional control over IP address ranges, and to construct more sophisticated network topologies. We launched Amazon Virtual Private Cloud in 2009, and in 2013 we made the VPC model essentially transparent with Virtual Private Clouds for Everyone.

Retiring EC2-Classic
EC2-Classic has served us well, but we’re going to give it a gold watch and a well-deserved sendoff! This post will tell you what you need to know, what you need to do, and when you need to do it.

Before I dive in, rest assured that we are going to make this as smooth and as non-disruptive as possible. We are not planning to disrupt any workloads and we are giving you plenty of lead time so that you can plan, test, and perform your migration. In addition to this blog post, we have tools, documentation, and people that are all designed to help.

Timing
We are already notifying the remaining EC2-Classic customers via their account teams, and will soon start to issue notices in the Personal Health Dashboard. Here are the important dates for your calendar:

  • All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.
  • On October 30, 2021 we will disable EC2-Classic in Regions for AWS accounts that have no active EC2-Classic resources in the Region, as listed below. We will also stop selling 1-year and 3-year Reserved Instances for EC2-Classic.
  • On August 15, 2022 we expect all migrations to be complete, with no remaining EC2-Classic resources present in any AWS account.

Again, we don’t plan to disrupt any workloads and will do our best to help you to meet these dates.

Affected Resources
In order to fully migrate from EC2-Classic to VPC, you need to find, examine, and migrate all of the following resources:

In preparation for your migration, be sure to read Migrate from EC2-Classic to a VPC.

You may need to create (or re-create, if you deleted it) the default VPC for your account. To learn how to do this, read Creating a Default VPC.

In some cases you will be able to modify the existing resources; in others you will need to create new and equivalent resources in a VPC.

Finding EC2-Classic Resources
Use the EC2 Classic Resource Finder script to find all of the EC2-Classic resources in your account. You can run this directly in a single AWS account, or you can use the included multi-account-wrapper to run it against each account of an AWS Organization. The Resource Finder visits each AWS Region, looks for specific resources, and generates a set of CSV files. Here’s the first part of the output from my run:

The script takes a few minutes to run. I inspect the list of CSV files to get a sense of how much work I need to do:

And then I take a look inside to learn more:

Turns out that I have some stopped OpsWorks Stacks that I can either migrate or delete:

Migration Tools
Here’s an overview of the migration tools that you can use to migrate your AWS resources:

AWS Application Migration Service – Use AWS MGN to migrate your instances and your databases from EC2-Classic to VPC with minimal downtime. This service uses block-level replication and runs on multiple versions of Linux and Windows (read How to Use the New AWS Application Migration Service for Lift-and-Shift Migrations to learn more). The first 90 days of replication are free for each server that you migrate; see the AWS Application Service Pricing page for more information.

Support Automation Workflow – This workflow supports simple, instance-level migration. It converts the source instance to an AMI, creates mirrors of the security groups, and launches new instances in the destination VPC.

After you have migrated all of the resources within a particular region, you can disable EC2-Classic by creating a support case. You can do this if you want to avoid accidentally creating new EC2-Classic resources in the region, but it is definitely not required.

Disabling EC2-Classic in a region is intended to be a one-way door, but you can contact AWS Support if you run it and then find that you need to re-enable EC2-Classic for a region. Be sure to run the Resource Finder that mentioned earlier and make sure that you have not left any resources behind. These resources will continue to run and to accrue charges even after the account status has been changed.

IP Address Migration – If you are migrating an EC2 instance and any Elastic IP addresses associated with the instance, you can use move-address-to-vpc then attach the Elastic IP to the migrated instance. This will allow you to continue to reference the instance by the original DNS name.

Classic Load Balancers – If you plan to migrate a Classic Load Balancer and need to preserve the original DNS names, please contact AWS Support or your AWS account team.

Updating Instance Types
All of the instance types that are available in EC2-Classic are also available in VPC. However, many newer instance types are available only in VPC, and you may want to consider an update as part of your overall migration plan. Here’s a map to get you started:

EC2-Classic VPC
M1, T1 T2
M3 M5
C1, C3 C5
CC2 AWS ParallelCluster
CR1, M2, R3 R4
D2 D3
HS1 D2
I2 I3
G2 G3

Count on Us
My colleagues in AWS Support are ready to help you with your migration to VPC. I am also planning to update this post with additional information and other migration resources as soon as they become available.

Jeff;

 

AA21-209A: Top Routinely Exploited Vulnerabilities

This post was originally published on this site

Original release date: July 28, 2021

Summary

This Joint Cybersecurity Advisory was coauthored by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the Australian Cyber Security Centre (ACSC), the United Kingdom’s National Cyber Security Centre (NCSC), and the U.S. Federal Bureau of Investigation (FBI). 

This advisory provides details on the top 30 vulnerabilities—primarily Common Vulnerabilities and Exposures (CVEs)—routinely exploited by malicious cyber actors in 2020 and those being widely exploited thus far in 2021.  

Cyber actors continue to exploit publicly known—and often dated—software vulnerabilities against broad target sets, including public and private sector organizations worldwide. However, entities worldwide can mitigate the vulnerabilities listed in this report by applying the available patches to their systems and implementing a centralized patch management system. 

Click here for a PDF version of this report.

Technical Details

Key Findings

In 2020, cyber actors readily exploited recently disclosed vulnerabilities to compromise unpatched systems. Based on available data to the U.S. Government, a majority of the top vulnerabilities targeted in 2020 were disclosed during the past two years. Cyber actor exploitation of more recently disclosed software flaws in 2020 probably stems, in part, from the expansion of remote work options amid the COVID-19 pandemic. The rapid shift and increased use of remote work options, such as virtual private networks (VPNs) and cloud-based environments, likely placed additional burden on cyber defenders struggling to maintain and keep pace with routine software patching.

Four of the most targeted vulnerabilities in 2020 affected remote work, VPNs, or cloud-based technologies. Many VPN gateway devices remained unpatched during 2020, with the growth of remote work options challenging the ability of organization to conduct rigorous patch management.

CISA, ACSC, the NCSC, and FBI consider the vulnerabilities listed in table 1 to be the topmost regularly exploited CVEs by cyber actors during 2020. 

Table 1:Top Routinely Exploited CVEs in 2020

Vendor

CVE

Type

Citrix

CVE-2019-19781

arbitrary code execution

Pulse

CVE 2019-11510

arbitrary file reading

Fortinet

CVE 2018-13379

path traversal

F5- Big IP

CVE 2020-5902

remote code execution (RCE)

MobileIron

CVE 2020-15505

RCE

Microsoft

CVE-2017-11882

RCE

Atlassian

CVE-2019-11580

RCE

Drupal

CVE-2018-7600

RCE

Telerik

CVE 2019-18935

RCE

Microsoft

CVE-2019-0604

RCE

Microsoft

CVE-2020-0787

elevation of privilege

Netlogon

CVE-2020-1472

elevation of privilege

 

In 2021, malicious cyber actors continued to target vulnerabilities in perimeter-type devices. Among those highly exploited in 2021 are vulnerabilities in Microsoft, Pulse, Accellion, VMware, and Fortinet.

CISA, ACSC, the NCSC, and FBI assess that public and private organizations worldwide remain vulnerable to compromise from the exploitation of these CVEs. Malicious cyber actors will most likely continue to use older known vulnerabilities, such as CVE-2017-11882 affecting Microsoft Office, as long as they remain effective and systems remain unpatched. Adversaries’ use of known vulnerabilities complicates attribution, reduces costs, and minimizes risk because they are not investing in developing a zero-day exploit for their exclusive use, which they risk losing if it becomes known. 

Organizations are encouraged to remediate or mitigate vulnerabilities as quickly as possible to reduce the risk of exploitation. Most can be remediated by patching and updating systems. Organizations that have not remediated these vulnerabilities should investigate for the presence of IOCs and, if compromised, initiate incident response and recovery plans. See the Contact Information section below for how to reach CISA to report an incident or request technical assistance.

2020 CVEs

CISA, ACSC, the NCSC, and FBI have identified the following as the topmost exploited vulnerabilities by malicious cyber actors from 2020: CVE-2019-19781, CVE-2019-11510, CVE-2018-13379, CVE-2020-5902, CVE-2020-15505, CVE-2020-0688, CVE-2019-3396, CVE-2017-11882, CVE-2019-11580, CVE-2018-7600, CVE 2019-18935, CVE-2019-0604, CVE-2020-0787, CVE-2020-1472.[1][2][3] Among these vulnerabilities, CVE-2019-19781 was the most exploited flaw in 2020, according to U.S. Government technical analysis.CVE-2019-19781 is a recently disclosed critical vulnerability in Citrix’s Application Delivery Controller (ADC)—a load balancing application for web, application, and database servers widely use throughout the United States.[4][5] Nation-state and criminal cyber actors most likely favor using this vulnerability because it is easy to exploit, Citrix servers are widespread, and exploitation enables the actors to perform unauthorized RCE on a target system.[6

Identified as emerging targets in early 2020,[7] unremediated instances of CVE-2019-19781 and CVE-2019-11510 continued to be exploited throughout the year by nation-state advanced persistent threat actors (APTs) who leveraged these and other vulnerabilities, such as CVE-2018-13379[8][9], in VPN services[10][11] to compromise an array of organizations, including those involved in COVID-19 vaccine development.[12][13]

The CVE-2019-11510 vulnerability in Pulse Connect Secure VPN was also frequently targeted by nation-state APTs. Actors can exploit the vulnerability to steal the unencrypted credentials for all users on a compromised Pulse VPN server and retain unauthorized credentials for all users on a compromised Pulse VPN server and can retain unauthorize access after the system is patched unless all compromised credentials are changed. Nation-state APTs also commonly exploited CVE-2020-15505 and CVE-2020-5902.[14][15][16][17]

2021 CVEs

In 2021, cyber actors continued to target vulnerabilities in perimeter-type devices. In addition to the 2020 CVEs listed above, organizations should prioritize patching for the following CVEs known to be exploited. 

  • Microsoft Exchange: CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065 
    • See CISA’s Alert: Mitigate Microsoft Exchange Server Vulnerabilities for more information on identifying and mitigating malicious activity concerning these vulnerabilities.
  • Pulse Secure: CVE-2021-22893, CVE-2021-22894, CVE-2021-22899, and CVE-2021-22900
    • See CISA’s Alert: Exploitation of Pulse Connect Secure Vulnerabilities for more information on how to investigate and mitigate this malicious activity.
  • Accellion: CVE-2021-27101, CVE-2021-27102, CVE-2021-27103, CVE-2021-27104
    • See the Australia-New Zealand-Singapore-UK-U.S. Joint Cybersecurity Advisory: Exploitation of Accellion File Transfer Appliance for technical details and mitigations.
  • VMware: CVE-2021-21985
    • See CISA’s Current Activity: Unpatched VMware vCenter Software for more information and guidance. 
  • Fortinet: CVE-2018-13379, CVE-2020-12812, and CVE-2019-5591 
    • See the CISA-FBI Joint Cybersecurity Advisory: APT Actors Exploit Vulnerabilities to Gain Initial Access for Future Attacks for more details and mitigations. 

Mitigations and Indicators of Compromise

One of the most effective best practices to mitigate many vulnerabilities is to update software versions once patches are available and as soon as is practicable. If this is not possible, consider applying temporary workarounds or other mitigations, if provided by the vendor. If an 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 or that would be accessible to the largest number of potential attackers (such as internet-facing systems). This advisory highlights vulnerabilities that should be considered as part of the prioritization process. To further assist remediation, automatic software updates should be enabled whenever possible. 

Focusing scarce cyber defense resources on patching those vulnerabilities that cyber actors most often use offers the potential of bolstering network security while impeding our adversaries’ operations. For example, nation-state APTs in 2020 extensively relied on a single RCE vulnerability discovered in the Atlassian Crow, a centralized identity management and application (CVE-2019-11580) in its reported operations. A concerted focus on patching this vulnerability could have a relative broad impact by forcing the actors to find alternatives, which may not have the same broad applicability to their target set. 

Additionally, attackers commonly exploit weak authentication processes, particularly in external-facing devices. Organizations should require multi-factor authentication to remotely access networks from external sources, especially for administrator or privileged accounts.

Tables 2–14 provide more details about, and specific mitigations for, each of the top exploited CVEs in 2020. 

Note: The lists of associated malware corresponding to each CVE below are not meant to be exhaustive but intended to identify a malware family commonly associated with exploiting the CVE.
 

Table 2: CVE-2019-19781 Vulnerability Details

Citrix Netscaler Directory Traversal (CVE-2019-19781)

Vulnerability Description
Citrix Netscaler Application Delivery Control (ADC) is vulnerable to RCE and full system compromise due to poor access controls, thus allowing directory traversal. 

CVSS 3.02 

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

The lack of adequate access controls allows an attacker to enumerate system directories for vulnerable code (directory traversal). In this instance, Citrix ADC maintains a vulnerable Perl script (newbm.pl) that, when accessed via HTTP POST request (POST https://$TARGET/vpn/../vpn/portal/scripts/newbm.pl), allows local operating system (OS) commands to execute. Attackers can use this functionality to upload/execute command and control (C2) software (webshell or reverse-shell executable) using embedded commands (e.g., curl, wget, Invoke-WebRequest) and gain unauthorized access to the OS. 

Multiple malware campaigns, including NOTROBIN, have taken advantage of this vulnerability.

Fix

Patch Available

Recommended Mitigations

  • Implement the appropriate refresh build according to the vulnerability details outlined by the vendor: Citrix: Mitigation Steps for CVE-2019-19781
  • If possible, only allow the VPN to communicate with known Internet Protocol (IP) addresses (allow-list).

Detection Methods

Vulnerable Technologies and Versions
Citrix ADC and Gateway 10.5, 11.1, 12.0, 12.1, and 13.0

References and Additional Guidance

 

Table 3: CVE 2019-11510 Vulnerability Details

Pulse Secure Connect VPN (CVE 2019-11510)

Vulnerability Description
Pulse Secure Connect is vulnerable to unauthenticated arbitrary file disclosure. An attacker can exploit this vulnerability to gain access to administrative credentials. 

CVSS 3.0

Critical
 

Vulnerability Discussion, IOCs, and Malware Campaigns
Improper access controls allow a directory traversal that an attacker can exploit to read the contents of system files. For example, the attacker could use a string such as https://sslvpn.insecure-org.com/dana-na/../dana/html5/acc/guacmole/../../../../../../etc/passwd?/dana/html5/guacamole/ to obtain the local password file from the system. The attacker can also obtain admin session data and replay session tokens in the browser. Once compromised, an attacker can run arbitrary scripts on any host that connects to the VPN. This could lead to anyone connecting to the VPN as a potential target to compromise.  

Multiple malware campaigns have taken advantage of this vulnerability, most notably REvil/Sodinokibi ransomware.

Fix

Patch Available
 

Recommended Mitigations

  • Upgrade to the latest Pulse Secure VPN.
  • Stay alert to any scheduled tasks or unknown files/executables. 
  • Create detection/protection mechanisms that respond on directory traversal (/../../../) attempts to read local system files.
Detection Methods

  • CISA developed a tool to help determine if IOCs exist in the log files of a Pulse Secure VPN Appliance for CVE-2019-11510: cisagov/check-your-pulse.
  • Nmap developed a script that can be used with the port scanning engine: http-vuln-cve2019-11510.nse #1708.

Vulnerable Technologies and Versions
Pulse Secure Pulse Connect Secure (PCS) 8.2 before 8.2R12.1, 8.3 before 8.3R7.1, and 9.0 before 9.0R3.4 are vulnerable.

References

 

Table 4: CVE 2018-13379 Vulnerability Details

Fortinet FortioOS Secure Socket Layer VPN (CVE 2018-13379)

Vulnerability Description
Fortinet Secure Sockets Layer (SSL) VPN is vulnerable to unauthenticated directory traversal, which allows attackers to gain access to the sslvpn_websession file. An attacker is then able to exact clear-text usernames and passwords. 

CVSS 3.0

Critical
 

Vulnerability Discussion, IOCs, and Malware Campaigns
Weakness in user access controls and web application directory structure allows attackers to read system files without authentication. Attackers are able to perform a HTTP GET request http://$SSLVPNTARGET?lang=/../../../..//////////dev/cmdb/sslvpn_websession. This results the server responding with unprintable/hex characters alongside cleartext credential information. 

Multiple malware campaigns have taken advantage of this vulnerability. The most notable being Cring ransomware (also known as Crypt3, Ghost, Phantom, and Vjszy1lo). 

Fix

Patch Available
 

Recommended Mitigations

  • Upgrade to the latest Fortinet SSL VPN. 
  • Monitor for alerts to any unscheduled tasks or unknown files/executables.  
  • Create detection/protection mechanisms that respond on directory traversal (/../../../) attempts to read the sslvpn_websessions file. 
Detection Methods

  • Nmap developed a script that can be used with the port scanning engine: Fortinet SSL VPN CVE-2018-13379 vuln scanner #1709.

Vulnerable Technologies and Versions
Fortinet FortiOS 6.0.0 to 6.0.4, 5.6.3 to 5.6.7, and 5.4.6 to 5.4.12 are vulnerable.

References

 

Table 5: CVE-2020-5902 Vulnerability Details

F5 Big IP Traffic Management User Interface (CVE-2020-5902)

Vulnerability Description
The Traffic Management User Interface (TMUI), also referred to as the Configuration Utility, has an RCE vulnerability in undisclosed pages. 

CVSS 3.0
Critical

Vulnerability Discussion, IOCs, and Malware Campaigns
This vulnerability allows for unauthenticated attackers, or authenticated users, with network access to the Configuration Utility (through the BIG-IP management port and/or self IPs) to execute arbitrary system commands, create or delete files, disable services, and execute arbitrary Java code. This vulnerability may result in complete system compromise. The BIG-IP system in Appliance mode is also vulnerable. This issue is not exposed on the data plane; only the control plane is affected. 

Fix
Upgrade to Secure Versions Available
 

Recommended Mitigations
Download and install a fixed software version of the software from a vendor approved resource. If it is not possible to update quickly, restrict access via the following actions.

  • Address unauthenticated and authenticated attackers on self IPs by blocking all access.
  • Address unauthenticated attackers on management interface by restricting access. 
Detection Methods

Vulnerable Technologies and Versions
BIG-IP (LTM, AAM, Advanced WAF, AFM, Analytics, APM, ASM, DDHD, DNS, FPS, GTM, Link Controller, PEM, SSLO, CGNAT) 15.1.0, 15.0.0-15.0.1, 14.1.0-14.1.2, 13.1.0-13.1.3, 12.1.0-12.1.5, and 11.6.1-11.6.5 are vulnerable.

References

 

Table 6: CVE-2020-15505 Vulnerability Details

MobileIron Core & Connector (CVE-2020-15505)

Vulnerability Description

MobileIron Core & Connector, Sentry, and Monitoring and Reporting Database (RDB) software are vulnerable to RCE via unspecified vectors.

CVSS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

CVE-2020-15505 is an RCE vulnerability in MobileIron Core & Connector versions 10.3 and earlier. This vulnerability allows an external attacker, with no privileges, to execute code of their choice on the vulnerable system. As mobile device management (MDM) systems are critical to configuration management for external devices, they are usually highly permissioned and make a valuable target for threat actors.

Multiple APTs have been observed exploiting this vulnerability to gain unauthorized access.

Fix

Patch Available

Recommended Mitigations

  • Download and install a fixed software version of the software from a vendor approved resource.

Detection Methods

  • None. Manually check your software version to see if it is susceptible to this vulnerability. 

Vulnerable Technologies and Versions

MobileIron Core & Connector versions 10.3.0.3 and earlier, 10.4.0.0, 10.4.0.1, 10.4.0.2, 10.4.0.3, 10.5.1.0, 10.5.2.0, and 10.6.0.0; Sentry versions 9.7.2 and earlier and 9.8.0; and Monitor and Reporting Database (RDB) version 2.0.0.1 and earlier are vulnerable.

References

 

Table 7: CVE-2020-0688 Vulnerability Details

Microsoft Exchange Memory Corruption (CVE-2020-0688)

Vulnerability Description

An RCE vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory.

CVSS 3.0

High

Vulnerability Discussion, IOCs, and Malware Campaigns
CVE-2020-0688 exists in the Microsoft Exchange Server when the server fails to properly create unique keys at install time. An authenticated user with knowledge of the validation key and a mailbox may pass arbitrary objects for deserialization by the web application that runs as SYSTEM. The security update addresses the vulnerability by correcting how Microsoft Exchange creates the keys during install. 

A nation-state APT actor has been observed exploiting this vulnerability to conduct widespread, distributed, and anonymized brute force access attempts against hundreds of government and private sector targets worldwide.

Fix

Patch Available

Recommended Mitigations

  • Download and install a fixed software version of the software from a vendor approved resource.

Detection Methods

Vulnerable Technologies and Versions

Microsoft Exchange Server 2019 Cumulative Update 3 and 4, 2016 Cumulative Update 14 and 15, 2013 Cumulative Update 23, and 2010 Service Pack 3 Update Rollup 30 are vulnerable.

References

 

Table 8: CVE-2019-3396 Vulnerability Details

Microsoft Office Memory Corruption (CVE 2017-11882)

Vulnerability Description

Atlassian Confluence Server and Data Center Widget Connector is vulnerable to a server-side template injection attack.

CVSS

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

Confluence Server and Data Center versions released before June 18, 2018, are vulnerable to this issue. A remote attacker is able to exploit a server-side request forgery (SSRF) vulnerability in the WebDAV plugin to send arbitrary HTTP and WebDAV requests from a Confluence Server or Data Center instance. A successful attack is able to exploit this issue to achieve server-side template injection, path traversal, and RCE on vulnerable systems.

Multiple malware campaigns have taken advantage of this vulnerability; the most notable being GandCrab ransomware.

Fix

Patch Available

Recommended Mitigations

  • Download and install a fixed software version of the software from a vendor-approved resource.

Detection Methods

Vulnerable Technologies and Versions

All versions of Confluence Server and Confluence Data Center before version 6.6.12, from version 6.7.0 before 6.12.3 (the fixed version for 6.12.x), from version 6.13.0 before 6.13.3 (the fixed version for 6.13.x), and from version 6.14.0 before 6.14.2 (the fixed version for 6.14.x) are vulnerable.

References

 

Table 9: CVE 2017-11882 Vulnerability Details

Microsoft Office Memory Corruption (CVE 2017-11882)

Vulnerability Description

Microsoft Office is prone to a memory corruption vulnerability allowing an attacker to run arbitrary code, in the context of the current user, by failing to properly handle objects in memory. It is also known as the “Microsoft Office Memory Corruption Vulnerability.” 

Cyber actors continued to exploit this four-year-old vulnerability in Microsoft Office that the U.S. Government publicly assessed last year was the most frequently targeted. Cyber actors most likely continue to exploit this vulnerability because Microsoft Office use is ubiquitous worldwide, the vulnerability is ideal for phasing campaigns, and it enables RCE on vulnerable systems.

CVSS 3.0

High

Vulnerability Discussion, IOCs, and Malware Campaigns

Microsoft Equation Editor, a component of Microsoft Office, contains a stack buffer overflow vulnerability that enables RCE on a vulnerable system. The component was compiled on November 9, 2000. Without any further recompilation, it was used in all currently supported versions of Microsoft Office. Microsoft Equation Editor is an out-of-process COM server that is hosted by eqnedt32.exe, meaning it runs as its own process and can accept commands from other processes.

Data execution prevention (DEP) and address space layout randomization (ASLR) should protect against such attacks. However, because of the manner in which eqnedt32.exe was linked, it will not use these features, subsequently allowing code execution. Being an out-of-process COM server, protections specific to Microsoft Office such as EMET and Windows Defender Exploit Guard are not applicable to eqnedt32.exe, unless applied system-wide. This provides the attacker with an avenue to lure targets into opening specially crafted documents, resulting in the ability to execute an embedded attacker commands.

Multiple cyber espionage campaigns have taken advantage of this vulnerability. CISA has noted CVE-2017-11882 being exploited to deliver LokiBot malware.

Fix

Patch Available

Recommended Mitigations

Detection Methods

  • Microsoft Defender Antivirus, Windows Defender, Microsoft Security Essentials, and the Microsoft Safety Scanner will all detect and patch this vulnerability.

Vulnerable Technologies and Versions

  • Microsoft Office 2007 Service Pack 3, Microsoft Office 2010 Service Pack 2, Microsoft Office 2013 Service Pack 1, and Microsoft Office 2016 are vulnerable.

References

 

Table 10: CVE 2019-11580 Vulnerability Details

Atlassian Crowd and Crowd Data Center Remote Code Execution (CVE 2019-11580)

Vulnerability Description

Atlassian Crowd and Crowd Data Center had the pdkinstall development plugin incorrectly enabled in release builds.

CVSS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

Attackers who can send unauthenticated or authenticated requests to a Crowd or Crowd Data Center instance can exploit this vulnerability to install arbitrary plugins, which permits RCE on systems running a vulnerable version of Crowd or Crowd Data Center.

Fix

Patch Available

Recommended Mitigations

  • Atlassian recommends customers running a version of Crowd below version 3.3.0 to upgrade to version 3.2.8. For customers running a version above or equal to 3.3.0, Atlassian recommends upgrading to the latest version.
  • Released Crowd and Crowd Data Center version 3.4.4 contains a fix for this issue and is available at https://www.atlassian.com/software/crowd/download.
  • Released Crowd and Crowd Data Center versions 3.0.5, 3.1.6, 3.2.8, and 3.3.5 contain a fix for this issue and are available at https://www.atlassian.com/software/crowd/download-archive.

Detection Methods

Vulnerable Technologies and Versions

All versions of Crowd from version 2.1.0 before 3.0.5 (the fixed version for 3.0.x), from version 3.1.0 before 3.1.6 (the fixed version for 3.1.x), from version 3.2.0 before 3.2.8 (the fixed version for 3.2.x), from version 3.3.0 before 3.3.5 (the fixed version for 3.3.x), and from version 3.4.0 before 3.4.4 (the fixed version for 3.4.x) are affected by this vulnerability.

References

 

Table 11: CVE 2018-7600 Vulnerability Details

Drupal Core Multiple Remote Code Execution (CVE 2018-7600)

Vulnerability Description

Drupal versions before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1 allow remote attackers to execute arbitrary code because of an issue affecting multiple subsystems with default or common module configurations.

CVSS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

An RCE vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised. Failed exploit attempts may result in a denial-of-service condition. A remote user can send specially crafted data to trigger a flaw in the processing of renderable arrays in the Form Application Programming Interface, or API, and cause the target system to render the user-supplied data and execute arbitrary code on the target system.

Malware campaigns include the Muhstik botnet and XMRig Monero Cryptocurrency mining.

Fix

Patch Available

Recommended Mitigations

  • Upgrade to the most recent version of Drupal 7 or 8 core. If running 7.x, upgrade to Drupal 7.58. If running 8.5.x, upgrade to Drupal 8.5.1.

Detection Methods

Vulnerable Technologies and Versions

  • Drupal versions before 7.58, 8.x before 8.3.9, 8.4.x before 8.4.6, and 8.5.x before 8.5.1 are affected.

References

 

Table 12: CVE 2019-18935 Vulnerability Details

Telerik UI for ASP.NET AJAX Insecure Deserialization (CVE 2019-18935)

Vulnerability Description

Telerik User Interface (UI) for ASP.NET does not properly filter serialized input for malicious content. Versions prior to R1 2020 (2020.1.114) are susceptible to  remote code execution attacks on affected web servers due to a deserialization vulnerability.

CVS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

The Telerik UI does not properly sanitize serialized data inputs from the user. This vulnerability leads to the application being vulnerable to RCE attacks that may lead to a full system compromise. A vulnerable HTTP POST parameter rauPostData makes use of a vulnerable function/object AsyncUploadHandler. The object/function uses the JavaScriptSerializer.Deserialize() method, which not not properly sanitize the serialized data during the deserialization process. This issue is attacked by:

  1. Determining the vulnerable function is available/registered:  http://<HOST>/Telerik.Web.UI.WebResource.axd?type=rau,
  2. Determining if the version running is vulnerable by querying the UI, and
  3. Creating an object (e.g., malicious mixed-mode DLL with native OS commands or Reverse Shell) and uploading the object via rauPostData parameter along with the proper encryption key.

There were two malware campaigns associated with this vulnerability:

  • Netwalker Ransomware and
  • Blue Mockbird Monero Cryptocurrency-mining.

Fix

Patch Available

Recommended Mitigations

  • Update to the most recent version of Telerik UI for ASP.NET AJAX (at least 2020.1.114 or later).

Detection Methods

  • ACSC has an example PowerShell script that can be used to identify vulnerable Telerik UI DLLs on Windows web server hosts.
  • Vulnerable hosts should be reviewed for evidence of exploitation. Indicators of exploitation can be found in IIS HTTP request logs and within the Application Windows event log. Details of the above PowerShell script and exploitation detection recommendations are available in ACSC Advisory 2020-004.
  • Exploitation of this and previous Telerik UI vulnerabilities commonly resulted in the installation of web shell malware. NSA provides guidance on detecting and preventing web shell malware.

Vulnerable Technologies and Versions

Telerik UI for ASP.NET AJAX versions prior to R1 2020 (2020.1.114) are affected.

References

 

Table 13: CVE-2019-0604 Vulnerability Details

Microsoft SharePoint Remote Code Execution (CVE-2019-0604)

Vulnerability Description

A vulnerability in an XML deserialization component within Microsoft SharePoint allowed remote attackers to execute arbitrary code on vulnerable Microsoft SharePoint servers.

CVSS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

This vulnerability was typically exploited to install webshell malware to vulnerable hosts. A webshell could be placed in any location served by the associated Internet Information Services (IIS) web server and did not require authentication. These web shells would commonly be installed in the Layouts folder within the Microsoft SharePoint installation directory, for example:

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions<version_number>TemplateLayouts

The xmlSerializer.Deserialize() method does not adequately sanitize user input that is received from the PickerEnitity/ValidateEnity (picker.aspx) functions in the serialized XML payloads. Once the serialized XML payload is deserialized, the XML code is evaulated for relevant XML commands and stings. A user can attack .Net based XML parsers with XMLNS payloads using the <system:string> tag and embedding malicious operating system commands. 

The exploit was used in malware phishing and the WickrMe/Hello Ransomware campaigns.

Fix

Patch Available

Recommended Mitigations

  • Upgrade on-premise installations of Microsoft Sharepoint to the latest available version (Microsoft SharePoint 2019) and patch level.
  • On-premise Microsoft SharePoint installations with a requirement to be accessed by internet-based remote staff should be moved behind an appropriate authentication mechanism such as a VPN, if possible.

Detection Methods

  • The patch level of on-premise Microsoft SharePoint installations should be reviewed for the presence of relevant security updates as outlined in the Microsoft SharePoint security advisory.
  • Vulnerable SharePoint servers should be reviewed for evidence of attempted exploitation. ACSC Advisory 2019-125 contains advice on reviewing IIS HTTP request logs for evidence of potential exploitation.
  • NSA provides guidance on detecting and preventing web shell malware.

Vulnerable Technologies and Versions

At the time of the vulnerability release, the following Microsoft SharePoint versions were affected: Microsoft Sharepoint 2019, Microsoft SharePoint 2016, Microsoft SharePoint 2013 SP1, and Microsoft SharePoint 2010 SP2.

References

 

Table 14: CVE-2020-0787 Vulnerability Details

Windows Background Intelligent Transfer Service Elevation of Privilege (CVE-2020-0787)

Vulnerability Description

The Windows Background Intelligent Transfer Service (BITS) is vulnerable to a privilege elevation vulnerability if it improperly handles symbolic links. An actor can exploit this vulnerability to execute arbitrary code with system-level privileges.

CVSS 3.0

High

Vulnerability Discussion, IOCs, and Malware Campaigns

To exploit this vulnerability, an actor would first need to have the ability to execute arbitrary code on a vulnerable Windows host.

Actors exploiting this vulnerability commonly used the proof of concept code released by the security researcher who discovered the vulnerability. If an actor left the proof of concept exploit’s working directories unchanged, then the presence of the following folders could be used as an indicator of exploitation:

C:Users<username>AppDataLocalTempworkspace
C:Users<username>AppDataLocalTempworkspacemountpoint
C:Users<username>AppDataLocalTempworkspacebait

The exploit was used in Maze and Egregor ransomware campaigns.

Fix

Patch Available

Recommended Mitigations

  • Apply the security updates as recommended in the Microsoft Netlogon security advisory.

Detection Methods

  • The patch level of all Microsoft Windows installations should be reviewed for the presence of relevant security updates as outlined in the Microsoft BITS security advisory.

Vulnerable Technologies and Versions

Windows 7 for 32-bit and x64-based Systems Service Pack 1, 8.1 for 32-bit and x64-based systems, RT 8.1, 10 for 32-bit and x64-based Systems, 10 1607 for 32-bit and x64-based Systems, 10 1709 for 32-bit and x64-based and ARM64-based Systems, 10 1803 for 32-bit and ARM64-based and x64-based Systems, 10 1809 for 32-bit and ARM64-based and x64-based Systems, 10 1903 for 32-bit and ARM64-based and x64-based Systems, 10 1909 for 32-bit, and ARM64-based and x64-based Systems are vulnerable.

Windows Server 2008 R2 for x64-based Systems Service Pack 1, 2008 R2 for x64-based Systems Service Pack 1 (Server Core Installation), 2008 for 32-bit Systems Service Pack 2, 2008 for 32-bit Systems Service Pack 2 (Server Core Installation), 2012, 2012 (Server Core Installation), 2012 R2, 2012 R2 (Server Core Installation), 2016, 2016 (Server Core Installation), 2019, 2019 (Server Core Installation), 1803 (Server Core Installation), 1903 (Server Core Installation), and 1909 (Server Core Installation) are also vulnerable.

References

 

Table 15: CVE-2020-1472 Vulnerability Details

Netlogon Elevation of Privilege (CVE-2020-1472)

Vulnerability Description

The Microsoft Windows Netlogon Remote Protocol (MS-NRPC) reuses a known, static, zero-value initialization vector (VI) in AES-CFB8 mode, which could allow an unauthenticated attacker to impersonate a domain-joined computer including a domain controller, and potentially obtain domain administrator privileges.

CVSS 3.0

Critical

Vulnerability Discussion, IOCs, and Malware Campaigns

To exploit this vulnerability, an actor would first need to have an existing presence on an internal network with network connectivity to a vulnerable Domain Controller, assuming that Domain Controllers are not exposed to the internet.

The immediate effect of successful exploitation results in the ability to authentication to the vulnerable Domain Controller with Domain Administrator level credentials. In compromises exploiting this vulnerability, exploitation was typically followed immediately by dumping all hashes for Domain accounts.

Threat actors were seen combining the MobileIron CVE-2020-15505 vulnerability for initial access, then using the Netlogon vulnerability to facilitate lateral movement and further compromise of target networks.

A nation-state APT group has been observed exploiting this vulnerability.[18]

Fix

Patch Available

Recommended Mitigations

  • Apply the security updates as recommended in the Microsoft Netlogon security advisory.

Detection Methods

  • The patch level of Domain Controllers should be reviewed for the presence of relevant security updates as outlined in the Microsoft Netlogon security advisory.
  • Reviewing and monitoring Windows Event Logs can identify potential exploitation attempts. However, further investigation would still be required to eliminate legitimate activity. Further information on these event logs is available in the ACSC 2020-016 Advisory.

Vulnerable Technologies and Versions

At the time of the vulnerability release, the following Microsoft Windows Server versions were vulnerable: all versions of Windows Server 2019; all versions of Windows Server 2016; Windows Server 2012 R2; Windows Server 2012; Windows Server 2008 R2 SP1; and Windows Server versions 1909/1903/1809.

References

 

For additional general best practices for mitigating cyber threats, see the joint advisory from Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity and ACSC’s Essential Eight mitigation strategies.

Additional Resources

Free Cybersecurity Services

CISA offers several free cyber hygiene vulnerability scanning and web application services to help U.S. federal agencies, state and local governments, critical infrastructure, and private organizations reduce their exposure to threats by taking a proactive approach to mitigating attack vectors. For more information about CISA’s free services, or to sign up, email vulnerability_info@cisa.dhs.gov.

Cyber Essentials

CISA’s Cyber Essentials is a guide for leaders of small businesses as well as leaders of small and local government agencies to develop an actionable understanding of where to start implementing organizational cybersecurity practices.

Cyber.gov.au 

ACSC’s website provides advice and information about how to protect individuals and families, small- and medium-sized businesses, large organizations and infrastructure, and government organizations from cyber threats.

ACSC Partnership Program

The ACSC Partnership Program enables Australian organizations and individuals to engage with ACSC and fellow partners, drawing on collective understanding, experience, skills, and capability to lift cyber resilience across the Australian economy.

Australian organizations, including government and those in the private sector as well individuals, are welcome to sign up at Become an ACSC partner to join.

NCSC 10 Steps

The NCSC offers 10 Steps to Cyber Security, providing detailed guidance on how medium and large organizations can manage their security.

On vulnerabilities specifically, the NCSC has guidance to organizations on establishing an effective vulnerability management process, focusing on the management of widely available software and hardware.

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. If you have any further questions related to this Joint Cybersecurity Advisory, or to request incident response resources or technical assistance related to these threats, contact CISA at Central@cisa.gov.

References

Revisions

  • Initial Version: July 28, 2021

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

Introducing Amazon Route 53 Application Recovery Controller

This post was originally published on this site

I am pleased to announce the availability today of Amazon Route 53 Application Recovery Controller, a Amazon Route 53 set of capabilities that continuously monitors an application’s ability to recover from failures and controls application recovery across multiple AWS Availability Zones, AWS Regions, and on premises environments to help you to build applications that must deliver very high availability.

At AWS, the security and availability of your data and workloads are our top priorities. From the very beginning, AWS global infrastructure allowed you to build application architectures that are resilient to different type of failures. When your business or application requires high availability, you typically use AWS global infrastructure to deploy redundant application replicas across AWS Availability Zones inside an AWS Region. Then, you use a Network or Application Load Balancer to route traffic to the appropriate replica. This architecture handles the requirements of the vast majority of workloads.

However, some industries and workloads have higher requirements in terms of high availability: availability rate at or above 99.99% with recovery time objectives (RTO) measured in seconds or minutes. Think about how real-time payment processing or trading engines can affect entire economies if disrupted. To address these requirements, you typically deploy multiple replicas across a variety of AWS Availability Zones, AWS Regions, and on premises environments. Then, you use Amazon Route 53 to reliably route end users to the appropriate replica.

Amazon Route 53 Application Recovery Controller helps you to build these applications requiring very high availability and low RTO, typically those using active-active architectures, but other type of redundant architectures might also benefit from Amazon Route 53 Application Recovery Controller. It is made of two parts: readiness check and routing control.

Readiness checks continuously monitor AWS resource configurations, capacity, and network routing policies, and allow you to monitor for any changes that would affect the ability to execute a recovery operation. These checks ensure that the recovery environment is scaled and configured to take over when needed. They check the configuration of Auto Scaling groups, Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon Elastic Block Store (EBS) volumes, load balancers, Amazon Relational Database Service (RDS) instances, Amazon DynamoDB tables, and several others. For example, readiness check verifies AWS service limits to ensure enough capacity can be deployed in an AWS Region in case of failover. It also verifies capacity and scaling characteristics of application replicas are the same across AWS Region.

Routing controls help to rebalance traffic across application replicas during failures, to ensure that the application stays available. Routing controls work with Amazon Route 53 health checks to redirect traffic to an application replica, using DNS resolution. Routing controls improve traditional automated Amazon Route 53 health check-based failovers in three ways:

  • First, routing controls give you a way to failover the entire application stack based on application metrics or partial failures, such as a 5% increased error rate or a millisecond of increased latency.
  • Second, routing controls give you safe and simple manual overrides. You can use them to shift traffic for maintenance purposes or to recover from failures when your monitors fail to detect an issue.
  • Third, routing controls can use a capability called safety rules to prevent common side effects associated with fully automated health checks, such as preventing fail over to an unprepared replica, or flapping issues.

To help you understand how Route 53 Application Recovery Controller works, I’ll walk you through the process I used to configure my own high availability application.

How It Works
For demo purposes, I built an application made up of a load balancer, an Auto Scaling group with two EC2 instances, and a global DynamoDB table. I wrote a CDK script to deploy the application in two AWS Regions: US East (N. Virginia) and US West (Oregon). The global DynamoDB table ensures data is replicated across the two AWS Regions. This is an active-standby architecture, as I described earlier.

The application is a multi-player TicTacToe game, an application that typically needs 99.99% availability or more :-). One DNS record (tictactoe.seb.go-aws.com) points to the load balancer in the US East (N. Virginia) region. The following diagram shows the architecture for this application:

Example application architecture

Preparing My Application
To configure Route 53 Application Recovery Controller for my application, I first deployed independent replicas of my application stack so that I can fail over traffic across the stacks. These copies are deployed across AWS high-availability boundaries, such as Availability Zones, or AWS Regions. I chose to deploy my application replicas across multiple AWS Regions

Then, I configured data replication across these independent replicas. I’m using DynamoDB global tables to help replicate my data.

Lastly, I configured each independent stack to expose a DNS name. This DNS name is the entry point into my application, such as a regional load balancer DNS name.

Terminology
Before I configure readiness check, let me share some basic terminology.

A cell defines the silo that contains my application’s independent units of failover. It groups all AWS resources that are required for my application to operate independently. For my demo, I have two cells: one per AWS Region where my application is deployed. A cell is typically aligned with AWS high-availability boundaries, such as AWS Regions or Availability Zones, but it can be smaller too. It is possible to have multiple cells in one Availability Zone. This is an effective way to reduce blast radius, especially when you follow one-cell-at-a-time change management practices.

definition of a cell

A recovery group is a collection of cells that represent an application or group of applications that I want to check for failover readiness. A recovery group typically consists of two or more cells that mirror each other in terms of functionality.

definition of a recovery group

A resource set is a set of AWS resources that can span multiple cells. For this demo, I have three resource sets: one for the two load balancers in us-east-1 and us-west-2, one for the two Auto Scaling groups in the two Regions, and one for the global DynamoDB table.

A readiness check validates a set of AWS resources readiness to be failed over to. In this example, I want to audit readiness for my load balancers, Auto Scaling groups, and DynamoDB table. I create a readiness check for the Auto Scaling groups. The service constantly monitors the instance types and counts in the groups to make sure that each group is scaled equally. I repeat the process for the load balancer and the global DynamoDB table.

definition of a resource set

To help determine recovery readiness for my application, Route 53 Application Recovery Controller continuously audits mismatches in capacity, AWS resource limits, and AWS throttle limits across application cells (Availability Zones or Regions). When Route 53 Application Recovery Controller detects a mismatch in limits, it raises an AWS Service Quota request for the resource across the cells. If Route 53 Application Recovery Controller detects a capacity mismatch in resources, I can take actions to align capacity across the cells. For example, I could trigger a scaling increase for my Auto Scaling groups.

Create a Readiness Check
To create a readiness check, I open the AWS Management Console and navigate to the Application Recovery Controller section under Route 53.

Create Recovery Group

To create a recovery group for my application, I navigate to the Getting Started section, then I choose Create recovery group.

Create Recovery Group - enter a name

I enter a name (for example AWSNewsBlogDemo) and then choose Next.

Create Recovery readiness - create cells

In Configure Architecture, I choose Add Cell, then I enter a cell name (AWSNewsBlogDemo-RegionWEST) and then choose Add Cell again to add a second cell. I enter AWSNewsBlogDemo-RegionEAST for the second cell. I choose Next to review my inputs, then I choose Create recovery group.

I now need to associate resources such as my load balancers, Auto Scaling groups, and DynamoDB table with my recovery group.

Create Resource Set

In the left navigation pane, I choose Resource Set and then I choose Create.

Create Resource Set - load balancers

I enter a name for my first resource set (for example, load_balancers). For Resource type, I choose Network Load Balancer or Application Load Balancer and I then choose Add to add the load balancer ARN.

I choose Add again to enter the second load balancer ARN, and then I choose Create resource set.

I repeat the process to create one resource set for the two Auto Scaling groups and a third resource set for the global DynamoDB table (one ARN). I now have three resource sets:

Create Resource Set - 3 Resource Sets

My last step is to create the readiness check. This will associate the resources with cells in the resource groups.

Create Readiness Check

In Readiness check, I choose Create at the top right of the screen, then Readiness check.

Create Readiness Check Step 1

Step 1 (Create readiness check), I enter a name (for example, load_balancers). For Resource Type, I choose Network Load Balancer or Application Load Balancer and then choose Next.

Create Readiness Check Step 2

Step 2 (Add resource set), I keep the default selection Use an existing resource set and for Resource set name, I choose load_balancers and then I choose Next.

Step 3 (Apply readiness rules), I review the rules and then choose Next.

Recovery Group Options

Step 4 (Recovery Group Options), I keep the default selection Associate with an existing recovery group. For Recovery group name, I choose AWSNewsBlog. Then, I associate the two cells (EAST and WEST) with the two load balancers ARN. Be sure to associate the correct load balancer to each cell. The Region name is included in the ARN.

Step 5 (Review and create), I review my choices and then choose Create readiness check.

Three readiness checks

I repeat this process for the Auto Scaling group and the DynamoDB global table.

Recovery Groups in Ready mode

When all readiness checks in the group are green, the group has a status of Ready.

Now, I can configure and test the routing controls.

Terminology
Before I configure routing controls, let me share some basic terminology.

A cluster is a set of five redundant Regional endpoints against which you can execute API calls to update or get the state of routing controls. You can host multiple control panels and routing controls on one cluster.

A routing control is a simple on/off switch, hosted on a cluster, that you use to control routing of client traffic in and out of cells. When you create a routing control, you add a health check in Route 53 so that you can reroute traffic when you update the routing control in Route 53 Application Recovery Controller. The health checks must be associated with DNS failover records that front each application replica if you want to use them to route traffic with routing controls.

A control panel groups together a set of related routing controls.

Configure Routing Controls
I can use the Route 53 console or API actions to create a routing control for each AWS Region for my application. After I create routing controls, I create an Amazon Route 53 Application Recovery Controller health check for each one, and then associate each health check with a DNS failover record for my load balancers in each Region. Then, to fail over traffic between Regions, I change the routing control state for one routing control to off and another routing control state to on.

The first step is to create a cluster. A cluster is charged $2.5 / hour. When you create a cluster to experience Route 53 Application Recovery Controller, be sure to delete the cluster after your experimentation.

Create Cluster

In the left navigation pane, I navigate to the cluster panel and then I choose Create.

Create Cluster - enter name

I enter a name for my cluster and then choose Create cluster.

The cluster is in Pending state for a few minutes. After a while, its status changes to Deployed.

After it’s deployed, I select the cluster name to discover the five redundant API endpoints. You must specify one of those endpoints when you build recovery tools to retrieve or set routing control states. You can use any of the cluster endpoints, but in complex or automated scenarios, we recommend that your systems be prepared to retry with each of the available endpoints, using a different endpoint with each retry request.

Routing Control Cluster Endpoints

Traffic routing is managed through routing controls that are grouped in a control panel. You can create one or use the default one that is created for you.

Default Control Panel

I choose DefaultControlPanel.

Default Control Panel - Add routing control

I choose Add routing control.

Create Routing Control

I enter a name for my routing (FailToWEST) control and then choose Create routing control. I repeat the operation for the second routing control (FailToEAST).

Control Panel - Create Health Check

After the routing control is created, I choose it from the list. On the detail page, I choose Create health check to create a health check in Route 53.

Control Panel - Create Health Check

I enter a name for the health check and then choose Create. I navigate to the Route 53 console to verify the health check was correctly created.

I create one health check for each routing control.

You might have noticed that the Control Panel provides a place where you can add Safety Rules. When you work with several routing controls at the same time, you might want some safeguards in place when you enable and disable them. These help you to avoid initiating a failover when a replica is not ready, or unintended consequences like turning both routing controls off and stopping all traffic flow. To create these safeguards, you create safety rules. For more information about safety rules, including usage examples, see the Route 53 Application Recovery Controller developer guide.

Now the routing controls and the DNS health check are in place, the last step is to route traffic to my application.

Adjust My DNS Settings
To route traffic to my application. I assign a DNS alias to the top-level entry point of the application in the cell. For this example, using the Route 53 console, I create two ALIAS A records of type FAILOVER and associate each health check with each DNS record. The two records have the same record name. One is the primary record and the other is the secondary record. For more information about Amazon Route 53 health checks, see the Amazon Route 53 developer guide.

DNS Alias Record Primary DNS Alias Record Secondary

On the application recovery routing controls page, I enable one of the two routing controls.

Application recovery Control - enable one control state

As soon as I do, all the traffic pointed to tictactoe.seb.go-aws.com goes to the infrastructure deployed on us-east-1.

Testing My Setup
To test my setup, I first use the dig command in a terminal. It shows the DNS CNAME record that points to the load balancer deployed in us-east-1.

testing alias for us-east-1

I also test the application with a web browser. I observe the name tictactoe.seb.go-aws.com goes to us-east-1.

Tic Tac Toe application

Now, using the update-routing-control-state API action, the CLI, or the console, I turn off the routing control to the us-east-1 Region and turn on the one to the us-west-2 Region. When I use the CLI, I use the endpoints provided by my cluster.

aws route53-recovery-cluster update-routing-control-state 
     --routing-control-arn arn:aws:route53-recovery-control::012345678:controlpanel/xxx/routingcontrol/abcd 
     --routing-control-state On 
     --region us-west-2 
     --endpoint-url https://host-xxx.us-west-2.cluster.routing-control.amazonaws.com/v1

In the console, I navigate to the control panel, I select the routing control I want to change and click Change routing control states.

Changing routing control states

After less than a minute, the DNS address is updated. My application traffic is now routed to the us-west-2 Region.

DNS checked after a routing control state change

Readiness checks and routing controls provide a controlled failover for my application traffic, redirecting traffic from my active replica to my standby one, in another AWS Region. I can change the traffic routing manually, as I showed in the demo, or I can automate it using Amazon CloudWatch alarms based on technical and business metrics for my application.

Pricing
This new capability is charged on demand. There are no upfront costs. You are charged per readiness check and per cluster per hour. Readiness checks are charged $0.045 / hour. Cluster are charged $2.5 / hour. In the demo example used for this blog post, there are three readiness checks and one cluster. The price per hour for this setup, excluding the application itself, is 3 x $0.045 + 1 x $2.5 = $2.635 / hour. For more details about the pricing, including an example, see the Route 53 pricing page.

This new capability is a global service that can be used to monitor and control application recovery for application running in any of the public commercial AWS Regions. Give it a try and let us know what you think. As always, you can send feedback through your usual AWS Support contacts or post it on the AWS forum for Route 53 Application Recovery Controller.

— seb

Announcing PowerShell Crescendo Preview.3

This post was originally published on this site

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

Warning


Preview.3 includes a change to the schema to support
multiple command configurations. This is a breaking change from previous previews. To enjoy the new
multi-command JSON format, please upgrade to the latest preview.

The updated preview release is 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 3 Updates

Crescendo 0.6.1-Preview.3 adds support to handle multiple command definitions per JSON
configuration and additional output handling options. Read the full list of changes
below:

  • Added support for multiple commands per JSON configuration.
    Issue #49
  • Added additional output handler options inline, function, and script.
    Issue #33
  • Added additional proxy generation code cleanup

Support multiple command definitions per JSON configuration

To improve the development and distribution of Crescendo wrapped commands, the schema for Crescendo
has been extended to support multiple command definitions in a single JSON file. A new keyword
Commands creates an additional tier to the hierarchy, followed by single or multiple command
definitions. This is a breaking change from previous previews.

In the example below, each command definition is located inside the Commands keyword.

{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Commands": [
         {
             "Verb": "New",
             "Noun": "Command1",
             "OriginalName":"<path><command>"
         },
         {
            "Verb": "New",
            "Noun": "Command2",
            "OriginalName":"<path><command>"
         },
         {
            "Verb": "New",
            "Noun": "Command3",
            "OriginalName":"<path><command>"
         }
    ]
}

Additional per command features such as parameter definitions and administrative elevation may be
added to single or multiple command definitions. Check out these blogs for more information about
parameters
and
elevation.

Support additional OutputHandlers

Output handlers take the text output (string) from a native command and convert those strings to
objects. Crafting custom output handlers is complex unless the native commands produce structured
output such as XML or JSON. To provide authors with development and deployment flexibility,
Crescendo supports three types of output handlers: inline, script, and function.

  • Inline – Authors construct the output handler code inside the cmdlet definition. When
    Crescendo generates the module, the output handler code is written directly into the proxy
    function for the new cmdlet.
  • Script – Authors may choose to develop the output handler in a separate script to isolate
    troubleshooting. The Handler keyword supports the path and script name to be included. Crescendo
    generates the module (.psm1) containing the proxy cmdlet, the manifest (.psd1), and includes the
    specified script as an additional asset.
  • Function – Authors may already have written output handlers that have been imported into
    PowerShell as functions. Crescendo adds the imported function to the generated module outside of
    the proxy cmdlet.
{
    "$schema": "./Microsoft.PowerShell.Crescendo.Schema.json",
    "Commands": [
         {
             "Verb": "New",
             "Noun": "Command1",
             "OriginalName":"<path><command>",
             "OutputHandlers": [
                {
                  "ParameterSetName": "viaInline",
                  "HandlerType": "Inline",
                  "Handler": "$args[0] | ConvertFrom-Json"
                }
             ]
         },
         {
            "Verb": "New",
            "Noun": "Command2",
            "OriginalName":"<path><command>",
            "OutputHandlers": [
                {
                  "ParameterSetName": "viaScript",
                  "HandlerType": "Script",
                  "Handler": "Convert-GetDate.ps1"
                }
            ]
         },
         {
            "Verb": "New",
            "Noun": "Command3",
            "OriginalName":"<path><command>",
            "OutputHandlers": [
                {
                  "ParameterSetName": "viaFunction",
                  "HandlerType": "Function",
                  "Handler": "Convert-GetDate"
                }
            ]
         }
    ]
}

information


Both script and function use Get-Command
to determine the availability of the handler. Be sure that the handler may be found by Get-Command
before using Export-CrescendoModule.

For an example of working with an inline output handler, including parameters, see
Announcing PowerShell Crescendo Preview.1

Future plans

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

  • Improved tooling for discovery of Crescendo generated modules
  • Improved cmdlet support including New-CrescendoCommand and Export-CrescendoModule

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

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

AWS Contact Center Day – July 2021

This post was originally published on this site

AWS Contact Center Days

Earlier this week, I ordered from Amazon.fr a box of four toothpaste tubes, but only one was in the box. I called Amazon’s customer center. The agent immediately found my order without me having to share the long order number. She issued a refund and told me I even can keep the one tube I received, no return was needed.  As a customer, I can’t ask for better customer service.

Amazon strives to be the earth’s most customer-centric company, not only because it is the right thing to do for customers, but because over the long term, it’s good for the business. According to a Salesforce study, 80% of customers believe the experience a company provides is as important as its product or services. Over 90% of customers believe a positive customer service experience makes them more likely to make another purchase.

Just like me, you might have been delighted by Amazon customer service already. We know that you want fast, convenient support and it’s what makes you loyal.

This is why we created the AWS Contact Center Day conference. To learn from industry experts how to create your contact center of the future in a free on-demand video conference.

Amazon’s Contact Centers
Amazon’s contact centers are critical to our mission to be focused on customer experience. Our contact centers have more than 100,000 customer-service associates in 32 countries who support millions of customers in dozens of languages. Given the scale and our strict requirements for security, resiliency, flexibility, agility, or automation, we couldn’t purchase an off-the-shelf solution. We decided to build our own.

Everything that Amazon learned from our customer service organization, while looking to the future, has helped us bring to market Amazon Connect, an easy-to-use omnichannel cloud contact center that helps businesses provide superior customer service at a lower cost. As the notion of the contact center has evolved, so have the expectations of customers. The contact center of the future isn’t a collection of disparate point solutions for taking a call or a chat, and it isn’t just an application that consolidates those technologies. It’s a platform that makes it easy to integrate with your enterprise applications or system of record. The contact center of the future makes it easy to use customer data in real time to personalize and contextualize all customer experiences.

Contact Centers Best Practices
To further support business looking to improve their contact centers, Amazon designed our first contact center focused event, AWS Contact Contact Center Day, a way to share best practices, customer experience, and contact center technology, and to learn how to use Amazon Connect to accelerate the modernization of your contact centers.

The one-day conference took place on July 13, 2021 and brought together some of the most influential people invested in the future of contact centers including: Becky Ploeger, Global Head of Hilton Reservations and Customer Care, and member of the Customer Contact Week advisory board; Matt Dixon, Chief Research and Innovation Officer at Tethr, and author of multiple bestsellers, including The Challenger Sale; Customer service expert; author Shep Hyken, author of I’ll Be Back: How to Get Customers to Come Back Again and Again; Brian Solis, Global Innovation Evangelist, Salesforce, and best-selling author; and Mark Honeycutt, Director of Consumer Operations, Amazon.

At Amazon, we have gone through years of trial and error to get to where our customer experience stands today. This is why we wanted to share our experiences with you so that you can learn from our progress:

  • Customers want super-human service. You can now automate routine customer experience and agent tasks. When I call my airline for a rebooking after a delayed flight, I expect to be greeted by name. I expect the system to know my flight was delayed and to offer rebooking suggestions. This can happen automatically today, without involving a customer agent. These automatic chatbot systems are personalized per customer. They are dynamic because they answer customer questions before they ask, and they are natural because they are based on voice interactions, like conversations between humans.
  • Customers expect personalized engagement. Amazon Connect allows for fast and secure interactions with real-time voice biometric authentication. There is no need to go through a lengthy authentication questionnaire anymore. After the customer is authenticated, the customer service agent has a 360-degree view of the customer’s profile, integrating and displaying data from across the enterprise and using machine learning to provide the right information at the right moment.
  • Contact centers must evolve quickly to answer changing needs. Contact center interactions must take action based on real-time data or customer sentiment. Leaders want to experiment, learn, and improve using customer analytics and data.

Learn more
If you’re interested in learning more about contact center excellence, the entire Contact Center Day conference is now available on demand.

Check out the full agenda and watch a session now or learn more about Amazon Connect.

I am looking forward my next delightful customer experience using your contact centers.

— seb

AA21-201A: Chinese Gas Pipeline Intrusion Campaign, 2011 to 2013

This post was originally published on this site

Original release date: July 20, 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.

Note: CISA released technical information, including indicators of compromise (IOCs), provided in this advisory in 2012 to affected organizations and stakeholders.

This Joint Cybersecurity Advisory—coauthored by the Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI)—provides information on a spearphishing and intrusion campaign conducted by state-sponsored Chinese actors that occurred from December 2011 to 2013, targeting U.S. oil and natural gas (ONG) pipeline companies.

CISA and the FBI provided incident response and remediation support to a number of victims of this activity. Overall, the U.S. Government identified and tracked 23 U.S. natural gas pipeline operators targeted from 2011 to 2013 in this spearphishing and intrusion campaign. Of the known targeted entities, 13 were confirmed compromises, 3 were near misses, and 8 had an unknown depth of intrusion.

The U.S. Government has attributed this activity to Chinese state-sponsored actors. CISA and the FBI assess that these actors were specifically targeting U.S. pipeline infrastructure for the purpose of holding U.S. pipeline infrastructure at risk. Additionally, CISA and the FBI assess that this activity was ultimately intended to help China develop cyberattack capabilities against U.S. pipelines to physically damage pipelines or disrupt pipeline operations.

This advisory provides information on this campaign, including tactics, techniques, and procedures (TTPs) and IOCs. The TTPs remain relevant to help network defenders protect against intrusions. The IOCs are provided for historical awareness.

CISA and the FBI urge owners and operators of Energy Sector and other critical infrastructure (CI) networks to adopt a heightened state of awareness and implement the recommendations listed in the Mitigations section of this advisory, which include implementing network segmentation between IT and industrial control system (ICS)/operational technology (OT) networks. These mitigations will improve a CI entity’s defensive cyber posture and functional resilience by reducing the risk of compromise or severe operational degradation if the system is compromised by malicious cyber actors, including but not limited to actors associated with the campaign described in this advisory.

For more information on Chinese malicious cyber activity, see us-cert.cisa.gov/china.

Click here for a PDF version of this report.

Technical Details

In April 2012, CISA received reports about targeted attacks directed at multiple ONG pipeline sites; CISA (via a predecessor organization) and FBI provided incident response and remediation support to a number of victims from 2012 to 2013. CISA and FBI’s analysis of the malware and threat actor techniques identified that this activity was related to a spearphishing campaign. The U.S. Government identified and tracked 23 U.S. natural gas pipeline operators targeted in this campaign. Of the 23 known targeted entities, 13 were confirmed compromises, 3 were near misses, and 8 had an unknown depth of intrusion.

Threat Actor Activity

The spearphishing activity appears to have started in late December 2011. From December 9, 2011, through at least February 29, 2012, ONG organizations received spearphishing emails [T1566.002] specifically targeting their employees. The emails were at constructed with a high level of sophistication to convince employees to view malicious files [T1204.002]. Note: see the appendix for a table of the MITRE ATT&CK tactics and techniques observed in this campaign.

In addition to spearphishing, CISA and the FBI were made aware of social engineering attempts by malicious actors believed to be associated with this campaign. The apparent goal was to gain sensitive information from asset owners [T1598]. One asset owner reported that individuals in their network engineering department, including managers, received multiple phone calls requesting information about their recent network security practices. Other employees in other departments were not targeted. The asset owner also reported that these calls began immediately after they had identified and removed the malicious intruder from their network and performed a system-wide credential reset. The caller identified himself as an employee of a large computer security firm performing a national survey about network cybersecurity practices. He inquired about the organization’s policy and practices for firewall use and settings, types of software used to protect their network, and the use and type of intrusion detection and/or prevention systems. The caller was blocking his caller ID and when the targeted organization tried to return the call, they reached a number that was not in service.

During the investigation of these compromises, CISA and FBI personnel discovered that Chinese state-sponsored actors specifically collected [TA0009] and exfiltrated [TA0010] ICS-related information. The Chinese state-sponsored actors searched document repositories [T1213] for the following data types:

  • Document searches: “SCAD*”
  • Personnel lists
  • Usernames/passwords
  • Dial-up access information
  • System manuals

Based on incident data, CISA and FBI assessed that Chinese state-sponsored actors also compromised various authorized remote access channels, including systems designed to transfer data and/or allow access between corporate and ICS networks. Though designed for legitimate business purposes, these systems have the potential to be manipulated by malicious cyber actors if unmitigated. With this access, the Chinese state-sponsored actors could have impersonated legitimate system operators to conduct unauthorized operations. According to the evidence obtained by CISA and FBI, the Chinese state-sponsored actors made no attempts to modify the pipeline operations of systems they accessed. Note: there was a significant number of cases where log data was not available, and the depth of intrusion and persistent impacts were unable to be determined; at least 8 of 23 cases (35 percent) identified in the campaign were assessed as having an unknown depth of intrusion due to the lack of log data.

CISA and FBI assess that during these intrusions, China was successful in accessing the supervisory control and data acquisition (SCADA) networks at several U.S. natural gas pipeline companies.

Chinese actors also gained information specific to dial-up access, including phone numbers, usernames, and passwords [T1120]. Dial-up modems continue to be prevalent in the Energy Sector, providing direct access into the ICS environment with little or no security and no monitoring, which makes them an optimal vector for hold-at-risk operations. The exfiltrated data provided the capabilities for the Chinese cyber actors to access ONG operational systems at a level where they could potentially conduct unauthorized operations.

Exfiltrated Information and Assessed Motives

The Chinese actors specifically targeted information that pertained to access of ICSs. Searches were made for terms involving “SCAD*,” and the actors exfiltrated documents, including personnel lists, usernames and passwords, dial-up access information, remote terminal unit (RTU) sites, and systems manuals. The Chinese actors also exfiltrated information pertaining to ICS permission groups and compromised jump points between corporate and ICS networks. The totality of this information would allow the actors to access ICS networks via multiple channels and would provide sufficient access to allow them to remotely perform unauthorized operations on the pipeline with physical consequences.

CISA and FBI assess that these intrusions were likely intended to gain strategic access to the ICS networks for future operations rather than for intellectual property theft. This assessment was based on the content of the data that was being exfiltrated and the TTPs used to gain that access. One victim organization set up a honeypot that contained decoy documents with content that appeared to be SCADA-related data and sensitive organizational information. According to this organization, the SCADA-related decoy content was exfiltrated within 15 minutes of the time it was made available in the honeypot. Other sensitive decoy information, including financial and business-related information, was ignored.

CISA and FBI assess that this activity was ultimately intended to help China develop cyberattack capabilities against U.S. pipelines to physically damage pipelines or disrupt pipeline operations.

Indicators of Compromise

Table 1 lists indicators related to this spearphishing and intrusion campaign as of May 7, 2012, which are provided in this alert for historical completeness.

Table 1: IOCs from Chinese Gas Pipeline Intrusion Campaign, 2011 to 2013

Type Indicator Filename
Malware MD5:84873fae9cdecb84452fff9cca171004  ntshrui.dll  
Malicious email content, including any attachments and/or message body fpso.bigish[.]net  
Malware MD5:e12ce62cf7de42581c2fe1d7f36d521c  ntshrui.dll  

User agent string

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)  
User agent string Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)  
Named pipe ssnp  
Possible command and control (C2) domain

<xxx>.arrowservice[.]net

Where xxx is the targeted company name abbreviation

 
Malware MD5:7361a1f33d48802d061605f34bf08fb0   spoolsvd.exe
Malware 5e6a033fa01739d9b517a468bd812162 AdobeUpdater.exe
Malware e62afe2273986240746203f9d55496db ins.exe
Malware ed92d1242c0017668b93a72865b0876b px.exe
Malware 6818a9aef22c0c2084293c82935e84fe gh.exe
Malware fcbbfadc992e265c351e54598a6f6dfb fslist.exe
Malware 05476307f4beb3c0d9099270c504f055 u.exe
Malware 54db65a27472c9f3126df5bf91a773ea slm.exe
Malware a46a7045c0a3350c5a4c919fff2831a0 niu.exe
Malware 60456fe206a87f5422b214369af4260e ccApp1.exe
Malware d6eaadcbcf9ea9192db1bd5bb7462bf8 ntshrui.dll
Malware 52294de74a80beb1e579e5bca7c7248a moonclient2.exe
Malware e62afe2273986240746203f9d55496db inn.exe
Malware 5e6a033fa01739d9b517a468bd812162 kkk.exe
Malware 4a8854363044e4d66bf34a0cd331d93d inn.exe
Malware 124ad1778c65a83208dbefcec7706dc6 AcroRD32.exe
Malware 17199ddac616938f383a0339f416c890 iass.dll
Malicious email sender address “(name of victim company official)@yahoo.com”  
Malicious email content, including any attachments and/or message body “If not read this paper, pay attention.”  
Malicious email hyperlinked probable malware The hyperlink indicated a “.zip” file and contained the words “quality specifications” in reference to a particular component or product unique to the victim U.S. corporation.  
Malicious email signature block Contained the name, title, phone number, and corporate email address of an actual victim company official.  
Malicious attachment name   Project-seems-clear-for-takeoff.zip
Possible C2 domain <xxx>.arrowservice[dot]net
Where <xxx> may be the full name of the targeted company
 
Possible C2 domain <xxx>.federalres[.]org  
Possible C2 domain <xxx>.businessconsults[.]net
Where <xxx> may be the targeted company name abbreviation or full name
 
Possible C2 domain idahoanad[dot]org  
Possible C2 domain energyreview.strangled[.]net  
Possible C2 domain blackcake[.]net   
Possible C2 domain infosupports[.]com  
Malware 7caf4dbf53ff1dcd5bd5be92462b2995 iTunesHelper.exe 
Malware 99b58e416c5e8e0bcdcd39ba417a08ed Solarworldsummary.exe
Malware f0a00cfd891059b70af96b807e9f9ab8 smss.exe
Malware ea1b46fab56e7f12c4c2e36cce63d593 AcroRD32.exe
Malicious email content, including any attachments and/or message body  3d28651bb2d16eeaa6a35099c886fbaa Election_2012_Analysis.pdf
Possible C2 domain balancefitstudio[.]com  
Possible C2 domain res.federalres[.]org  
Possible C2 domain 18center[.]com  
Possible C2 domain milk.crabdance[.]com  
Possible C2 domain bargainblog[.com[.]au  
Possible C2 domain etrace-it[.]com  
Possible C2 domain picture.wintersline[.]com  
Possible C2 domain wish.happyforever[.]com  
Possible C2 domain mitchellsrus[.]com  
Possible C2 domain un.linuxd[.]org  
Malicious email content, including any attachments and/or message body    How_Can_Steelmakers_Compete_for_Growth_in_the_Steel_Sector_in_2012.zip
Malicious email content, including any attachments and/or message body    (Company Name)_Summary.zip
Malicious email content, including any attachments and/or message body  f5369e59a1ddca9b97ede327e98d8ffe Solarworldsummary.zip
Malicious email content, including any attachments and/or message body    (Company Name)_to_Sell_RNGMS_to_(Company Name).zip
Malicious email content, including any attachments and/or message body    Gift-Winter.zip
Malicious email content, including any attachments and/or message body    Happy_New_Year.zip
Malicious email content, including any attachments and/or message body    Debt_Crisis_Hits_US.zip
Malicious email content, including any attachments and/or message body    01-12-RATEALERT.zip
Malicious email content, including any attachments and/or message body  fni.itgamezone[.]net  

 

Mitigations

CISA and the FBI urge Energy Sector and other CI owners and operators to apply the following mitigations to implement a layered, defense-in-depth cyber posture. By implementing a layered approach, administrators will enhance the defensive cyber posture of their OT/ICS networks, reducing the risk of compromise or severe operational degradation if their system is compromised by malicious cyber actors.

  • Harden the IT/corporate network to reduce the risk of initial compromise.
    • Update all software, including operating systems, applications, and firmware, in a timely manner. Consider using a centralized patch management system.
    • Replace all end-of-life software and hardware devices.
    • Restrict and manage remote access software. Remote access tools are a common method for threat actors to gain initial access and persistence on target networks.
      • Manage and restrict users and groups who are permitted to access remote capabilities. Permissions should be limited to users that require the capability to complete their duties.
      • Require multi-factor authentication (MFA) for remote access.
      • Limit access to resources over networks, especially by restricting Remote Desktop Protocol (RDP). If RDP is operationally necessary, restrict the originating sources and require MFA.
    • Enable strong spam filters to prevent phishing emails from reaching end users.
    • Implement unauthorized execution prevention by:
      • Disabling macro scrips 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 malware locations, such as temporary folders supporting popular internet browsers.
    • 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 allow lists.
    • Set antivirus/antimalware programs to regularly scan IT network assets using up-to-date signatures.
  • 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 (NIST) Special Publication 800-82: Guide to ICS Security.
    • Use one-way communication diodes to prevent external access, whenever possible.
    • Set up demilitarized zones (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.
  • 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 filter 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 (SIEM) to monitor, analyze, and correlate event logs from across the ICS network to identify intrusion attempts.
  • Implement the following additional ICS environment best practices:
    • Update all software. Use a risk-based assessment strategy to determine which ICS network and assets and zones should participate in the patch management program.
      • Test all patches in off-line text environments before implementation.
    • Implement application allowlisting on human machine interfaces.
    • Harden 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. Require MFA for remote access to ICS networks.
    • Configure encryption and security for ICS protocols.
    • Use a risk-based asset inventory strategy to determine how OT network assets are identified and evaluated for the presence of malware.
    • Do not allow vendors to connect their devices to the ICS network. Use of a compromised device could introduce malware. 
    • Maintain an ICS asset inventory of all hardware, software, and supporting infrastructure technologies. 
    • 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.
    • Manage the supply chain by adjusting the ICS procurement process to weigh cybersecurity heavily as part of the scoring and evaluation methodology. Additionally, establish contractual agreements for all outsourced services that ensure proper incident handling and reporting, security of interconnections, and remote access specifications and processes.
  • Implement the following additional best practices:
    • Implement IP geo-blocking, as appropriate.
    • Implement regular, frequent data backup procedures on both the IT and ICS networks. Data backup procedures should address the following best practices:
      • Ensure backups are regularly tested.
      • Store backups separately, i.e., backups should be isolated from network connections that could enable spread of malware or lateral movement.
      • Maintain regularly updated “gold images” of critical systems in the event they need to be rebuilt.
      • Retain backup hardware to rebuild systems in the even rebuilding the primary system is not preferred.
    • Implement a user training program to train employees to recognize spearphishing attempts, discourage users from visiting malicious websites or opening malicious attachments, and re-enforce appropriate user response to spearphishing emails.

APPENDIX: Tactics and Techniques

Table 2 provides a summary of the MITRE ATT&CK tactics and techniques observed in this campaign.

Table 2: Observed MITRE ATT&CK tactics and techniques

Tactic Technique
Reconnaissance [TA0043] Phishing for Information [T1598]
Initial Access [TA0001] Phishing: Spearphishing Link [T1566.002]
Execution [TA0002] User Execution: Malicious File [T1204.002]
Discovery [TA0007] Peripheral Device Discovery [T1120]
Collection [TA0009] Information from Document Repositories [T1213]
Exfiltration  [TA0010]  

Revisions

  • Initial Version: July 20, 2021

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

Amazon EBS io2 Block Express Volumes with Amazon EC2 R5b Instances Are Now Generally Available

This post was originally published on this site

At AWS re:Invent 2020, we previewed Amazon EBS io2 Block Express volumes, the next-generation server storage architecture that delivers the first SAN built for the cloud. Block Express is designed to meet the requirements of the largest, most I/O-intensive, mission-critical deployments of Microsoft SQL Server, Oracle, SAP HANA, and SAS Analytics on AWS.

Today, I am happy to announce the general availability of Amazon EBS io2 Block Express volumes, with Amazon EC2 R5b instances powered by the AWS Nitro System to provide the best network-attached storage performance available on EC2. The io2 Block Express volumes now also support io2 features such as Multi-Attach and Elastic Volumes.

In the past, customers had to stripe multiple volumes together in order go beyond single-volume performance. Today, io2 volumes can meet the needs of mission-critical performance-intensive applications without striping and the management overhead that comes along with it. With io2 Block Express, customers can get the highest performance block storage in the cloud with four times higher throughput, IOPS, and capacity than io2 volumes with sub-millisecond latency, at no additional cost.

Here is a summary of the use cases and characteristics of the key Solid State Drive (SSD)-backed EBS volumes:

General Purpose SSD Provisioned IOPS SSD
Volume type gp2 gp3 io2 io2 Block Express
Durability 99.8%-99.9% durability 99.999% durability
Use cases General applications, good to start with when you do not fully understand the performance profile yet I/O-intensive applications and databases Business-critical applications and databases that demand highest performance
Volume size 1 GiB – 16 TiB 4 GiB – 16 TiB 4 GiB – 64 TiB
Max IOPS 16,000 64,000 ** 256,000
Max throughput 250 MiB/s * 1,000 MiB/s 1,000 MiB/s ** 4,000 MiB/s

* The throughput limit is between 128 MiB/s and 250 MiB/s, depending on the volume size.
** Maximum IOPS and throughput are guaranteed only on instances built on the Nitro System provisioned with more than 32,000 IOPS.

The new Block Express architecture delivers the highest levels of performance with sub-millisecond latency by communicating with an AWS Nitro System-based instance using the Scalable Reliable Datagrams (SRD) protocol, which is implemented in the Nitro Card dedicated for EBS I/O function on the host hardware of the instance. Block Express also offers modular software and hardware building blocks that can be assembled in many ways, giving you the flexibility to design and deliver improved performance and new features at a faster rate.

Getting Started with io2 Block Express Volumes
You can now create io2 Block Express volumes in the Amazon EC2 console, AWS Command Line Interface (AWS CLI), or using an SDK with the Amazon EC2 API when you create R5b instances.

After you choose the EC2 R5b instance type, on the Add Storage page, under Volume Type, choose Provisioned IOPS SSD (io2). Your new volumes will be created in the Block Express format.

Things to Know
Here are a couple of things to keep in mind:

  • You can’t modify the size or provisioned IOPS of an io2 Block Express volume.
  • You can’t launch an R5b instance with an encrypted io2 Block Express volume that has a size greater than 16 TiB or IOPS greater than 64,000 from an unencrypted AMI or a shared encrypted AMI. In this case, you must first create an encrypted AMI in your account and then use that AMI to launch the instance.
  • io2 Block Express volumes do not currently support fast snapshot restore. We recommend that you initialize these volumes to ensure that they deliver full performance. For more information, see Initialize Amazon EBS volumes in Amazon EC2 User Guide.

Available Now
The io2 Block Express volumes are available in all AWS Regions where R5b instances are available: US East (Ohio), US East (N. Virginia), US West (Oregon), Asia Pacific (Singapore), Asia Pacific (Tokyo), Europe (Frankfurt), with support for more AWS Regions coming soon. We plan to allow EC2 instances of all types to connect to io2 Block Volumes, and will have updates on this later in the year.

In terms of pricing and billing, io2 volumes and io2 Block Express volumes are billed at the same rate. Usage reports do not distinguish between io2 Block Express volumes and io2 volumes. We recommend that you use tags to help you identify costs associated with io2 Block Express volumes. For more information, see the Amazon EBS pricing page.

To learn more, visit the EBS Provisioned IOPS Volume page and io2 Block Express Volumes in the Amazon EC2 User Guide.

Channy

AA21-200B: Chinese State-Sponsored Cyber Operations: Observed TTPs

This post was originally published on this site

Original release date: July 19, 2021

Summary

This advisory uses the MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK®) framework, Version 9, and MITRE D3FEND™ framework, version 0.9.2-BETA-3. See the ATT&CK for Enterprise for all referenced threat actor tactics and techniques and the D3FEND framework for referenced defensive tactics and techniques.

The National Security Agency, Cybersecurity and Infrastructure Security Agency (CISA), and Federal Bureau of Investigation (FBI) assess that People’s Republic of China state-sponsored malicious cyber activity is a major threat to U.S. and Allied cyberspace assets. Chinese state-sponsored cyber actors aggressively target U.S. and allied political, economic, military, educational, and critical infrastructure (CI) personnel and organizations to steal sensitive data, critical and emerging key technologies, intellectual property, and personally identifiable information (PII). Some target sectors include managed service providers, semiconductor companies, the Defense Industrial Base (DIB), universities, and medical institutions. These cyber operations support China’s long-term economic and military development objectives.

This Joint Cybersecurity Advisory (CSA) provides information on tactics, techniques, and procedures (TTPs) used by Chinese state-sponsored cyber actors. This advisory builds on previous NSA, CISA, and FBI reporting to inform federal, state, local, tribal, and territorial (SLTT) government, CI, DIB, and private industry organizations about notable trends and persistent TTPs through collaborative, proactive, and retrospective analysis.

To increase the defensive posture of their critical networks and reduce the risk of Chinese malicious cyber activity, NSA, CISA, and FBI urge government, CI, DIB, and private industry organizations to apply the recommendations listed in the Mitigations section of this advisory and in Appendix A: Chinese State-sponsored Cyber Actors’ Observed Procedures. Note: NSA, CISA, and FBI encourage organization leaders to review CISA Joint Insights: Chinese Malicious Cyber Activity: Threat Overview for Leaders for information on this threat to their organization.

Click here for a PDF version of this report.

Technical Details

Trends in Chinese State-Sponsored Cyber Operations

NSA, CISA, and FBI have observed increasingly sophisticated Chinese state-sponsored cyber activity targeting U.S. political, economic, military, educational, and CI personnel and organizations. NSA, CISA, and FBI have identified the following trends in Chinese state-sponsored malicious cyber operations through proactive and retrospective analysis:

  • Acquisition of Infrastructure and Capabilities. Chinese state-sponsored cyber actors remain agile and cognizant of the information security community’s practices. These actors take effort to mask their activities by using a revolving series of virtual private servers (VPSs) and common open-source or commercial penetration tools.

  • Exploitation of Public Vulnerabilities. Chinese state-sponsored cyber actors consistently scan target networks for critical and high vulnerabilities within days of the vulnerability’s public disclosure. In many cases, these cyber actors seek to exploit vulnerabilities in major applications, such as Pulse Secure, Apache, F5 Big-IP, and Microsoft products. For information on Common Vulnerabilities and Exposures (CVE) known to be exploited by malicious Chinese state-sponsored cyber actors, see:

  • Encrypted Multi-Hop Proxies. Chinese state-sponsored cyber actors have been routinely observed using a VPS as an encrypted proxy. The cyber actors use the VPS as well as small office and home office (SOHO) devices as operational nodes to evade detection.

Observed Tactics and Techniques

Chinese state-sponsored cyber actors use a full array of tactics and techniques to exploit computer networks of interest worldwide and to acquire sensitive intellectual property, economic, political, and military information. Appendix B: MITRE ATT&CK Framework lists the tactics and techniques used by Chinese state-sponsored cyber actors. A downloadable JSON file is also available on the NSA Cybersecurity GitHub page.

Refer to Appendix A: Chinese State-Sponsored Cyber Actors’ Observed Procedures for information on procedures affiliated with these tactics and techniques as well as applicable mitigations.

Figure 1: Example of tactics and techniques used in various cyber operations.

 

Mitigations

NSA, CISA, and FBI urge federal and SLTT government, CI, DIB, and private industry organizations to apply the following recommendations as well as the detection and mitigation recommendations in Appendix A, which are tailored to observed tactics and techniques:

  • Patch systems and equipment promptly and diligently. Focus on patching critical and high vulnerabilities that allow for remote code execution or denial-of-service on externally facing equipment and CVEs known to be exploited by Chinese state-sponsored cyber actors. Consider implementing a patch management program that enables a timely and thorough patching cycle.
    Note: for more information on CVEs routinely exploited by Chinese state-sponsored cyber actors refer to the resources listed in the Trends in Chinese State-Sponsored Cyber Operations section.

  • Enhance monitoring of network traffic, email, and endpoint systems. Review network signatures and indicators for focused activities, monitor for new phishing themes, and adjust email rules accordingly. Follow the best practices of restricting attachments via email and blocking URLs and domains based upon reputation. Ensure that log information is aggregated and correlated to enable maximum detection capabilities, with a focus on monitoring for account misuse. Monitor common ports and protocols for command and control (C2) activity. SSL/TLS inspection can be used to see the contents of encrypted sessions to look for network-based indicators of malware communication protocols. Implement and enhance network and endpoint event analysis and detection capabilities to identify initial infections, compromised credentials, and the manipulation of endpoint processes and files.
  • Use protection capabilities to stop malicious activity. Implement anti-virus software and other endpoint protection capabilities to automatically detect and prevent malicious files from executing. Use a network intrusion detection and prevention system to identify and prevent commonly employed adversarial malware and limit nefarious data transfers. Use a domain reputation service to detect suspicious or malicious domains. Use strong credentials for service accounts and multi-factor authentication (MFA) for remote access to mitigate an adversary’s ability to leverage stolen credentials, but be aware of MFA interception techniques for some MFA implementations.▪

Resources

Refer to us-cert.cisa.gov/china, https://www.ic3.gov/Home/IndustryAlerts, and https://www.nsa.gov/What-We-Do/Cybersecurity/Advisories-Technical-Guidance/ for previous reporting on Chinese state-sponsored malicious cyber activity.

Disclaimer of Endorsement

The information and opinions contained in this document are provided “as is” and without any warranties or guarantees. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States Government, and this guidance shall not be used for advertising or product endorsement purposes.

Purpose

This document was developed by NSA, CISA, and FBI in furtherance of their respective cybersecurity missions, including their responsibilities to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.
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/.

Trademark Recognition

MITRE and ATT&CK are registered trademarks of The MITRE Corporation. • D3FEND is a trademark of The MITRE Corporation. • Microsoft, Microsoft Exchange, Office 365, Microsoft Office, OneDrive, Outlook, OWA, PowerShell, Windows Defender, and Windows are registered trademarks of Microsoft Corporation. • Pulse Secure is a registered trademark of Pulse Secure, LLC. • Apache is a registered trademark of Apache Software Foundation. • F5 and BIG-IP are registered trademarks of F5 Networks. • Cobalt Strike is a registered trademark of Strategic Cyber LLC. • GitHub is a registered trademark of GitHub, Inc. • JavaScript is a registered trademark of Oracle Corporation. • Python is a registered trademark of Python Software Foundation. • Unix is a registered trademark of The Open Group. • Linux is a registered trademark of Linus Torvalds. • Dropbox is a registered trademark of Dropbox, Inc.

APPENDIX A: Chinese State-Sponsored Cyber Actors’ Observed Procedures

Note: D3FEND techniques are based on the Threat Actor Procedure(s) and may not match automated mappings to ATT&CK techniques and sub-techniques.

Tactics: Reconnaissance [TA0043]    

Table 1: Chinese state-sponsored cyber actors’ Reconnaissance TTPs with detection and mitigation recommendations

Threat Actor
Technique / Sub-Techniques

Threat Actor Procedure(s)

Detection and Mitigation Recommendations

Defensive Tactics and Techniques

Active Scanning [T1595

Chinese state-sponsored cyber actors have been assessed to perform reconnaissance on Microsoft® 365 (M365), formerly Office® 365, resources with the intent of further gaining information about the networks. These scans can be automated, through Python® scripts, to locate certain files, paths, or vulnerabilities. The cyber actors can gain valuable information on the victim network, such as the allocated resources, an organization’s fully qualified domain name, IP address space, and open ports to target or exploit.

Minimize the amount and sensitivity of data available to external parties, for example: 

  • Scrub user email addresses and contact lists from public websites, which can be used for social engineering, 

  • Share only necessary data and information with third parties, and 

  • Monitor and limit third-party access to the network. 

Active scanning from cyber actors may be identified by monitoring network traffic for sources associated with botnets, adversaries, and known bad IPs based on threat intelligence.

Detect: 

  • Network Traffic Analysis

    • Connection Attempt Analysis [D3-CAA]

Isolate: 

  • Network Isolation

    • Inbound Traffic Filtering [D3-ITF]

Gather Victim Network Information [T1590]

 

Tactics: Resource Development [TA0042]

Table II: Chinese state-sponsored cyber actors’ Resource Development TTPs with detection and mitigation recommendations

Threat Actor
Technique / Sub-Techniques

Threat Actor Procedure(s)

Detection and Mitigation Recommendations

Defensive Tactics and Techniques

Acquire Infrastructure [T1583]

 

Chinese state-sponsored cyber actors have been observed using VPSs from cloud service providers that are physically distributed around the world to host malware and function as C2 nodes.

 

Adversary activities occurring outside the organization’s boundary of control and view makes mitigation difficult. Organizations can monitor for unexpected network traffic and data flows to and from VPSs and correlate other suspicious activity that may indicate an active threat.

 

N/A

Stage Capabilities [T1608]

Obtain Capabilities [T1588]: 

Chinese state-sponsored cyber actors have been observed using Cobalt Strike® and tools from GitHub® on victim networks. 

Organizations may be able to identify malicious use of Cobalt Strike by:

  • Examining network traffic using Transport Layer Security (TLS) inspection to identify Cobalt Strike. Look for human generated vice machine-generated traffic, which will be more uniformly distributed. 

  • Looking for the default Cobalt Strike TLS certificate. 

  • Look at the user agent that generates the TLS traffic for discrepancies that may indicate faked and malicious traffic.

  • Review the traffic destination domain, which may be malicious and an indicator of compromise.

  • Look at the packet’s HTTP host header. If it does not match with the destination domain, it may indicate a fake Cobalt Strike header and profile.

  • Check the Uniform Resource Identifier (URI) of the flow to see if it matches one associated with Cobalt Strike’s malleable C2 language. If discovered, additional recovery and investigation will be required.

 

N/A

Tactics: Initial Access [TA0001]

Table III: Chinese state-sponsored cyber actors’ Initial Access TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques

Threat Actor Procedure(s)

Detection and Mitigation Recommendations

Detection and Mitigation Recommendations

Drive By Compromise [T1189]

Chinese state-sponsored cyber actors have been observed gaining access to victim networks through watering hole campaigns of typo-squatted domains.

  • Ensure all browsers and plugins are kept up to date.
  • Use modern browsers with security features turned on.
  • Restrict the use of unneeded websites, block unneeded downloads/attachments, block unneeded JavaScript®, restrict browser extensions, etc.
  • Use adblockers to help prevent malicious code served through advertisements from executing. 
  • Use script blocking extensions to help prevent the execution of unneeded JavaScript, which may be used during exploitation processes. 
  • Use browser sandboxes or remote virtual environments to mitigate browser exploitation.
  • Use security applications that look for behavior used during exploitation, such as Windows Defender® Exploit Guard (WDEG).

Detect: 

  • Identifier Analysis
    • Homoglyph Detection [D3-HD]
    • URL Analysis [D3-UA]
  • File Analysis
    • Dynamic Analysis [D3-DA]

Isolate: 

  • Execution Isolation
    • Hardware-based Process Isolation [D3-HBPI]
    • Executable Allowlisting [D3-EAL]
  • Network Isolation

Exploit Public-Facing Application [T1190]

Chinese state-sponsored cyber actors have exploited known vulnerabilities in Internet-facing systems.[1] For information on vulnerabilities known to be exploited by Chinese state-sponsored cyber actors, refer to the Trends in Chinese State-Sponsored Cyber Operations section for a list of resources.
Chinese state-sponsored cyber actors have also been observed:

  • Using short-term VPS devices to scan and exploit vulnerable Microsoft Exchange® Outlook Web Access (OWA®) and plant webshells.

  • Targeting on-premises Identity and Access Management (IdAM) and federation services in hybrid cloud environments to gain access to cloud resources.

  • Deploying a public proof of concept (POC) exploit targeting a public-facing appliance vulnerability.

Review previously published alerts and advisories from NSA, CISA, and FBI, and diligently patch vulnerable applications known to be exploited by cyber actors. Refer to the Trends in Chinese State-Sponsored Cyber Operations section for a non-inclusive list of resources.

Additional mitigations include:

  • Consider implementing Web Application Firewalls (WAF), which can prevent exploit traffic from reaching an application.
  • Segment externally facing servers and services from the rest of the network with a demilitarized zone (DMZ).
  • Use multi-factor authentication (MFA) with strong factors and require regular re-authentication.
  • Disable protocols using weak authentication.
  • Limit access to and between cloud resources with the desired state being a Zero Trust model. For more information refer to NSA Cybersecurity Information Sheet: [Embracing a Zero Trust Security Model].
  • When possible, use cloud-based access controls on cloud resources (e.g., cloud service provider (CSP)-managed authentication between virtual machines).
  • Use automated tools to audit access logs for security concerns.
  • Where possible, enforce MFA for password resets.
  • Do not include Application Programing Interface (API) keys in software version control systems where they can be unintentionally leaked.

Harden:

  • Application Hardening [D3-AH]
  • Platform Hardening
    • Software Update [D3-SU]

Detect:

  • File Analysis [D3-FA
  • Network Traffic Analysis
    • Client-server Payload Profiling [D3-CSPP]
  • Process Analysis 
    • Process Spawn Analysis
    • Process Lineage Analysis [D3-PLA]

Isolate: 

  • Network Isolation
    • Inbound Traffic Filtering [D3-ITF]

Phishing [T1566]: 

Chinese state-sponsored cyber actors have been observed conducting spearphishing campaigns. These email compromise attempts range from generic emails with mass targeted phishing attempts to specifically crafted emails in targeted social engineering lures. 
These compromise attempts use the cyber actors’ dynamic collection of VPSs, previously compromised accounts, or other infrastructure in order to encourage engagement from the target audience through domain typo-squatting and masquerading. These emails may contain a malicious link or files that will provide the cyber actor access to the victim’s device after the user clicks on the malicious link or opens the attachment. 

  • Implement a user training program and simulated spearphishing emails to discourage users from visiting malicious websites or opening malicious attachments and re-enforce the appropriate user responses to spearphishing emails. Quarantine suspicious files with antivirus solutions.
  • Use a network intrusion prevention system (IPS) to scan and remove malicious email attachments.
  • Block uncommon file types in emails that are not needed by general users (.exe, .jar,.vbs)
  • Use anti-spoofing and email authentication mechanisms to filter messages based on validity checks of the sender domain (using Sender Policy Framework [SPF]) and integrity of messages (using Domain Keys Identified Mail [DKIM]). Enabling these mechanisms within an organization (through policies such as Domain-based Message Authentication, Reporting, and Conformance [DMARC]) may enable recipients (intra-org and cross domain) to perform similar message filtering and validation.
  • Determine if certain websites that can be used for spearphishing are necessary for business operations and consider blocking access if activity cannot be monitored well or if it poses a significant risk.
  • Prevent users from clicking on malicious links by stripping hyperlinks or implementing “URL defanging” at the Email Security Gateway or other email security tools.
  • Add external sender banners to emails to alert users that the email came from an external sender.

Harden: 

  • Message Hardening
    • Message Authentication [D3-MAN]
    • Transfer Agent Authentication [D3-TAAN]

Detect: 

  • File Analysis
    • Dynamic Analysis [D3-DA]
  • Identifier Analysis
    • Homoglyph Detection [D3-HD]
    • URL Analysis [D3-UA]
  • Message Analysis
    • Sender MTA Reputation Analysis [D3-SMRA]
    • Sender Reputation Analysis [D3-SRA]
       

External Remote Services [T1133]

Chinese state-sponsored cyber actors have been observed:

  • Exploiting vulnerable devices immediately after conducting scans for critical zero-day or publicly disclosed vulnerabilities. The cyber actors used or modified public proof of concept code in order to exploit vulnerable systems.

  • Targeting Microsoft Exchange offline address book (OAB) virtual directories (VDs).

  • Exploiting Internet accessible webservers using webshell small code injections against multiple code languages, including net, asp, apsx, php, japx, and cfm

Note: refer to the references listed above in Exploit Public-Facing Application [T1190] for information on CVEs known to be exploited by malicious Chinese cyber actors.

Note: this technique also applies to Persistence [TA0003].

  • Many exploits can be mitigated by applying available patches for vulnerabilities (such as CVE-2019-11510, CVE-2019-19781, and CVE-2020-5902) affecting external remote services.
  • Reset credentials after virtual private network (VPN) devices are upgraded and reconnected to the external network.
  • Revoke and generate new VPN server keys and certificates (this may require redistributing VPN connection information to users).
  • Disable Remote Desktop Protocol (RDP) if not required for legitimate business functions.
  • Restrict VPN traffic to and from managed service providers (MSPs) using a dedicated VPN connection.
  • Review and verify all connections between customer systems, service provider systems, and other client enclaves.

Harden:

  • Software Update [D3-SU]

Detect:

  • Network Traffic Analysis
    • Connection Attempt Analysis [D3-CAA]
  • Platform Monitoring [D3-PM]
  • Process Analysis
    • Process Spawn Analysis [D3-SPA
      • Process Lineage Analysis [D3-PLA]

Valid Accounts [T1078]:

Chinese state-sponsored cyber actors have been observed: gaining credential access into victim networks by using legitimate, but compromised credentials to access OWA servers, corporate login portals, and victim networks.

Note: this technique also applies to Persistence [TA0003], Privilege Escalation [TA0004], and Defense Evasion [TA0005].

  • Adhere to best practices for password and permission management.
  • Ensure that MSP accounts are not assigned to administrator groups and restrict those accounts to only systems they manage 
  • Do not store credentials or sensitive data in plaintext.
  • Change all default usernames and passwords.
  • Routinely update and secure applications using Secure Shell (SSH). 
  • Update SSH keys regularly and keep private keys secure.
  • Routinely audit privileged accounts to identify malicious use.

Harden: 

  • Credential Hardening
    • Multi-factor Authentication [D3-MFA]

Detect:

  • User Behavior Analysis [D3-UBA]
    • Authentication Event Thresholding [D3-ANET
    • Job Function Access Pattern Analysis [D3-JFAPA]

Tactics: Execution [TA0002]

Table IV: Chinese state-sponsored cyber actors’ Execution TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques

Threat Actor Procedure(s)

Detection and Mitigation Recommendations

Defensive Tactics and Techniques

Command and Scripting Interpreter [T1059]: 

Chinese state-sponsored cyber actors have been observed:

  • Using cmd.exe, JavaScript/Jscript Interpreter, and network device command line interpreters (CLI).

  • Using PowerShell to conduct reconnaissance, enumeration, and discovery of the victim network. 

  • Employing Python scripts to exploit vulnerable servers.

  • Using a UNIX shell in order to conduct discovery, enumeration, and lateral movement on Linux® servers in the victim network.

PowerShell

  • Turn on PowerShell logging. (Note: this works better in newer versions of PowerShell. NSA, CISA, and FBI recommend using version 5 or higher.)

  • Push Powershell logs into a security information and event management (SIEM) tool.

  • Monitor for suspicious behavior and commands. Regularly evaluate and update blocklists and allowlists.

  • Use an antivirus program, which may stop malicious code execution that cyber actors attempt to execute via PowerShell.

  • Remove PowerShell if it is not necessary for operations. 

  • Restrict which commands can be used.

Windows Command Shell

  • Restrict use to administrator, developer, or power user systems. Consider its use suspicious and investigate, especially if average users run scripts. 

  • Investigate scripts running out of cycle from patching or other administrator functions if scripts are not commonly used on a system, but enabled. 

  • Monitor for and investigate other unusual or suspicious scripting behavior. 

Unix

  • Use application controls to prevent execution.

  • Monitor for and investigate unusual scripting behavior. Use of the Unix shell may be common on administrator, developer, or power user systems. In this scenario, normal users running scripts should be considered suspicious. 

  • If scripts are not commonly used on a system, but enabled, scripts running out of cycle from patching or other administrator functions should be considered suspicious. 

Python

  • Audit inventory systems for unauthorized Python installations.

  • Blocklist Python where not required.

  • Prevent users from installing Python where not required.

JavaScript

  • Turn off or restrict access to unneeded scripting components.

  • Blocklist scripting where appropriate.

  • For malicious code served up through ads, adblockers can help prevent that code from executing.

Network Device Command Line Interface (CLI)

  • Use TACACS+ to keep control over which commands administrators are permitted to use through the configuration of authentication and command authorization.

  • Use an authentication, authorization, and accounting (AAA) systems to limit actions administrators can perform and provide a history of user actions to detect unauthorized use and abuse.

  • Ensure least privilege principles are applied to user accounts and groups.

Harden: 

  • Platform Hardening [D3-PH]

Detect: 

  • Process Analysis

    • Script Execution Analysis [D3-SEA]

Isolate:

  • Execution Isolation

    • Executable Allowlisting [D3-EAL]

Scheduled Task/Job [T1053]

Chinese state-sponsored cyber actors have been observed using Cobalt Strike, webshells, or command line interface tools, such as schtask or crontab to create and schedule tasks that enumerate victim devices and networks.

Note: this technique also applies to Persistence [TA0003] and Privilege Escalation [TA0004].

•    Monitor scheduled task creation from common utilities using command-line invocation and compare for any changes that do not correlate with known software, patch cycles, or other administrative activity.
•    Configure event logging for scheduled task creation and monitor process execution from svchost.exe (Windows 10) and Windows Task Scheduler (Older version of Windows) to look for changes in %systemroot%System32Tasks that do not correlate with known software, patch cycles, or other administrative activity. Additionally monitor for any scheduled tasks created via command line utilities—such as PowerShell or Windows Management Instrumentation (WMI)—that do not conform to typical administrator or user actions. 

Detect: 

  • Platform Monitoring
    • Operating System Monitoring [D3-OSM]
      • Scheduled Job Analysis [D3-SJA]
      • System Daemon Monitoring [D3-SDM]
      • System File Analysis [D3-SFA]

Isolate: 

  • Execution Isolation
    • Executable Allowlisting [D3-EAL]

User Execution [T1204]

Chinese state-sponsored cyber actors have been observed conducting spearphishing campaigns that encourage engagement from the target audience. These emails may contain a malicious link or file that provide the cyber actor access to the victim’s device after the user clicks on the malicious link or opens the attachment.

  • Use an antivirus program, which may stop malicious code execution that cyber actors convince users to attempt to execute.
  • Prevent unauthorized execution 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.
  • Use a domain reputation service to detect and block suspicious or malicious domains.
  • Determine if certain categories of websites are necessary for business operations and consider blocking access if activity cannot be monitored well or if it poses a significant risk.
  • Ensure all browsers and plugins are kept up to date.
  • Use modern browsers with security features turned on.
  • Use browser and application sandboxes or remote virtual environments to mitigate browser or other application exploitation.

Detect: 

  • File Analysis
  • Identifier Analysis
    • Homoglyph Detection [D3-HD]
    • URL Analysis [D3-UA]
  • Network Traffic Analysis

Isolate: 

  • Execution Isolation
    • Hardware-based Process Isolation [D3-HBPI]
    • Executable Allowlisting [D3-EAL]
  • Network Isolation

Tactics: Persistence [TA0003]

Table V: Chinese state-sponsored cyber actors’ Persistence TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Hijack Execution Flow [T1574]: 

Chinese state-sponsored cyber actors have been observed using benign executables which used Dynamic Link Library (DLL) load-order hijacking to activate the malware installation process. 

Note: this technique also applies to Privilege Escalation [TA0004] and Defense Evasion [TA0005].

  • Disallow loading of remote DLLs.
  • Enable safe DLL search mode.
  • Implement tools for detecting search order hijacking opportunities.
  • Use application allowlisting to block unknown DLLs.
  • Monitor the file system for created, moved, and renamed DLLs.
  • Monitor for changes in system DLLs not associated with updates or patches.
  • Monitor DLLs loaded by processes (e.g., legitimate name, but abnormal path).

Detect: 

  • Platform Monitoring
    • Operating System Monitoring
      • Service Binary Verification [D3-SBV]
  • Process Analysis
    • File Access Pattern Analysis [D3-FAPA]

Isolate: 

  • Execution Isolation
    • Executable Allowlisting [D3-EAL]

Modify Authentication Process [T1556]

  • Domain Controller Authentication [T1556.001]

Chinese state-sponsored cyber actors were observed creating a new sign-in policy to bypass MFA requirements to maintain access to the victim network.
Note: this technique also applies to Defense Evasion [TA0005] and Credential Access [TA0006].

  • Monitor for policy changes to authentication mechanisms used by the domain controller. 
  • Monitor for modifications to functions exported from authentication DLLs (such as cryptdll.dll and samsrv.dll).
  • Configure robust, consistent account activity audit policies across the enterprise and with externally accessible services. 
  • Look for suspicious account behavior across systems that share accounts, either user, admin, or service accounts (for example, one account logged into multiple systems simultaneously, multiple accounts logged into the same machine simultaneously, accounts logged in at odd times or outside of business hours). 
  • Correlate other security systems with login information (e.g., a user has an active login session but has not entered the building or does not have VPN access).
  • Monitor for new, unfamiliar DLL files written to a domain controller and/or local computer. Monitor for and correlate changes to Registry entries.

Detect: 

  • Process Analysis [D3-PA]
  • User Behavior Analysis
    • Authentication Event Thresholding [D3-ANET]
    • User Geolocation Logon Pattern Analysis [D3-UGLPA]  

Server Software Component [T1505]: 

Chinese state-sponsored cyber actors have been observed planting web shells on exploited servers and using them to provide the cyber actors with access to the victim networks. 

  • Use Intrusion Detection Systems (IDS) to monitor for and identify China Chopper traffic using IDS signatures.
  • Monitor and search for predictable China Chopper shell syntax to identify infected files on hosts.
  • Perform integrity checks on critical servers to identify and investigate unexpected changes.
  • Have application developers sign their code using digital signatures to verify their identity.
  • Identify and remediate web application vulnerabilities or configuration weaknesses. Employ regular updates to applications and host operating systems.
  • Implement a least-privilege policy on web servers to reduce adversaries’ ability to escalate privileges or pivot laterally to other hosts and control creation and execution of files in particular directories.
  • If not already present, consider deploying a DMZ between web-facing systems and the corporate network. Limiting the interaction and logging traffic between the two provides a method to identify possible malicious activity.
  • Ensure secure configuration of web servers. All unnecessary services and ports should be disabled or blocked. Access to necessary services and ports should be restricted, where feasible. This can include allowlisting or blocking external access to administration panels and not using default login credentials.
  • Use a reverse proxy or alternative service, such as mod_security, to restrict accessible URL paths to known legitimate ones.
  • Establish, and backup offline, a “known good” version of the relevant server and a regular change management policy to enable monitoring for changes to servable content with a file integrity system.
  • Employ user input validation to restrict exploitation of vulnerabilities.
  • Conduct regular system and application vulnerability scans to establish areas of risk. While this method does not protect against zero-day exploits, it will highlight possible areas of concern.
  • Deploy a web application firewall and conduct regular virus signature checks, application fuzzing, code reviews, and server network analysis.

Detect: 

  • Network Traffic Analysis
    • Client-server Payload Profiling [D3-CSPP]
    • Per Host Download-Upload Ratio Analysis [D3-PHDURA]
  • Process Analysis 
    • Process Spawn Analysis
      • Process Lineage Analysis [D3-PLA]

Isolate:

  • Network Isolation
    • Inbound Traffic Filtering [D3-ITF]

Create or Modify System Process [T1543]:

Chinese state-sponsored cyber actors have been observed executing malware shellcode and batch files to establish new services to enable persistence.

Note: this technique also applies to Privilege Escalation [TA0004].

  • Only allow authorized administrators to make service changes and modify service configurations. 
  • Monitor processes and command-line arguments for actions that could create or modify services, especially if such modifications are unusual in your environment.
  • Monitor WMI and PowerShell for service modifications.
Detect:

  • Process Analysis 
    • Process Spawn Analysis [D3-PSA]

Tactics: Privilege Escalation [TA0004]

Table VI: Chinese state-sponsored cyber actors’ Privilege Escalation TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Domain Policy Modification [T1484]

Chinese state-sponsored cyber actors have also been observed modifying group policies for password exploitation.

Note: this technique also applies to Defense Evasion [TA0005].

  • Identify and correct Group Policy Object (GPO) permissions abuse opportunities (e.g., GPO modification privileges) using auditing tools.
  • Monitor directory service changes using Windows event logs to detect GPO modifications. Several events may be logged for such GPO modifications.
  • Consider implementing WMI and security filtering to further tailor which users and computers a GPO will apply to.

Detect:

  • Network Traffic Analysis
    • Administrative Network Activity Analysis [D3-ANAA]
  • Platform Monitoring
    • Operating System Monitoring
      • System File Analysis [D3-SFA]

Process Injection [T1055]: 

Chinese state-sponsored cyber actors have been observed:

  • Injecting into the rundll32.exe process to hide usage of Mimikatz, as well as injecting into a running legitimate explorer.exe process for lateral movement.
  • Using shellcode that injects implants into newly created instances of the Service Host process (svchost)

Note: this technique also applies to Defense Evasion [TA0005].
 

  • Use endpoint protection software to block process injection based on behavior of the injection process.
  • Monitor DLL/Portable Executable (PE) file events, specifically creation of these binary files as well as the loading of DLLs into processes. Look for DLLs that are not recognized or not normally loaded into a process.
  • Monitor for suspicious sequences of Windows API calls such as CreateRemoteThread, VirtualAllocEx, or WriteProcessMemory and analyze processes for unexpected or atypical behavior such as opening network connections or reading files.
  • To minimize the probable impact of a threat actor using Mimikatz, always limit administrative privileges to only users who actually need it; upgrade Windows to at least version 8.1 or 10; run Local Security Authority Subsystem Service (LSASS) in protected mode on Windows 8.1 and higher; harden the local security authority (LSA) to prevent code injection.
  • Execution Isolation
    • Hardware-based Process Isolation [D3-HBPI]
    • Mandatory Access Control [D3-MAC]

Tactics: Defense Evasion [TA0005]

Table VII: Chinese state-sponsored cyber actors’ Defensive Evasion TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Deobfuscate/Decode Files or Information [T1140]

Chinese state-sponsored cyber actors were observed using the 7-Zip utility to unzip imported tools and malware files onto the victim device.

  • Monitor the execution file paths and command-line arguments for common archive file applications and extensions, such as those for Zip and RAR archive tools, and correlate with other suspicious behavior to reduce false positives from normal user and administrator behavior.
  • Consider blocking, disabling, or monitoring use of 7-Zip.

Detect: 

  • Process Analysis 
    • Process Spawn Analysis [D3-PSA]

Isolate: 

  • Execution Isolation
    • Executable Denylisting [D3-EDL]

Hide Artifacts [T1564]

Chinese state-sponsored cyber actors were observed using benign executables which used DLL load-order hijacking to activate the malware installation process.

  • Monitor files, processes, and command-line arguments for actions indicative of hidden artifacts, such as executables using DLL load-order hijacking that can activate malware.
  • Monitor event and authentication logs for records of hidden artifacts being used.
  • Monitor the file system and shell commands for hidden attribute usage.

Detect: 

  • Process Analysis
    • File Access Pattern Analysis [D3-FAPA

Isolate:

  • Execution Isolation
    • Executable Allowlisting [D3-EAL]

Indicator Removal from Host [T1070]

Chinese state-sponsored cyber actors have been observed deleting files using rm or del commands.
Several files that the cyber actors target would be timestomped, in order to show different times compared to when those files were created/used.

  • Make the environment variables associated with command history read only to ensure that the history is preserved.
  • Recognize timestomping by monitoring the contents of important directories and the attributes of the files. 
  • Prevent users from deleting or writing to certain files to stop adversaries from maliciously altering their ~/.bash_history or ConsoleHost_history.txt files.
  • Monitor for command-line deletion functions to correlate with binaries or other files that an adversary may create and later remove. Monitor for known deletion and secure deletion tools that are not already on systems within an enterprise network that an adversary could introduce.
  • Monitor and record file access requests and file handles. An original file handle can be correlated to a compromise and inconsistencies between file timestamps and previous handles opened to them can be a detection rule.

Detect: 

  • Platform Monitoring
    • Operating System Monitoring
      • System File Analysis [D3-SFA]
  • Process Analysis
    • File Access Pattern Analysis [D3-FAPA

Isolate:

  • Execution Isolation
    • Executable Allowlisting [D3-EAL]

Obfuscated Files or Information [T1027]

Chinese state-sponsored cyber actors were observed Base64 encoding files and command strings to evade security measures.

Consider utilizing the Antimalware Scan Interface (AMSI) on Windows 10 to analyze commands after being processed/interpreted.

Detect:

  • Process Analysis
    • File Access Pattern Analysis [D3-FAPA]

Signed Binary Proxy Execution [T1218]

Chinese state-sponsored cyber actors were observed using Microsoft signed binaries, such as Rundll32, as a proxy to execute malicious payloads.

Monitor processes for the execution of known proxy binaries (e.g., rundll32.exe) and look for anomalous activity that does not follow historically good arguments and loaded DLLs associated with the invocation of the binary.

Detect:

  • Process Analysis

    • File Access Pattern Analysis [D3-FAPA]

    • Process Spawn Analysis [D3-PSA

Tactics: Credential Access [TA0006]

Table VIII: Chinese state-sponsored cyber actors’ Credential Access TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Exploitation for Credential Access [T1212]

Chinese state-sponsored cyber actors have been observed exploiting Pulse Secure VPN appliances to view and extract valid user credentials and network information from the servers.

  • Update and patch software regularly.

  • Use cyber threat intelligence and open-source reporting to determine vulnerabilities that threat actors may be actively targeting and exploiting; patch those vulnerabilities immediately.

Harden: 

  • Platform Hardening

    • Software Update [D3-SU]

  • Credential Hardening

    • Multi-factor Authentication [D3-MFA]

OS Credential Dumping [T1003]
•    LSASS Memory [T1003.001]
•    NTDS [T1003.003]

Chinese state-sponsored cyber actors were observed targeting the LSASS process or Active directory (NDST.DIT) for credential dumping.

  • Monitor process and command-line arguments for program execution that may be indicative of credential dumping, especially attempts to access or copy the NDST.DIT.

  • Ensure that local administrator accounts have complex, unique passwords across all systems on the network.

  • Limit credential overlap across accounts and systems by training users and administrators not to use the same passwords for multiple accounts.

  • Consider disabling or restricting NTLM. 

  • Consider disabling WDigest authentication. 

  • Ensure that domain controllers are backed up and properly secured (e.g., encrypt backups).

  • Implement Credential Guard to protect the LSA secrets from credential dumping on Windows 10. This is not configured by default and requires hardware and firmware system requirements. 

  • Enable Protected Process Light for LSA on Windows 8.1 and Windows Server 2012 R2.

Harden:

  • Credential Hardening [D3-CH]

Detect: 

  • Process Analysis

    • File Access Pattern Analysis [D3-FAPA]

    • System Call Analysis [D3-SCA]

Isolate: 

  • Execution Isolation

    • Hardware-based Process Isolation [D3-HBPI]

    • Mandatory Access Control [D3-MAC]

Tactics: Discovery [TA0007]

Table IX: Chinese state-sponsored cyber actors’ Discovery TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

File and Directory Discovery [T1083]

Chinese state-sponsored cyber actors have been observed using multiple implants with file system enumeration and traversal capabilities.

Monitor processes and command-line arguments for actions that could be taken to gather system and network information. WMI and PowerShell should also be monitored.

Detect: 

  • User Behavior Analysis

    • Job Function Access Pattern Analysis [D3-JFAPA]

  • Process Analysis 

    • Database Query String Analysis [D3-DQSA]

    • File Access Pattern Analysis [D3-FAPA]

    • Process Spawn Analysis [D3-PSA]

Permission Group Discovery [T1069]

Chinese state-sponsored cyber actors have been observed using commands, including net group and net localgroup, to enumerate the different user groups on the target network. 

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 and PowerShell.

Detect: 

  • Process Analysis 

  • Process Spawn Analysis [D3-PSA]

    • System Call Analysis [D3-SCA]

  • User Behavior Analysis [D3-UBA]  

Process Discovery [T1057]

Chinese state-sponsored cyber actors have been observed using commands, including tasklist, jobs, ps, or taskmgr, to reveal the running processes on victim devices.

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 Windows Management Instrumentation and PowerShell. 

Detect: 

  • Process Analysis 

    • Process Spawn Analysis [D3-PSA]

    • System Call Analysis [D3-SCA]

  • User Behavior Analysis [D3-UBA]

Network Service Scanning [T1046]

Chinese state-sponsored cyber actors have been observed using Nbtscan and nmap to scan and enumerate target network information.

•    Ensure that unnecessary ports and services are closed to prevent discovery and potential exploitation.
•    Use network intrusion detection and prevention systems to detect and prevent remote service scans such as Nbtscan or nmap.
•    Ensure proper network segmentation is followed to protect critical servers and devices to help mitigate potential exploitation.

Detect: 

  • Network Traffic Analysis

    • Connection Attempt Analysis [D3-CAA]

Isolate:

  • Network Isolation

    • Inbound Traffic Filtering [D3-ITF]

Remote System Discovery [T1018]

Chinese state-sponsored cyber actors have been observed using Base-64 encoded commands, including ping, net group, and net user to enumerate target 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.

Detect: 

  • Process Analysis 

    • Process Spawn Analysis [D3-PSA]

  • User Behavior Analysis

    • Job Function Access Pattern Analysis [D3-JFAPA]

Tactics: Lateral Movement [TA0008]

Table X: Chinese state-sponsored cyber actors’ Lateral Movement TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Exploitation of Remote Services [T1210]

Chinese state-sponsored cyber actors used valid accounts to log into a service specifically designed to accept remote connections, such as telnet, SSH, RDP, and Virtual Network Computing (VNC). The actor may then perform actions as the logged-on user.

Chinese state-sponsored cyber actors also used on-premises Identity and Access Management (IdAM) and federation services in hybrid cloud environments in order to pivot to cloud resources.

Chinese state-sponsored cyber actors used valid accounts to log into a service specifically designed to accept remote connections, such as telnet, SSH, RDP, and Virtual Network Computing (VNC). The actor may then perform actions as the logged-on user.

Chinese state-sponsored cyber actors also used on-premises Identity and Access Management (IdAM) and federation services in hybrid cloud environments in order to pivot to cloud resources.

  • Disable or remove unnecessary services.

  • Minimize permissions and access for service accounts.

  • Perform vulnerability scanning and update software regularly.

  • Use threat intelligence and open-source exploitation databases to determine services that are targets for exploitation.

Detect: 

  • Network Traffic Analysis

    • Remote Terminal Session Detection [D3-RTSD

  • User Behavior Analysis [D3-UBA]

Isolate:

  • Execution Isolation

    • Mandatory Access Control [D3-MAC]

Tactics: Collection [TA0009]

Table XI: Chinese state-sponsored cyber actors’ Collection TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Archive Collected Data [T1560]

Chinese state-sponsored cyber actors used compression and encryption of exfiltration files into RAR archives, and subsequently utilizing cloud storage services for storage.

  • Scan systems to identify unauthorized archival utilities or methods unusual for the environment.

  • Monitor command-line arguments for known archival utilities that are not common in the organization’s environment.

Detect: 

  • Process Analysis 

    • File Access Pattern Analysis [D3-FAPA]

    • Process Spawn Analysis [D3-PSA]

Isolate:

  • Execution Isolation

    • Executable Denylisting [D3-EDL]

Clipboard Data [T1115]

Chinese state-sponsored cyber actors used RDP and execute rdpclip.exe to exfiltrate information from the clipboard.

  • Access to the clipboard is a legitimate function of many applications on an operating system. If an organization chooses to monitor for this behavior, then the data will likely need to be correlated against other suspicious or non-user-driven activity (e.g. excessive use of pbcopy/pbpaste (Linux) or clip.exe (Windows) run by general users through command line).

  • If possible, disable use of RDP and other file sharing protocols to minimize a malicious actor’s ability to exfiltrate data.

Detect:

  • Network Traffic Analysis

    • Remote Terminal Session Detection  [D3-RTSD]

Isolate:

  • Network Isolation

    • Inbound Traffic Filtering [D3-ITF]

    • Outbound Traffic Filtering [D3-OTF

Data Staged [T1074]

Chinese state-sponsored cyber actors have been observed using the mv command to export files into a location, like a compromised Microsoft Exchange, IIS, or emplaced webshell prior to compressing and exfiltrating the data from the target network.

Processes that appear to be reading files from disparate locations and writing them to the same directory or file may be an indication of data being staged, especially if they are suspected of performing encryption or compression on the files, such as using 7-Zip, RAR, ZIP, or zlib. Monitor publicly writeable directories, central locations, and commonly used staging directories (recycle bin, temp folders, etc.) to regularly check for compressed or encrypted data that may be indicative of staging.

Detect: 

  • Process Analysis

    • File Access Pattern Analysis [D3-FAPA]

Email Collection [T1114]

Chinese state-sponsored cyber actors have been observed using the New-MailboxExportRequest PowerShell cmdlet to export target email boxes.

  • Audit email auto-forwarding rules for suspicious or unrecognized rulesets.

  • Encrypt email using public key cryptography, where feasible.

  • Use MFA on public-facing mail servers.

Harden:

  • Credential Hardening

    • Multi-factor Authentication [D3-MFA]

  • Message Hardening

Detect: 

  • Process Analysis [D3-PA]

Tactics: Command and Control [TA0011]

Table XII: Chinese state-sponsored cyber actors’ Command and Control TTPs with detection and mitigation recommendations

Threat Actor Technique /
Sub-Techniques
 
Threat Actor Procedure(s) Detection and Mitigation Recommendations Defensive Tactics and Techniques

Application Layer Protocol [T1071]

Chinese state-sponsored cyber actors have been observed:

  • Using commercial cloud storage services for command and control.

  • Using malware implants that use the Dropbox® API for C2 and a downloader that downloads and executes a payload using the Microsoft OneDrive® API.

Use network intrusion detection and prevention systems with network signatures to identify traffic for specific adversary malware.

Detect: 

  • Network Traffic Analysis

    • Client-server Payload Profiling [D3-CSPP]

    • File Carving [D3-FC]

Isolate: 

  • Network Isolation

Ingress Tool Transfer [T1105]

Chinese state-sponsored cyber actors have been observed importing tools from GitHub or infected domains to victim networks. In some instances. Chinese state-sponsored cyber actors used the Server Message Block (SMB) protocol to import tools into victim networks.

  • Perform ingress traffic analysis to identify transmissions that are outside of normal network behavior. 

  • Do not expose services and protocols (such as File Transfer Protocol [FTP]) to the Internet without strong business justification.

  • Use signature-based network intrusion detection and prevention systems to identify adversary malware coming into the network.

Isolate:

  • Network Isolation

    • Inbound Traffic Filtering [D3-ITF]

Non-Standard Port [T1571]

Chinese state-sponsored cyber actors have been observed using a non-standard SSH port to establish covert communication channels with VPS infrastructure. 

  • Use signature-based network intrusion detection and prevention systems to identify adversary malware calling back to C2.

  • Configure firewalls to limit outgoing traffic to only required ports based on the functions of that network segment.

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

Detect:  

  • Network Traffic Analysis

    • Client-server Payload Profiling [D3-CSPP]

    • Protocol Metadata Anomaly Detection [D3-PMAD]

Isolate:

  • Network Isolation

    • Inbound Traffic Filtering [D3-ITF]

    • Outbound Traffic Filtering [D3-OTF]

Protocol Tunneling [T1572]

Chinese state-sponsored cyber actors have been observed using tools like dog-tunnel and dns2tcp.exe to conceal C2 traffic with existing network activity. 

  • Monitor systems for connections using ports/protocols commonly associated with tunneling, such as SSH (port 22). Also monitor for processes commonly associated with tunneling, such as Plink and the OpenSSH client.

  • Analyze packet contents to detect application layer protocols that do not follow the expected protocol standards.

  • Analyze network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server) 

Detect: 

  • Network Traffic Analysis

    • Protocol Metadata Anomaly Detection [D3-PMAD]

Proxy [T1090]: 

Chinese state-sponsored cyber actors have been observed using a network of VPSs and small office and home office (SOHO) routers as part of their operational infrastructure to evade detection and host C2 activity. Some of these nodes operate as part of an encrypted proxy service to prevent attribution by concealing their country of origin and TTPs.

Monitor traffic for encrypted communications originating from potentially breached routers to other routers within the organization. Compare the source and destination with the configuration of the device to determine if these channels are authorized VPN connections or other encrypted modes of communication.

  • Alert on traffic to known anonymity networks (such as Tor) or known adversary infrastructure that uses this technique.

  • Use network allow and blocklists to block traffic to known anonymity networks and C2 infrastructure.

Detect: 

  • Network Traffic Analysis

    • Protocol Metadata Anomaly Detection [D3-PMAD]

    • Relay Pattern Analysis [D3-RPA]

Isolate: 

  • Network Isolation

    • Outbound Traffic Filtering [D3-OTF]

Appendix B: MITRE ATT&CK Framework 

Figure 2: MITRE ATT&CK Enterprise tactics and techniques used by Chinese state-sponsored cyber actors (Click here for the downloadable JSON file.) 

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 Central@cisa.dhs.gov.

For NSA client requirements or general cybersecurity inquiries, contact the NSA Cybersecurity Requirements Center at 410-854-4200 or Cybersecurity_Requests@nsa.gov.

Media Inquiries / Press Desk:
•    NSA Media Relations, 443-634-0721, MediaRelations@nsa.gov
•    CISA Media Relations, 703-235-2010, CISAMedia@cisa.dhs.gov
•    FBI National Press Office, 202-324-3691, npo@fbi.gov

References

Revisions

  • July 19, 2021: Initial Version

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

Multi-Cloud and Hybrid Threat Protection with Sumo Logic Cloud SIEM Powered by AWS

This post was originally published on this site

IT security teams need to have a real-time understanding of what’s happening with their infrastructure and applications. They need to be able to find and correlate data in this continuous flood of information to identify unexpected behaviors or patterns that can lead to a security breach.

To simplify and automate this process, many solutions have been implemented over the years. For example:

  • Security information management (SIM) systems collect data such as log files into a central repository for analysis.
  • Security event management (SEM) platforms simplify data inspection and the interpretation of logs or events.

Many years ago these two approaches were merged to address both information analysis and interpretation of events. These security information and event management (SIEM) platforms provide real-time analysis of security alerts generated by applications, network hardware, and domain specific security tools such as firewalls and endpoint protection tools).

Today, I’d like to introduce a solution created by one of our partners: Sumo Logic Cloud SIEM powered by AWS. Sumo Logic Cloud SIEM provides deep security analytics and contextualized threat data across multi-cloud and hybrid environments to reduce the time to detect and respond to threats. You can use this solution to quickly detect and respond to the higher-priority issues, including malicious activities that negatively impact your business or brand. The solution comes with more than 300 out-of-the-box integrations, including key AWS services, and can help reduce time and effort required to conduct compliance audits for regulations such as PCI and HIPAA.

Sumo Logic Cloud SIEM is available in AWS Marketplace and you can use a free trial to evaluate the solution. Before having a look at how this works in practice, let’s see how it’s being used.

Customer Case Study – Medidata
I had the chance to meet a very interesting customer to talk about how they use Sumo Logic Cloud SIEM. Scott Sumner is the VP and CISO at Medidata, a company that is redefining what’s possible in clinical trials. Medidata is processing patient data for clinical trials of the Moderna and Johnson & Johnson COVID-19 vaccines, so you can see why security is a priority for them. With such critical workloads, the company must keep the trust of the people participating in those trials.

Scott told me, “There is an old saying: If you can’t measure it, you can’t manage it.” In fact, when he joined Medidata in 2015, one of the first things Scott did was to implement a SIEM. Medidata has been using Sumo Logic for more than five years now. They appreciate that it’s a cloud-native solution, and that has made it easier for them to follow the evolution of the tool over the years.

“Not having transparency in the environment you process data is not good for security professionals.” Scott wanted his team to be able to respond quickly and, to do so, they needed to be able to look at a single screen that displays all IP calls, network flows, and any relevant information. For example, Medidata has very aggressive checks for security scans and any kind of external access. To do so, they have to look not just at the perimeter, but at the entire environment. Sumo Logic Cloud SIEM allows them to react without breaking anything in their corporate environment, including the resources they have in more than 45 AWS accounts.

“One of the metrics that is floated around by security specialists is that you have up to five hours to respond to a tentative intrusion,” Scott says. “With Sumo Logic Cloud SIEM, we can match that time aggressively, and most of the times we respond within five minutes.” The ability to respond quickly allows Medidata to keep patient trust. This is very important for them, because delaying a clinical trial can affect people’s health.

Medidata security response is managed by a global team through three levels. Level 1 is covered by a partner who is empowered to block simple attacks. For the next level of escalation, Level 2, Medidata has a team in each region. Beyond that there is Level 3: a hardcore team of forensics examiners distributed across the US, Europe, and Asia who deal with more complicated attacks.

Availability is also important to Medidata. In addition to providing the Cloud SIEM functionality, Sumo Logic helps them monitor availability issues, such as web server failover, and very quickly figure out possible problems as they happen. Interestingly, they use Sumo Logic to better understand how applications talk with each other. These different use cases don’t complicate their setup because the security and application teams are segregated and use Sumo Logic as a single platform to share information seamlessly between the two teams when needed.

I asked Scott Sumner if Medidata was affected by the move to remote work in 2020 due to the COVID-19 pandemic. It’s an important topic for them because at that time Medidata was already involved in clinical trials to fight the pandemic. “We were a mobile environment anyway. A significant part of the company was mobile before. So, we were ready and not being impacted much by working remotely. All our tools are remote, and that helped a lot. Not sure we’d done it easily with an on-premises solution.”

Now, let’s see how this solution works in practice.

Setting Up Sumo Logic Cloud SIEM
In AWS Marketplace I search for “Sumo Logic Cloud SIEM” and look at the product page. I can either subscribe or start the one-month free trial. The free trial includes 1GB of log ingest for security and observability. There is no automatic conversion to paid offer when the free trials expires. After the free trial I have the option to either buy Sumo Logic Cloud SIEM from AWS Marketplace or remain as a free user. I create and accept the contract and set up my Sumo Logic account.

Console screenshot.

In the setup, I choose the Sumo Logic deployment region to use. The Sumo Logic documentation provides a table that describes the AWS Regions used by each Sumo Logic deployment. I need this information later when I set up the integration between AWS security services and Sumo Logic Cloud SIEM. For now, I select US2, which corresponds to the US West (Oregon) Region in AWS.

When my Sumo Logic account is ready, I use the Sumo Logic Security Integrations on AWS Quick Start to deploy the required integrations in my AWS account. You’ll find the source files used by this Quick Start in this GitHub repository. I open the deployment guide and follow along.

This architecture diagram shows the environment deployed by this Quick Start:

Architectural diagram.

Following the steps in the deployment guide, I create an access key and access ID in my Sumo Logic account, and write down my organization ID. Then, I launch the Quick Start to deploy the integrations.

The Quick Start uses an AWS CloudFormation template to create a stack. First, I check that I am in the right AWS Region. I use US West (Oregon) because I am using US2 with Sumo Logic. Then, I leave all default values and choose Next. In the parameters, I select US2 as my Sumo Logic deployment region and enter my Sumo Logic access ID, access key, and organization ID.

Console screenshot.

After that, I enable and configure the integrations with AWS security services and tools such as AWS CloudTrail, Amazon GuardDuty, VPC Flow Logs, and AWS Config.

Console screenshot.

If you have a delegate administrator with GuardDuty, you can enabled multiple member accounts as long as they are a part of the same AWS organization. With that, all findings from member accounts are vended to the delegate administrator and then to Sumo Logic Cloud SIEM through the GuardDuty events processor.

In the next step, I leave the stack options to their default values. I review the configuration and acknowledge the additional capabilities required by this stack (such as the creation of IAM resources) and then choose Create stack.

When the stack creation is complete, the integration with Sumo Logic Cloud SIEM is ready. If I had a hybrid architecture, I could connect those resources for a single point of view and analysis of my security events.

Using Sumo Logic Cloud SIEM
To see how the integration with AWS security services works, and how security events are handled by the SIEM, I use the amazon-guardduty-tester open-source scripts to generate security findings.

First, I use the included CloudFormation template to launch an Amazon Elastic Compute Cloud (Amazon EC2) instance in an Amazon Virtual Private Cloud (VPC) private subnet. The stack also includes a bastion host to provide external access. When the stack has been created, I write down the IP addresses of the two instances from the stack output.

Console screenshot.

Then, I use SSH to connect to the EC2 instance in the private subnet through the bastion host. There are easy-to-follow instructions in the README file. I use the guardduty_tester.sh script, installed in the instance by CloudFormation, to generate security findings for my AWS account.

$ ./guardduty_tester.sh

SSH screenshot.

GuardDuty processes these findings and the events are sent to Sumo Logic through the integration I just set up. In the Sumo Logic GuardDuty dashboard, I see the threats ready to be analyzed and addressed.

Console screenshot.

Availability and Pricing
Sumo Logic Cloud SIEM powered by AWS is a multi-tenant Software as a Service (SaaS) available in AWS Marketplace that ingests data over HTTPS/TLS 1.2 on the public internet. You can connect data from any AWS Region and from multi-cloud and hybrid architectures for a single point of view of your security events.

Start a free trial of Sumo Logic Cloud SIEM and see how it can help your security team.

Read the Sumo Logic team’s blog post here for more information on the service. 

Danilo