Aggregator

Endpoint Detection and Response systems (EDRs) are an essential part of modern cybersecurity strategies. EDR solutions gather and analyze data from endpoints to identify suspicious activities and provide real-time threat visibility. This allows security teams to respond quickly to incidents, investigate threats thoroughly, and mitigate the impact of potential breaches.

When attackers manage to disable or block EDR systems using tools like EDRSilencer or NimBlackout, it poses serious challenges to defenders. One major consequence is the loss of visibility into endpoint activities, which compromises the ability of cybersecurity teams to detect and respond to threats effectively. This diminished visibility can result in delayed detection of breaches, giving attackers more time to exfiltrate data or cause damage. Moreover, without the continuous monitoring and real-time alerts that EDRs provide, defenders are left with a reactive approach, often discovering incidents only after significant harm has been done. The ability of EDRs to facilitate immediate responses, such as isolating affected systems and stopping malicious processes, is also neutralized when these tools are blocked, leaving organizations more vulnerable to ongoing attacks. In such scenarios, the risk of prolonged, undetected breaches increases, complicating the efforts of defenders and escalating the potential damage to the organization’s security posture.

This blog isn’t going to cover every EDR based tool in an attackers arsenal, but there are some common ones that have been observed recently. Attackers and Defenders are in a constant game of cat and mouse when it comes to tools and techniques. Fortunately, with these techniques there are some common indicators that can still be detected irregardless of the tool used.

Tools

Here are the tools we will be taking a look at. Many of these have been observed in use in the wild.

EDRSilencer — Inspired by the closed source FireBlock tool FireBlock from MdSec NightHawk, this tool was created with the aim of blocking the outbound traffic of running EDR processes using Windows Filtering Platform (WFP) APIs.

EDRSandBlast — Written in C. It weaponizes a vulnerable signed driver to bypass EDR detections (Notify Routine callbacks, Object Callbacks and ETW TI provider) and LSASS protections. Multiple userland unhooking techniques are also implemented to evade userland monitoring.

NimBlackout — An adaptation of the @Blackout project which consists of removing AV/EDRs using the gmer (BYOVD) driver.

AuKill — The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.

EDRSilencer

The main features of this tool is searching for running EDR processes and applying Windows Filtering Platform (WFP) filters to block outbound traffic, adding filters for specific processes, and removing filters either individually or globally. The tool includes a custom implementation to avoid file handle access issues with EDR processes by bypassing the CreateFileW API. It supports a wide range of EDRs, including Microsoft Defender, Carbon Black, SentinelOne, and more.

EDRSilencer Adding WFP Filters

By creating custom WFP filters, attackers can selectively intercept and drop network packets sent by EDR processes, effectively preventing them from communicating with their management servers or security dashboards. This disruption stops the EDR from sending telemetry data, alerts, or incident logs, thereby silencing its ability to notify defenders of suspicious or malicious activities occurring on the endpoints. Such interference can be stealthy, as it can be crafted to target only specific processes or traffic patterns associated with the EDR, ensuring other legitimate network operations remain unaffected. By exploiting WFP in this manner, attackers can maintain prolonged access to a compromised system without detection, allowing them to escalate their attacks, exfiltrate data, or cause further damage without triggering the EDR’s defensive mechanisms.

Fortunately, there are a few pieces of telemetry that sneak through before the EDR is silenced. One such piece is Windows Event 5447 which identifies when a WFP filter has been changed. In the case of EDRSilencer there is a very specific filter that is added.

Action: %%16389
ActivityID: "9F3364FE-E417-0002-2065-339F17E4DA01"
CalloutKey: 00000000-0000-0000-0000-000000000000
CalloutName: -
ChangeType: %%16384
Channel: Security
Conditions: Condition ID: {d78e1e87-8644-4ea5-9437-d809ecefc971}
Match value: Equal to
Condition value:
00000000 5c 00 64 00 65 00 76 00-69 00 63 00 65 00 5c 00 \.d.e.v.i.c.e.\.
00000010 68 00 61 00 72 00 64 00-64 00 69 00 73 00 6b 00 h.a.r.d.d.i.s.k.
00000020 76 00 6f 00 6c 00 75 00-6d 00 65 00 31 00 5c 00 v.o.l.u.m.e.1.\.
00000030 70 00 72 00 6f 00 67 00-72 00 61 00 6d 00 64 00 p.r.o.g.r.a.m.d.
00000040 61 00 74 00 61 00 5c 00-6d 00 69 00 63 00 72 00 a.t.a.\.m.i.c.r.
00000050 6f 00 73 00 6f 00 66 00-74 00 5c 00 77 00 69 00 o.s.o.f.t.\.w.i.
00000060 6e 00 64 00 6f 00 77 00-73 00 20 00 64 00 65 00 n.d.o.w.s. .d.e.
00000070 66 00 65 00 6e 00 64 00-65 00 72 00 5c 00 70 00 f.e.n.d.e.r.\.p.
00000080 6c 00 61 00 74 00 66 00-6f 00 72 00 6d 00 5c 00 l.a.t.f.o.r.m.\.
00000090 34 00 2e 00 31 00 38 00-2e 00 32 00 34 00 30 00 4...1.8...2.4.0.
000000a0 36 00 30 00 2e 00 37 00-2d 00 30 00 5c 00 6d 00 6.0...7.-.0.\.m.
000000b0 73 00 6d 00 70 00 65 00-6e 00 67 00 2e 00 65 00 s.m.p.e.n.g...e.
000000c0 78 00 65 00 00 00 x.e...
Error_Code: -
EventID: 5447
EventRecordID: 763263
FilterId: 67700
FilterKey: 795B7AA5-86D4-4383-BD45-FA5FE4AA7509
FilterName: Custom Outbound Filter
FilterType: %%16387
Keywords: 0x8020000000000000
LayerId: 48
LayerKey: C38D57D1-05A7-4C33-904F-7FBCEEE60E82
LayerName: ALE Connect v4 Layer
Level: 0
...

EDRSilencer by default will create its filters with the FilterName of “Custom Outbound Filter”. You can also see the process being filtered in the Condition Value, in this case msmpeng.exe (Defender).

Another detection opportunity is the command line arguments and process information from when the tool is launched. It is pretty unusual for a benign process to have a argument called blockedr.

...
Caller_Domain: WIN10-21H1
Caller_User_Name: localuser
Channel: Security
CommandLine: EDRSilencer.exe blockedr
EventID: 4688
NewProcessName: C:\Users\localuser\Desktop\EDRSilencer.exe
Opcode: 0
ParentProcessName: C:\Windows\System32\cmd.exe
ProcessID: "4"
ProcessId: 10416
Process_Command_Line: EDRSilencer.exe blockedr
TokenElevationType: %%1936
...

For more logs, details, and detections, we have captured this activity in our platform here.

EDRSandBlast

This tool can also use WFP to block communication of EDRs. It will enumerate EDRs and create filters for every service and process of the EDR.

EDRSandBlast Adding WFP Filters

This will create very similar logs as EDRSilencer in Windows Event 5447 but on a larger scale since it will do it for every subprocess of the EDR. However, since it is enumerating the EDR services it will access the EDR process in a way that is logged. In Sysmon this will be EventCode 10.

CallTrace: C:\Windows\SYSTEM32\ntdll.dll+9d234|C:\Windows\System32\KERNELBASE.dll+2c0fe|C:\Users\localuser\EDRSandblast.exe+5eb1f|C:\Users\localuser\EDRSandblast.exe+5fb11|C:\Users\localuser\EDRSandblast.exe+5b106|C:\Users\localuser\EDRSandblast.exe+74c68|C:\Windows\System32\KERNEL32.DLL+17034|C:\Windows\SYSTEM32\ntdll.dll+52651
Channel: Microsoft-Windows-Sysmon/Operational
EventCode: 10
EventDescription: ProcessAccess
EventID: 10
EventRecordID: 1589884
GrantedAccess: 0x1000
ProcessID: "3452"
ProcessId: 1424
ProcessName: EDRSandblast.exe
ProcessPath: C:\Users\localuser\
SourceImage: C:\Users\localuser\EDRSandblast.exe
SourceProcessGUID: F51F9151-1307-6729-E915-000000000D00
SourceProcessId: 1424
SourceThreadId: 2064
SourceUser: WIN10-21H1\localuser
SystemTime: '2024-11-04T18:31:36.252633Z'
TargetImage: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe
TargetProcessGUID: F51F9151-10B7-6729-0303-000000000D00
TargetProcessId: 6424
TargetUser: NT AUTHORITY\SYSTEM
...

In addition to the methods of detection mentioned, you can also identify these WFP Filters through the registry. They will create an entry under HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{GUID} as seen here.

Channel: Microsoft-Windows-Sysmon/Operational
Details: v2.30|Action=Block|Active=TRUE|Dir=In|App=C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe|Name=wYLqwn43kCmugxYqisuL|Desc=wYLqwn43kCmugxYqisuL|
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventType: SetValue
Image: C:\Windows\system32\svchost.exe
ProcessGuid: F51F9151-1EDC-6733-2300-000000000F00
SystemTime: '2024-11-12T14:50:37.718504Z'
TargetObject: HKLM\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules\{19876A6F-6871-4C48-A9EB-B1FFF949759C}
...

For more logs, details, and detections, we have captured this activity in our platform here.

EDRSandBlast also has a technique to perform LSASS dumping without triggering Credential Dumping activity alerts. EDRSandBlast enumerates the Kernel “Notify Routines” callbacks and remove any callback routine linked to a predefined list of EDR drivers (more than 1000 drivers of security products supported, see the EDR driver detection section. The enumeration and removal are made possible through the exploitation of an arbitrary Kernel memory read / write primitive provided by the exploitation of a vulnerable driver (see Vulnerable drivers section).

Vulnerable Driver Load

Here we can see the tool creating the malicious service and loading the vulnerable driver.

LSASS Dumped

Afterwards it uses this driver to remove those callback routines and make the process safe. Then lsass.exe is access and dumped to the current directory. Once done the service and driver are removed.

These activities will still create some logs despite the efforts of the tool to hide activity. The first we can look at is the service creation for the kernel driver (Windows Event 7045)

Channel: System
EventCode: 7045
EventRecordID: 6244
EventSourceName: "Service Control Manager"
ImagePath: C:\Users\localuser\gdrv.sys
Keywords: 0x8080000000000000
Level: 4
Name: "Service Control Manager"
Opcode: 0
ProcessID: "720"
ProcessId: 720
Qualifiers: "16384"
RecordNumber: 6244
ServiceName: bx92yOn6
ServiceType: kernel mode driver
SigmaEventCode: 7045
StartType: auto start
SystemTime: '2024-11-04T18:27:21.800918Z'
Task: 0
ThreadID: "4852"
UserID: "S-1-5-21-1538153195-943065003-848949206-1000"
Version: 0
dest: WIN10-21H1.snapattack.labs
...

Here we can see the driver being loaded from an unusual location (C:\Users\localuser\gdrv.sys) as a kernel mode driver with a start type of auto start. The combination of auto start with kernel mode should be investigated but adding in a known vulnerable driver really makes this stand out. This technique is commonly referred to as a "bring your own vulnerable driver" (BYOVD) attack. The LOLDrivers project contains a massive list of information about these known drivers including names and hashes.

For more logs, details, and detections, we have captured this activity in our platform here.

Blackout/NimBlackout

These tools leverage a different driver, gmer, to effectively disable or kill EDRs and Antiviruses. It uses a very similar approach to EDRSandBlast by loading a kernel mode driver and then exploiting the vulnerable driver to accomplish something it normally wouldn’t have permission to. In the particular case of this tool, it will repeatedly terminate the specified process over and over. Likely targets for this are EDR and AntiVirus products.

NimBlackout Killing Defender

If you have telemetry for registry activity you can actually see the service creation keys as well with EventCode 13. These tools will both use the Blackout.sys driver as the ImagePath.

Channel: Microsoft-Windows-Sysmon/Operational
Details: \??\C:\Users\Public\Blackout.sys
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventRecordID: 26269
EventType: SetValue
Image: C:\Windows\system32\services.exe
Keywords: 0x8000000000000000
ProcessName: services.exe
ProcessPath: C:\Windows\system32\
SystemTime: '2023-07-11T17:46:23.006634Z'
TargetObject: HKLM\System\CurrentControlSet\Services\NimBlackout\ImagePath
User: NT AUTHORITY\SYSTEM
UserID: "S-1-5-18"
action: modified
user: SYSTEM
user_id: "S-1-5-18"
vendor_product: Microsoft Sysmon
...

If you have telemetry for Windows Events you can monitor for termination of your EDR Processes. This is Event Id 4689, and here we can see the Defender process from our execution being killed.

EventCode: 4689
Logon_ID: 0x3e7
Name: "Microsoft-Windows-Security-Auditing"
ProcessID: "4"
ProcessId: 8624
ProcessName: C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.23050.5-0\MsMpEng.exe
Status: 0x0
SubjectDomainName: SNAPATTACK
SubjectLogonId: 0x3e7
SubjectUserName: QUADRA$
SubjectUserSid: S-1-5-18
SystemTime: '2023-07-11T17:46:24.779760Z'
Task: 13313
ThreadID: "9060"
name: A process has exited
status: success
subject: A process has exited
...

For more logs, details, and detections, we have captured this activity in our platform here.

Threat Actor Tools — AuKill

While all the tools covered so far have been open source tools, or educational experiments, these techniques are being actively used by threat actors. One such example is a tool dubbed AuKill by Sophos discussed here. However, this tool uses many of the techniques covered in this blog and includes many of the same detection opportunities.

The AuKill tool abuses an outdated version of the driver used by version 16.32 of the Microsoft utility, Process Explorer, to disable EDR processes before deploying either a backdoor or ransomware on the target system.

The method of abusing the Process Explorer driver to bypass EDR systems isn’t new; it was implemented in many open-source tools. AuKill possibly uses multiple code snippets from, and built their malware around, the core technique introduced by Backstab. AuKill drops a driver named PROCEXP.SYS (from the release version 16.32 of process Explorer) into the C:\Windows\System32\drivers path. The legitimate Process Explorer driver is named PROCEXP152.sys, and normally is found in the same location. Both drivers can be present on a machine that has a copy of Process Explorer running. The AuKill installer also drops an executable copy of itself to either the System32 or the TEMP directory, which it runs as a service as seen below.

EventCode: 4697
ProcessId: 660
ServiceAccount: LocalSystem
ServiceFileName: C:\Windows\system32\auSophos.exe
ServiceName: auSophos
ServiceStartType: 2
ServiceType: 0x10
SubjectDomainName: SNAPATTACK
SubjectLogonId: 0x3e7
SubjectUserName: MSEDGEWIN10$
SubjectUserSid: S-1-5-18
SystemTime: '2023-04-26 15:25:24.920066 UTC'
action: success
name: A service was installed in the system
product: Windows
service: auSophos
service_name: auSophos
sigma_product: windows
sigma_service: security
start_mode: auto
status: started

Another interesting thing that this tool does that we hadn’t seen in many of the open source tools was disabling the Windows Update Service. This can be seen in a registry key change.

Details: DWORD (0x00000004)
EventCode: 13
EventDescription: RegistryEvent (Value Set)
EventType: SetValue
Image: C:\Windows\system32\services.exe
ProcessId: 636
ProcessName: services.exe
ProcessPath: C:\Windows\system32\
SystemTime: '2023-04-26 15:25:43.001866 UTC'
TargetObject: HKLM\System\CurrentControlSet\Services\wuauserv\Start
Task: 13
User: NT AUTHORITY\SYSTEM
UserID: "S-1-5-18"
action: modified
...

This value change disables the automatic starting of the update service. This can prevent future security updates that might mess with an attacker’s access.

For more logs, details, and detections, we have captured this activity in our platform here.

MITRE

T1562.001: Impair Defenses: Disable or Modify Tools
Adversaries may modify and/or disable security tools to avoid possible detection of their malware/tools and activities

T1562.004: Impair Defenses: Disable or Modify System Network Configurations
Adversaries may disable or modify system firewalls in order to bypass controls limiting network usage.

T1569: System Services
Adversaries may abuse system services or daemons to execute commands or programs.

T1112: Modify Registry
Adversaries may interact with the Windows Registry to hide configuration information within Registry keys, remove information as part of cleaning up, or as part of other techniques to aid in persistence and execution.

Conclusion

The tools and techniques used by attackers to bypass or disable EDRs underscore the continuous and evolving struggle between cybersecurity defenses and adversarial tactics. By exploiting legitimate system features, such as the Windows Filtering Platform, attackers can effectively neutralize critical EDR functions, creating blind spots. However, defenders are not without recourse. While these tools aim to obscure their activities, certain logs and registry modifications still offer valuable indicators of compromise. Monitoring for these signals — like specific WFP filters, unusual process behaviors, or suspicious service creations — can help defenders detect these evasive tactics. Having a strong detection workflow is paramount to catch these sorts of attacks, especially when they are attacking the EDRs themselves.

SnapAttack is the threat hunting, detection engineering, and detection validation platform for proactive threat-informed defense. Register for a FREE community account to access the tons of content included in this blog post, as well as thousands of other detections. Subscribers also get advanced features like a no-code detection builder, one-click deployments to leading SIEMs and EDRs like Chronicle, Sentinel, Splunk, CrowdStrike and SentinelOne, advanced threat profiles to prioritize relevant threats, and customized reports that track MITRE ATT&CK coverage and more!

Resources

GitHub - Helixo32/NimBlackout: Kill AV/EDR leveraging BYOVD attack
'AuKill' EDR killer malware abuses Process Explorer driver
GitHub - wavestone-cdt/EDRSandblast
TA Phone Home: EDR Evasion Testing Reveals Extortion Actor's Toolkit
GitHub - netero1010/EDRSilencer: A tool uses Windows Filtering Platform (WFP) to block Endpoint Detection and Response (EDR) agents from reporting security events to the server.
Nighthawk 0.2.6 - Three Wise Monkeys - MDSec

Blinded by Silence was originally published in SnapAttack on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Blinded by Silence appeared first on Security Boulevard.

Raven Tait

Randall Munroe’s XKCD ‘Geometriphylogenetics’

Security Boulevard

1 year 7 months ago

via the comic humor & dry wit of Randall Munroe, creator of XKCD

Permalink

The post Randall Munroe’s XKCD ‘Geometriphylogenetics’ appeared first on Security Boulevard.

Marc Handelman

The Vendor's Role in Combating Alert Fatigue

darkreading

1 year 7 months ago

As alerts pile up, the complexity can overwhelm security professionals, allowing real threats to be missed. This is where vendors must step up.

Supradeep Bokkasam

Уравнение жизни: как темная энергия определяет судьбу цивилизаций

Securitylab.ru

1 year 7 months ago

Учёные измерили шансы появления разумной жизни в нашей вселенной.

Busting Ransomware’s Billion-Dollar Boom with Network Observability and Security

Security Boulevard

1 year 7 months ago

Ransomware-as-a-service (RaaS) is the first example of a specific threat becoming a financially viable business model. The subscription model approach has propelled ransomware to be one of the most pervasive cyber threats of our time, evolving over the last decade to include mainstream SaaS capabilities that enable user success, such as 24/7 helpdesk support, training, and documentation.

The post Busting Ransomware’s Billion-Dollar Boom with Network Observability and Security appeared first on Netography.

The post Busting Ransomware’s Billion-Dollar Boom with Network Observability and Security appeared first on Security Boulevard.

Mal Fitzgerald

ДНК-дискриминация: генетические тесты лишают американцев страховки

Securitylab.ru

1 year 7 months ago

Что важнее для страховщиков и работодателей: деньги или человечность?

CVE-2024-49881 | Linux Kernel up to 6.11.2 ext4_find_extent orig_path null pointer dereference (Nessus ID 210940)

Vuldb Updates

1 year 7 months ago

A vulnerability was found in Linux Kernel up to 6.11.2. It has been rated as critical. This issue affects the function ext4_find_extent. The manipulation of the argument orig_path leads to null pointer dereference. The identification of this vulnerability is CVE-2024-49881. The attack can only be initiated within the local network. There is no exploit available. It is recommended to upgrade the affected component.

vuldb.com

CVE-2024-9693 | GitLab Community Edition/Enterprise Edition up to 17.3.6/17.4.3/17.5.1 authorization (Issue 497449 / Nessus ID 210944)

Vuldb Updates

1 year 7 months ago

A vulnerability, which was classified as critical, was found in GitLab Community Edition and Enterprise Edition up to 17.3.6/17.4.3/17.5.1. This affects an unknown part. The manipulation leads to incorrect authorization. This vulnerability is uniquely identified as CVE-2024-9693. It is possible to initiate the attack remotely. There is no exploit available. It is recommended to upgrade the affected component.

vuldb.com

Experts Uncover 70,000 Hijacked Domains in Widespread 'Sitting Ducks' Attack Scheme

The Hackers News

1 year 7 months ago

Multiple threat actors have been found taking advantage of an attack technique called Sitting Ducks to hijack legitimate domains for using them in phishing attacks and investment fraud schemes for years. The findings come from Infoblox, which said it identified nearly 800,000 vulnerable registered domains over the past three months, of which approximately 9% (70,000) have been subsequently

The Hacker News

Cloud Ransomware Flexes Fresh Scripts Against Web Apps

darkreading

1 year 7 months ago

Cloud service providers are getting better at protecting data, pushing adversaries to develop new cloud ransomware scripts to target PHP applications, a new report says.

Becky Bracken, Senior Editor, Dark Reading

Who’s Afraid of a Toxic Cloud Trilogy?

Security Boulevard

1 year 7 months ago

The Tenable Cloud Risk Report 2024 reveals that nearly four in 10 organizations have workloads that are publicly exposed, contain a critical vulnerability and have excessive permissions. Here’s what to watch for in your organization.

In a “GPS mapping” of today’s most pressing cloud security issues, the Tenable Cloud Risk Report 2024 from Tenable Cloud Research revealed serious flaws across workloads, identities, containers, storage and Kubernetes.;

Particularly concerning was the discovery that nearly four in 10 organizations (38%) have an elevated level of exposure from workloads bearing an especially risky blend of security gaps. We called this blend a “toxic cloud trilogy,” defined as any cloud workload having these three risk factors:

A critical vulnerability
Excessive permissions
Public exposure

Like the big bad wolf in the Little Red Riding Hood fable, a toxic cloud trilogy masks its existence and severity in the cloud environment. The masking makes these high risks hard to spot, prioritize and remediate. In this blog we discuss the implications of the toxic cloud trilogy and offer guidance for actions to avoid them.

Why we conducted this research

To help our customers — and ourselves — better understand the most prevalent risks in cloud environments, the Tenable Cloud Research team analyzed telemetry from millions of cloud resources in active production across multiple public cloud repositories. Conducted in the first half of 2024, the research included cloud workload and configuration information. To determine the most exploitable vulnerabilities the team applied Tenable’s Vulnerability Priority Rating (VPR) to common cloud CVEs.

Why a toxic cloud trilogy increases risk

A toxic cloud trilogy increases risk by making the workload’s weaknesses easier for attackers to exploit — and making the scope of exploitation potentially greater.

Cloud security involves layers of defense to prevent breaches if a given layer fails; a toxic trilogy effectively erodes these layers. Bad actors seek out critical vulnerabilities or publicly accessible assets. Finding one, they can commandeer highly privileged permissions or roles to burrow their way in, accessing — and even exfiltrating — sensitive data. For example, an attacker can modify access policies or elevate privileges, moving laterally and deploying resources to gain access to even more sensitive areas.

Prevalence of toxic cloud trilogies in organizations worldwide Source: Tenable Cloud Risk Report 2024, October 2024

The work of mitigating toxic cloud trilogies needs to be high on a security team’s “to do” list. That’s easier said than done. Let’s explore the challenges organizations face in addressing such exposures.

Organizational causes of toxic cloud trilogies

How are such risky combinations getting through? Fault lines can be organizational, due to siloed tooling that limits visibility. Another contributing factor is the distributed ownership of systems, spanning development, IT and cybersecurity teams, among others. Each of these teams may have a different level of risk appetite.

Here are three examples of how these factors contribute to the creation of toxic cloud trilogies:

Didn’t see it. Siloed tooling looks for specific kinds of flaws. They can create false positives that don’t show the full context of an identified exposure, such as a vulnerability not being in runtime so not exploitable.
Will the cloud risk owner please stand up? Depending on the organization — its size and organizational structure — many roles may play a part in managing cloud risk. You’d need to have a holistic view to catch a toxic trilogy.
Risk hungry? The National Institute of Standards and Technology (NIST) defines cyber risk appetite as “The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value.” While an organization may have its strategic risk appetite clearly spelled out, different teams with conflicting business goals may make compromises in implementation that clear the way for toxic cloud trilogies.

Why toxic cloud trilogy factors persist in organizations

Let’s take a closer look at each factor implicated in a toxic cloud trilogy and why these issues can be so difficult for organizations to address.

Critical vulnerabilities

Attackers abuse cloud vulnerabilities — flaws in cloud-based software — to gain unauthorized access, steal sensitive data and/or disrupt services. You would expect published CVEs to be easy, low-hanging fruit for cybersecurity teams to act on quickly. Doing so prevents or dismantles a toxic cloud trilogy. Yet, to our surprise, many high risk vulnerabilities in the data we examined remained unremediated even a month after a CVE was published.

High risk vulnerabilities remained largely unremediated after 30 days.

Why does remediating a vulnerability take so much time? One reason may be that, regardless of who technically “owns” vulnerability management in the organization, it requires the involvement of several teams. Depending on the organization’s structure, those involved in the process of remediating vulnerabilities could include security teams alerting vulnerability management teams, applications teams issuing software update requests of operating systems teams and DevSecOps teams needing to make related changes in CI/CD pipelines.

Another “drag” factor in resolving vulnerabilities may be tactical: teams see vulnerability remediation as time-consuming, requiring an arbitrary cycle of tasks. Adopting conventional wisdom, they may try to save cycles by taking a “batch the patch” approach: delaying the fix until every relevant patch is available. While this approach is understandable from a time management perspective, it places operational efficiency above security.

Excessive permissions

Attackers target credentials, putting identity and access management (IAM) on the radar of everyone responsible for securing the cloud. Overprivileged human identities are a known, high-impact risk factor in identity-based attacks. Overprivileged non-human identities are the key impact factor in breaches based on application vulnerabilities. All are part of the same IAM system.

87% of human identities in AWS have critical or high excessive permissions

Our research revealed extensive instances of excessive permissions in both human and non-human identities. We also found that human identities are granted significantly more risky excessive permissions than non human identities. For example, in the Amazon Web Services (AWS) permissions we studied, the vast majority had excessive critical and high risk permissions.

Human and non-human identity permissions in AWS Source: Tenable Cloud Risk Report 2024, October 2024

Avoiding risky permissions is a cloud security best practice, and also, in many cases, a compliance requirement, achieved by acting on least privilege implementation.

At the helm of permissions and access management are the IAM teams. Aided by no shortage of cloud providers and third-party tools — including AWS IAM, Microsoft Azure Active Directory, Google Cloud Platform (GCP) IAM; AWS IAM Access Analyzer, Azure Privileged Identity Management (PIM), Okta and Auth0 — they work to create and maintain access permissions structures and policies, and apply least privilege to the extent possible.

Security teams, on the other hand, are at another helm, and using other tools, to spot exposures. They are looking not only at permissions but also workloads, data, applications and infrastructure as a whole. This broader approach informs security teams about permissions-related risks as well as granular policy refinements that enforce least privilege, including when elevated permissions should be granted but limited by time.

By design, IAM tools lack full stack and even multi-cloud entitlements context; they may recommend least privilege yet from a narrow permissions and policy lens. They are unable to bring into focus access risk that feeds into a vulnerability or resource to create a toxic cloud trilogy.

IT and security leaders need to enable their IAM and security teams to work closely with each other. Do they?

And why are human identities more likely to be assigned excessive privileges? In some cases, project managers prevail upon their IT colleagues to elevate privileges for an urgent business need. Note, too, that developers may be using programmatic, IAM role-based templates to define access for non-human identities.

Public exposure

The phrase “public exposure” conjures up an actor performing before an audience. In cloud infrastructure, public assets — databases, websites, email servers and other online services — are just that: exposed to external networks so legitimate parties outside the organization can access them.

Risk increases when assets are unintentionally public with either excessive permissions and/or a vulnerability. Worse is when the asset contains sensitive data. Organizations need to be able examine whether an asset is configured as public. In the case of publicly exposed cloud storage, they need to be able to discover and classify sensitive data contained within, including who can access it and how it is used, so any remediation measures can be prioritized accordingly.

29% of organizations have public-facing storage buckets

Our research found that 96% of organizations have public-facing cloud assets; 29% of organizations have public-facing storage buckets. It is essential to know if this exposure is due to a misconfiguration, such as an unpatched resource or overprivileged access. If oversight is at play, it may be due to business drivers such as time to market or lack of cloud security personnel, or the need to implement guardrails, policies or visibility. Context and tools are needed to be able to monitor and close such exposure, and downgrade permissions to the minimal needed.

Key actions to prevent toxic cloud trilogies

Taking a few key actions can prevent toxic cloud trilogies in your cloud environment. Here’s what we recommend:

Treat your cloud infrastructure security as a whole. Attackers have figured out that multi-cloud integrations offer fertile ground. Put your multiple cloud environments under one security roof, unifying workload monitoring, entitlements management and security posture, for comprehensive visibility. Include contextual analysis to reveal which cloud assets hold sensitive data and who can access them.
Don’t wait, remediate CVEs. Make it your organization’s security culture to quickly address severe vulnerabilities. Context matters when prioritizing vulnerabilities for remediation. The ability to quickly analyze which systems contain a vulnerability, which users interact with that system, what data is stored there and whether or not it’s publicly accessible will enable you to prioritize those vulnerabilities which represent the greatest risk to your organization. You’ll be able to give prescriptive guidance to the other teams involved in your vulnerability remediation process.
Don’t underestimate permissions risk. Analyze all identities dynamically, enabling teams to identify access risk and confidently resolve the excessive permissions that lead to toxic cloud trilogies. Apply least privilege principles, including through time-saving just-in-time access controls that make developers willing security partners.
Be aware of public-facing assets and configurations. External exposure is a double-edged sword — necessary for doing business and a potential source of exposure. Rein in and monitor assets configured as public.

Summary

Our research showed that unwittingly or not, many organizations have unnecessary exposures in their cloud environments. Since we can’t know what a malicious actor will do next, control what you can. Add context to unmask and prioritize security gaps like the cloud toxic trilogy, and close such exposures swiftly.

Learn more

Read the Tenable Cloud Risk Report 2024
View the on-demand webinar Empower Your 2025 Cloud Security Planning with Tenable's Data Insights
Read the Tenable Cloud Risk Report Sounds the Alarm on Toxic Cloud Exposures Threatening Global Organizations

The post Who’s Afraid of a Toxic Cloud Trilogy? appeared first on Security Boulevard.

Shai Morag

Who’s Afraid of a Toxic Cloud Trilogy?

Tenable Blog

1 year 7 months ago

A critical vulnerability
Excessive permissions
Public exposure

Why we conducted this research

Why a toxic cloud trilogy increases risk

A toxic cloud trilogy increases risk by making the workload’s weaknesses easier for attackers to exploit — and making the scope of exploitation potentially greater.

Prevalence of toxic cloud trilogies in organizations worldwide Source: Tenable Cloud Risk Report 2024, October 2024

Organizational causes of toxic cloud trilogies

Here are three examples of how these factors contribute to the creation of toxic cloud trilogies:

Didn’t see it. Siloed tooling looks for specific kinds of flaws. They can create false positives that don’t show the full context of an identified exposure, such as a vulnerability not being in runtime so not exploitable.
Will the cloud risk owner please stand up? Depending on the organization — its size and organizational structure — many roles may play a part in managing cloud risk. You’d need to have a holistic view to catch a toxic trilogy.
Risk hungry? The National Institute of Standards and Technology (NIST) defines cyber risk appetite as “The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value.” While an organization may have its strategic risk appetite clearly spelled out, different teams with conflicting business goals may make compromises in implementation that clear the way for toxic cloud trilogies.

Why toxic cloud trilogy factors persist in organizations

Let’s take a closer look at each factor implicated in a toxic cloud trilogy and why these issues can be so difficult for organizations to address.

Critical vulnerabilities

High risk vulnerabilities remained largely unremediated after 30 days.

Excessive permissions

87% of human identities in AWS have critical or high excessive permissions

Human and non-human identity permissions in AWS Source: Tenable Cloud Risk Report 2024, October 2024

Avoiding risky permissions is a cloud security best practice, and also, in many cases, a compliance requirement, achieved by acting on least privilege implementation.

IT and security leaders need to enable their IAM and security teams to work closely with each other. Do they?

Public exposure

29% of organizations have public-facing storage buckets

Key actions to prevent toxic cloud trilogies

Taking a few key actions can prevent toxic cloud trilogies in your cloud environment. Here’s what we recommend:

Treat your cloud infrastructure security as a whole. Attackers have figured out that multi-cloud integrations offer fertile ground. Put your multiple cloud environments under one security roof, unifying workload monitoring, entitlements management and security posture, for comprehensive visibility. Include contextual analysis to reveal which cloud assets hold sensitive data and who can access them.
Don’t wait, remediate CVEs. Make it your organization’s security culture to quickly address severe vulnerabilities. Context matters when prioritizing vulnerabilities for remediation. The ability to quickly analyze which systems contain a vulnerability, which users interact with that system, what data is stored there and whether or not it’s publicly accessible will enable you to prioritize those vulnerabilities which represent the greatest risk to your organization. You’ll be able to give prescriptive guidance to the other teams involved in your vulnerability remediation process.
Don’t underestimate permissions risk. Analyze all identities dynamically, enabling teams to identify access risk and confidently resolve the excessive permissions that lead to toxic cloud trilogies. Apply least privilege principles, including through time-saving just-in-time access controls that make developers willing security partners.
Be aware of public-facing assets and configurations. External exposure is a double-edged sword — necessary for doing business and a potential source of exposure. Rein in and monitor assets configured as public.

Summary

Learn more

Read the Tenable Cloud Risk Report 2024
View the on-demand webinar Empower Your 2025 Cloud Security Planning with Tenable's Data Insights
Read the Tenable Cloud Risk Report Sounds the Alarm on Toxic Cloud Exposures Threatening Global Organizations

Shai Morag

A Threat Actor Has Allegedly Leaked the Data of Ahmedabad Institute of Technology

Dark Web Informer - Cyber Threat Intelligence

1 year 7 months ago

A Threat Actor Has Allegedly Leaked the Data of Ahmedabad Institute of Technology

Dark Web Informer

CVE-2024-38540 | Linux Kernel up to 6.6.32/6.8.11/6.9.2 bnxt_re /include/linux/log2.h out-of-bounds (Nessus ID 209785)

Vuldb Updates

1 year 7 months ago

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.6.32/6.8.11/6.9.2. Affected by this issue is some unknown functionality in the library /include/linux/log2.h of the component bnxt_re. The manipulation leads to out-of-bounds read. This vulnerability is handled as CVE-2024-38540. The attack can only be initiated within the local network. There is no exploit available. It is recommended to upgrade the affected component.

vuldb.com

CVE-2024-44337 | gomarkdown 0.0.0-2024 parser/block.go paragraph denial of service

Vuldb Updates

1 year 7 months ago

A vulnerability classified as problematic was found in gomarkdown markdown 0.0.0-2024. Affected by this vulnerability is the function paragraph of the file parser/block.go. The manipulation leads to denial of service. This vulnerability is known as CVE-2024-44337. The attack can be launched remotely. There is no exploit available. It is recommended to apply a patch to fix this issue.

vuldb.com

Aggregator

Managed ad