Aggregator

The rise in DDOS attacks against the gaming industry is accompanied by increasing bot activity

Even within organizations that have achieved a mature security posture, targeted NTLM relay attacks are still incredibly effective after all these years of abuse. Leveraging several of these NTLM relay primitives, specifically ones that require coercing SMB-based authentication, come with additional challenges to overcome while operating over command and control (C2). This technique will the ease abuse of several popular NTLM relay primitives by allowing attackers to control inbound 445/tcp traffic without loading a driver, loading a module into LSASS, or requiring a reboot of the target Windows machine.

Introduction

When conducting a penetration test or red team from a device that can directly route into a target network, there is often a straightforward path to control inbound SMB-based traffic on port 445/tcp. Common scenarios include a Windows laptop plugged directly into ethernet, a deployed Linux virtual machine, VPN accessibility, etc.

In the case of Windows, the `LanmanServer` service can be disabled, followed by a reboot, and the Windows kernel is no longer bound to the target port. In the case of a Linux machine, having escalated privileges on your testing device will allow for binding to the target port.

However, conducting your offensive assessment through a C2 agent includes a few additional hurdles to overcome. A commonly problematic step is gaining is gaining control of inbound SMB-based authentication attempts on port 445/tcp from a compromised Windows host.

If you’re interested in skipping the technical analysis and getting straight to the solution, see the Implementation Summary section.

Existing Solutions WinDivert driver

The WinDivert driver is described as a “a user-mode packet interception library that enables user-mode capturing/modifying/dropping of network packets sent to/from the Windows network stack”. Many popular open-source projects have been created to leverage this driver to redirect inbound SMB-based authentication, such as PortBender, SharpRelay, StreamDivert, DivertTCPconn, hwfwbypass, and more.

Lsarelayx

The lsarelayx by @_EthicalChaos_ is a “system wide NTLM relay tool designed to relay incoming NTLM based authentication to the host it is running on” by leveraging “a fake LSA authentication provider to hook the NTLM and Negotiate packages and facilitate redirecting authentication requests”.

Disabling LanmanServer w/ Reboot

The LanmanServer service can simply be set to a ‘disabled’ start type. When the Windows machine is rebooted, 445/tcp will no longer be bound by the kernel.

OPSEC Considerations

Leveraging a driver for post-exploitation involves several considerations, such as potential for BSOD. This is a risk we cannot afford to take in certain situations. Especially when conducting activities on high-uptime, critical infrastructure. Loading a driver, especially one publicly associated with popular abuse primitives, can also be a single point of failure regarding detection and prevention.

Loading a customer LSA authentication provider can come with similar risks, as it can affect the stability of the LSASS process. You could be one incorrectly handled error away from a forced reboot depending on your code. As a Microsoft-specific limitation of how LSA plugins work, the provider also cannot be unloaded until a reboot occurs (without getting creative).

Disabling the LanmanServer service also requires either forcing, or waiting for, a reboot of the target machine. This often isn’t an option due to time constraints or high-uptime needs of a production environment.

Ideally, we would be able to control traffic inbound on the target port without loading a driver, loading a module into LSASS, or rebooting the target machine.

Technical Analysis Prerequisite Notes

As previously mentioned, configuring the `LanmanServer` service to a start type of `disabled` and rebooting Windows will result in the machine no longer being bound to 445/tcp by default. Another important note — when reconfiguring the `LanmanServer` service back to the default start type of `auto start` and manually starting the service, the Windows machine will again bind to 445/tcp and reloading all the necessary resources to resume normal SMB-based functionality. Remember, the goal here is to do something to release this port without requiring a reboot, loading a driver, or loading a module into LSASS. Being able to repeat and debug the same thing in reverse (i.e., binding to the port) will be helpful for understanding the potential associated code path(s) for our desired result.

Initial Items of Interest

To start, let’s verify what is binding to the port we are interested in. Here’s one way to do this quickly, using PowerShell:

PS C:\> Get-NetTCPConnection -LocalPort 445 | ForEach-Object { Get-Process -Id $_.OwningProcess }
Handles NPM(K) PM(K) WS(K) CPU(s) Id SI ProcessName
- - - - - - - - - - - - - - - - - - - - - - - -
6600 0 224 7424 9,175.72 4 0 System

So we know the process with a handle to the socket bound on 445/tcp is `System`, and we can begin looking at loaded modules/drivers associated with opening and closing sockets. Using System Informer to obtain a list of loaded modules is a good starting point for this enumeration. After reading through driver names, descriptions, and definitely not using ChatGPT, the initial list for inspection was narrowed down to:

• afd.sys — Ancillary Function Driver for WinSock
• tcpip.sys — TCP/IP Driver
• netbt.sys — MBT Transport driver

Understanding the Binding Process

NOTE: Winbindex was used to ensure the same binaries were being analyzed on the remote machine during dynamic analysis and locally during static analysis.

The next objective was to identify function(s) within these drivers used to bind to the SMB-related port. IDA Free was used to conduct initial inspection for potentially related functions, and thanks to Microsoft symbols, several were found. Searching function names for related keywords such as “port”, “socket”, and “bind”, some of the functions initially identified included:

• afd!WskProAPIBind
• afd!Bind
• afd!WskProAPISocket
• tcpip!InspectBindEndpoint
• tcpip!InetAcquirePort
• (many… many more)

The target Windows VM was configured to enable kernel debugging. To make the action of binding to 445/tcp a repeatable behavior, the VM was also configured with the `LanmanServer` service to a start type of `disabled` and rebooted (mentioned in Prerequisite Notes). Once the machine was no longer listening on the port in question, the VM was snapshotted for easily repeatable behavior. This was coupled with a simple PowerShell one-liner (below) to quickly iterate over the action of rebinding to 445/tcp while using WinDbg.

Set-Service -Name "lanmanserver" -StartupType Automatic; Start-Service -Name "lanmanserver"

Breakpoints were set on many of these interesting functions, which eventually led to the inspection of `tcpip!InetAcquirePort`. A breakpoint set for this function was reliably hit when `LanmanServer` was restarted (i.e., when the port was being bound). To ensure this activity was associated with the binding of port 445, I wanted to see the port number passed in function call parameters. Early in the logic of the `tcpip!InetAcquirePort` function, there was a call to another function, `tcpip!IsPortInExclusion`.

ExAcquireResourceExclusiveLite(a1, v16);
v68 = (unsigned __int16)__ROR2__(*a6, 8);
v69 = IsPortInExclusion(*(_QWORD *)(a1 + 136), v68);
if ( v69 && (*(_BYTE *)(v69 + 16) & 0x12) == 2 )

As seen above, the ‘tcpip!IsPortInExclusion’ function took two parameters. The second parameter was an `unsigned __int16`, which could likely represent a port number between 0–65535. Using the standard fastcall calling convention, this parameter should appear in the RDX register. Stepping through execution of `tcpip!InetAcquirePort` until `tcpip!IsPortInExclusion` was called and obtaining the RDX register value looked like this:

1: kd> p
tcpip!InetAcquirePort+0xbae:
fffff806`3e93c646 e8f9bd0100 call tcpip!IsPortInExclusion (fffff806`3e958444)

1: kd> ? rdx
Evaluate expression: 445 = 00000000`000001bd

So we know this function call is associated with the binding of port 445 when starting the `LanmanServer` service. What information can we gather from the call stack (below) and how we got to this function call? Where can we start in terms of attempting to unbind this port while considering our given prerequisites?

[0x0] tcpip!InetAcquirePort+0xbae
[0x1] tcpip!TcpBindEndpointRequestInspectComplete+0x2cc
[0x2] tcpip!TcpIoControlEndpoint+0x2e9
[0x3] tcpip!TcpTlEndpointIoControlEndpointCalloutRoutine+0x74
[0x4] nt!KeExpandKernelStackAndCalloutInternal+0x78
[0x5] nt!KeExpandKernelStackAndCalloutEx+0x1d
[0x6] tcpip!TcpTlEndpointIoControlEndpoint+0x6e
[0x7] afd!WskProIRPBind+0x11e
[0x8] afd!AfdWskDispatchInternalDeviceControl+0x3c
[0x9] nt!IofCallDriver+0x55
[0xa] afd!WskProAPIBind+0x47
[0xb] srvnet!SrvNetWskOpenListenSocket+0x3ef
[0xc] srvnet!SrvNetAllocateEndpointCommon+0x34a
[0xd] srvnet!SrvNetAllocateEndpoint+0x3e02
[0xe] srvnet!SrvNetAddServedName+0x564
[0xf] srvnet!SvcXportAdd+0x14e
[0x10] srvnet!SrvAdminProcessFsctlFsp+0xbe
[0x11] nt!IopProcessWorkItem+0x93
[0x12] nt!ExpWorkerThread+0x105
[0x13] nt!PspSystemThreadStartup+0x55
[0x14] nt!KiStartSystemThread+0x28 So What About Unbinding?

We have several places we can continue on from this point. My first thought was to identify functionality exposed by these drivers, through device I/O control codes (IOCTLs) for example. Something more straightforward was identified first, though.

Starting with the `srvnet.sys` driver, I attempted to identify similar functions to what was previously identified when debugging 445/tcp being bound. Referencing our call stack from before, we see the `srvnet!SrvNetWskOpenListenSocket` function. Stepping back through the cross-references, we see another function call that is comparable to the functions used to bind to the target port. In this case we see `srvnet!SrvNetCloseEndpoint` calling `srvnet!SrvNetWskCloseListenSocket`, similarly to `srvnet!SrvNetAllocateEndpoint` calling `srvnet!SrvNetWskOpenListenSocket` previously observed.

Checking the cross-references for `srvnet!SrvNetAllocateEndpoint` yields several more results. After manual triage, it was identified that one of those several cross-references (`srvnet!SrvNetCleanupDeviceExtensionPreScavengerTermination`) was called by `srvnet!DriverUnload`.

This is the part where I thought to myself… “no way it’ll be this easy”. If we can use the Service Control Manager (SCM) to stop the service associated with the srvnet.sys driver, would the target code path leading to the release of port 445 be reached?

Service Dependents and Configuration

The `LanmanServer` service is configured with a start type of `auto start` by default. We will first configure this to `disabled` to prevent it from restarting, for testing purposes.

Stopping the `srvnet` service, responsible for loading the `srvnet.sys` driver should make use of the Service Control Manager (SCM) to ultimately call `srvnet!DriverUnload`. However, using System Informer we can quickly determine that `srvnet` has two dependent services:

• srv2
• LanmanServer

So both of these services must first be stopped before attempting to stop the target service. The `srv2` service also has a dependency of `LanmanServer`. Stopping these services in the following order (based on the previously mentioned dependencies) should allow for all three of the services in question to be stopped:

1. LanmanServer
2. srv2
3. srvnet

We now see the first major indicator that our assumption might be correct. The port 445/tcp is no longer locally bound.

PS C:\Windows\system32> Get-NetTCPConnection -LocalPort 445
Get-NetTCPConnection : No MSFT_NetTCPConnection objects found with property 'LocalPort' equal to '445'. Verify the
value of the property and retry.
At line:1 char:1
+ Get-NetTCPConnection -LocalPort 445
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (445:UInt16) [Get-NetTCPConnection], CimJobException
+ FullyQualifiedErrorId : CmdletizationQuery_NotFound_LocalPort,Get-NetTCPConnection

To further validate our assumptions, we can return to the kernel debugger. When we were previously getting a better understanding of the binding process, we set a breakpoint on `tcpip!InetAcquirePort`. Similarly, there is a function in the same driver that will likely reveal what we are looking for when unbinding, `tcpip!InetReleasePort`. We can reconfigure the services to their original state (or just revert the VM) and set the appropriate breakpoint using WinDbg.

Upon repeating reconfiguring and disabling of target services, the breakpoint is hit:

0: kd> g
Breakpoint 2 hit
tcpip!InetReleasePort:
fffff807`7d92a3fc 4c8bdc mov r11,rsp
1: kd> r
rax=ffffcf8d773ed190 rbx=ffffcf8d7a1eacb0 rcx=ffffcf8d77475000
rdx=000000000000bd01 rsi=ffffcf8d7a782770 rdi=0000000000000000
rip=fffff8077d92a3fc rsp=fffffe8bfb1ea0b8 rbp=fffffe8bfb1ea3a0
r8=ffffcf8d7a1ead28 r9=0000000000000000 r10=fffff80779cd2250
r11=fffffe8bfb1ea178 r12=0000000000000001 r13=0000000000000000
r14=ffffcf8d7a80ad98 r15=fffff807901ee040

We don’t immediately see “445” as an argument passed to the function, so to make sure this is our activity that cause the breakpoint let’s take a quick look at the function’s pseudocode in IDA free.

__int64 __fastcall InetReleasePort(__int64 a1, __int64 a2, __int64 a3, __int64 a4)
{
unsigned __int16 v4; // r14
…
__int128 v21; // [rsp+20h] [rbp-48h] BYREF
__int64 v22; // [rsp+30h] [rbp-38h]
v4 = __ROR2__(a2, 8);
v21 = 0i64;
…
v13 = IsPortInExclusion(*(__int64 **)(a1 + 136), v4);
if ( (unsigned __int8)IsEmptyAssignment(v12, v13) )
…

The variable of `v4` is declared as an `__int16`, which helped us previously identify the port being used in the `tcpip!InetAcquirePort` call during the binding process. This variable is used shortly thereafter when calling the `tcpip!IsPortInExclusion` function, where it should appear in the `rdx` register (as the second parameter for that function). We set another breakpoint for `tcpip!IsPortInExclusion`, hit the additional breakpoint, and see that port 445 is the target of this activity.

0: kd> g
Breakpoint 1 hit
tcpip!IsPortInExclusion:
fffff807`7d918444 6690 nop
0: kd> ? rdx
Evaluate expression: 445 = 00000000`000001bd

Now we have our validation that the following behavior, from simply interacting with the Service Control Manager (SCM), is achieved:

Implementation Summary

I’ve published two tools (Python and BOF format) to automate abuse of this technique, and the code can be found on Github. They both include simple commands of “check”, “stop”, and “start” to automate the Service Control Manager interactions discussed in the previous section.

Operational Usage Notes

You don’t need to use my PoCs, as you can just use your favorite tool to manage services remotely or locally. Below I’ve included some example commands of using ‘sc.exe’ proxied into a network from remote Windows machine, as well as ‘wmiexec-Pro’:

sc.exe

• sc config LanmanServer start= disabled
• sc stop LanmanServer
• sc stop srv2
• sc stop srvnet

wmiexec-Pro

• wmiexec-pro.py lab.local/[email protected] service -action disable -service-name “LanmanServer”
• wmiexec-pro.py lab.local/[email protected] service -action stop -service-name “LanmanServer”
• wmiexec-pro.py lab.local/[email protected] service -action stop -service-name “srv2”
• wmiexec-pro.py lab.local/[email protected] service -action disable -service-name “srvnet”

NOTE: Disabling these services effectively hinders the target machine’s ability to facilitate named pipe / SMB communication. This is important to know for two reasons:

1. If the target machine is a server that is, let’s say, a large file share server, it will no longer be able to serve its function.

2. If you disable these services on a remote machine, and the tools you’re using rely on RPC over named pipes (ncacn_np) for Service Control Manager interactions, you will not be able to re-enable them remotely. The examples I’ve given above, as well as my PoCs, make use of RPC over TCP (ncacn_ip_tcp), which should not be affected.

A big perk of this technique is that re-enabling SMB functionality to its default state is a straightforward task and takes effect immediately. You can just set the LanmanServer service to a start-type of “auto-start” again, and a service trigger will soon reenable the service itself which will reload all the necessary drivers and resources to resume normal functionality. If you don’t want to wait, you can just manually start the LanmanServer service again.

Demo

https://medium.com/media/3bf3f58ae1a7ba15ba1b1d38d95b6d4e/href

Conclusion

My hope is that this technique provides a “lower-touch” alternative to existing solutions for taking control of port 445/tcp on compromised Windows hosts while operating over C2. My code to automate this can be found on GitHub and if you’re using other tools, be sure to determine if they use ‘ncacn_np’ vs ‘ncacn_ip_tcp’ to avoid issues with re-enabling remotely.

Relay Your Heart Away: An OPSEC-Conscious Approach to 445 Takeover was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post Relay Your Heart Away: An OPSEC-Conscious Approach to 445 Takeover appeared first on Security Boulevard.

Ученые не могут определить, станет ли π целым числом при многократном возведении в степень.

今日暂未更新资讯~
更多最新文章，请访问SecWiki

Windows privileges, the permissions assigned to users and processes, are essential for maintaining system security and functionality. They determine what actions an account can perform, such as accessing files, running programs, or modifying system s...

美国达美航空 CEO Ed Bastian 表示，CrowdStrike 事故导致了数千名旅客滞留，给它造成了 5 亿美元损失。Bastian 表示，该数字不仅仅代表收入方面的损失，还包括了五天内每天数千万美元的补偿和酒店费用。CrowdStrike 事故迫使该公司手动重置了 4 万台服务器，它正寻求 CrowdStrike 和微软赔偿其损失。与此同时，CrowdStrike 的股东周二对该公司提起了诉讼，认为 CrowdStrike 对其技术的保证有着严重的虚假或误导性。CrowdStrike 的股价在 12 天内下跌了 32%，市值蒸发了 250 亿美元。

UK authorities shut down a scam platform responsible for over 1.3 million calls to 500,000 victims, resulting in millions of pounds in losses

A critical security vulnerability has been discovered in Bitdefender’s GravityZone Update Server, potentially exposing organizations to server-side request forgery (SSRF) attacks. The flaw, identified as CVE-2024-6980, carries a high severity rating with a CVSS score of 9.2 out of 10, indicating its significant impact on affected systems. The security issue originates from a verbose error-handling […]

The post Bitdefender Vulnerability Let Attackers Trigger SSRF Attacks appeared first on Cyber Security News.

CloudSek said the RansomEXX breach occurred via a misconfigured Jenkins server at Brontoo Technology

Data breaches are on the rise. In the US, last year broke new records in terms of breach volumes. The bad news is that costs are also increasing. The latest IBM study reveals that they surged 10% annually to reach nearly $4.9m on average in 2024. Although there are several mooted causes of this rise, one of the most critical appears to be the growing challenge of shadow data.

The post As Breach Costs Surge, Companies Need a Better Way to Find Shadow Data appeared first on Security Boulevard.

Cloudflare Radar is constantly monitoring the Internet for widespread disruptions. Here we examine several recent noteworthy disruptions detected in the first month of Q3, including traffic anomalies observed in Bangladesh, Syria, Pakistan, and Venezuela.

It may feel like beating a dead horse to say it, but the threat of software supply chain attacks is increasing at an alarming rate. And, in fact, it can’t be said too often.

Two recent reports illustrate this point: The "2024 Verizon Data Breach Investigation Report" (DBIR) found that breaches stemming from third-party software development skyrocketed by 68% from what was reported in Verizon’s 2023 report. And ReversingLabs’ "State of Software Supply Chain Security 2024" report chronicled the dramatic rise in threats from open-source repositories (1300%), as well as a string of high-profile attacks on commercial software — from SolarWinds' Orion update that was released to thousands of firms and federal agencies in 2020 to the exposure of CircleCI users’ software secrets and the hack of VoIP vendor 3CX in 2023. 

As software producers, enterprise buyers, and other key stakeholders prepare their cybersecurity and risk management efforts for 2025, they should be looking for ways to prevent and quickly mitigate any and all software supply chain attacks. But modern enterprise security programs suffer from a sprawl of uncoordinated tools and continually fail at achieving software supply chain security (SSCS). This calls for a new era of SSCS management, one in which universal controls can prioritize the mitigation of these threats.

ReversingLabs is now introducing the Software Assurance Foundational Evaluation (SAFE) report as a part of RL Spectra Assure. This report is much more than the simple list of components that a software bill of materials (SBOM) provides, offering much-needed visibility into the risks and threats in the entire application or software binary, in context.

Here’s how Spectra Assure’s new SAFE Report works — and why the time for SAFE is now.

The post Why SAFE. Why Now. appeared first on Security Boulevard.

巴西提议对全球资产超过 10 亿美元的超级富豪征收 2% 的财富税，认为每年可带来 2500 亿美元，可用于应对气候危机、解决贫困和不平等问题，而且该税只影响极少数人。巴西国家气候变化秘书 Ana Toni 表示，没有国家公开反对该税，但在支持程度上一部分国家大于另一部分国家。缺乏对该税的公开反对并不意味着它能被其它国家接受。有很多政府持怀疑态度，但不愿意公开予以否定，因为它在道义上被认为是正确的。美国财政部长 Janet Yellen 表示，美国不认为需要一项全球性税收，而且如何实施全球税是一大挑战，但她同时承认全球税是可能的，七国集团的财长就曾同意征收最低 15% 的企业税。Yellen 说，财富税必须是全球性的，否则富豪会将财富从一个国家转移到另一个国家。

Security Risk Advisors (SRA) announces the launch of VECTR Enterprise Edition, a premium version of its widely-used VECTR platform for purple teams and adversary management program reporting and benchmarking. VECTR Enterprise is designed to support organizations that want to mature and communicate the success of their purple team exercises with benchmarking and executive reporting features. […]

The post Security Risk Advisors Announces Launch of VECTR Enterprise Edition appeared first on GBHackers on Security | #1 Globally Trusted Cyber Security News Platform.

Security Risk Advisors (SRA) announces the launch of VECTR Enterprise Edition, a premium version of its widely-used VECTR platform for purple teams and adversary management program reporting and benchmarking. VECTR Enterprise is designed to support organizations that want to mature and communicate the success of their purple team exercises with benchmarking and executive reporting features. […]

The post Security Risk Advisors Announces Launch of VECTR Enterprise Edition appeared first on Cyber Security News.

Pharma company Cencora confirmed the theft of personal and health information following the February 2024 data breach. Pharmaceutical giant Cencora confirmed that the threat actors had access to personally identifiable information (PII) and protected health information (PHI) following the February 2024 cyberattack. On February 21, Cencora announced a data breach in a filing with the Securities and […]

To wrap up this blog series we wanted to include one more technique that you can use when exploiting this class of vulnerabilities. This technique, introduced to us by Abdelhamid Naceri, becomes useful when you have an on-boot arbitrary delete primitive that you want to transform into an on-demand delete, so that you can escalate using the C:\Config.msi technique.  We will also share a tool that can make debugging protected processes on Windows easier and end by detailing some difficulties we faced during disclosures with several vendors.

Technique ++

One way you can use an on-boot delete primitive is to abuse the Windows Task Scheduler included in default installations of Windows. The Task Scheduler uses the following two directories to perform tasks:

C:\Windows\System32\Tasks - for standard task management.
C:\Windows\Tasks - for legacy operations aimed at ensuring compatibility with Windows XP.

When removing a task, the Task Scheduler does not validate mount points before it deletes the corresponding .job file from C:\Windows\Tasks. The DACL on C:\Windows\Tasks allows writing by a standard user. To prevent a user from taking advantage of this to convert C:\Windows\Tasks into a junction, Windows places a hidden SA.DAT file in this directory, so that the directory will not be empty. Exploiting this setup, it’s possible to transform a controlled boot-time deletion into an on-demand file deletion by removing the SA.DAT file. After deleting this file, the directory is empty, so it can be converted into a junction. Afterwards, deletion of the .job file can be redirected to C:\Config.Msi::$INDEX_ALLOCATION. Despite the directory being emptied of the .job file, Windows still believes this file is present in the tasks folder when we trigger the deletion of the task in our exploit. This is because task information is stored and managed in the Windows registry under the TaskCache key:

Below is a demonstration of this technique that we used to exploit a vulnerability we found in Papercut NG/MF Windows servers. The specific issue was within the PaperCut Web Print service which performed privileged delete operations in `C:\Windows\TEMP\web-print` when this service was started. This directory is typically used to store temporary files that are queued for printing. In the case of a system crash or other unexpected service shutdown, this directory has the potential to take up significant amounts of disk space. The service's delete-on-startup feature is intended to remove these temporary files that are no longer needed. However, this service never verifies any of the items it attempts to delete. So, by placing junctions inside this directory we can abuse this service to delete the contents of arbitrary directories on startup.

Making life a little easier

A common problem throughout this research project that we ran into occurred when we wanted to know more about a file operation that some application was performing. We’d double-click on the operation in Procmon, navigate to the stack trace tab, and be shown something like this:

Although we could see some of the calls that happened in the kernel, all other calls were unknown. This means we often could not find what binary or module was responsible for the file operations or what function that code was calling. We ran into this problem because the antivirus products we were looking at were running as protected processes. What this means is that these processes cannot be debugged, terminated, or inspected at all from a non-protected process, even if the user requesting to do any of these things is running as NT AUTHORITY\SYSTEM.

One can get around this by setting up a kernel debugging session, but this approach can be quite time-consuming. So instead, we used another technique. Since these protected processes cannot be viewed by a normal process, we simply need to turn our non-protected process into a protected one! This can be done using a tool such as PPLcontrol which uses a vulnerable driver to allow for arbitrary read and write access to kernel memory, which can be used to set arbitrary protection levels for any process. We have conveniently borrowed this functionality to create our own simple tool which will allow us to launch any process as a protected process. When we launch Procmon again as a protected process, we can finally see what all those unknowns are:

This tool also allows for a convenient way to debug a protected process. By launching WinDbg as a protected process, or a debugging server, we are now able to attach and debug protected processes. You can download this tool here. You can learn more and find additional resources about debugging protected processes here. 

Vendor Vertigo - A Few Examples of Difficult Disclosures

ZDI’s goal is always to get bugs patched and disclosed properly. We do our best to work with vendors to meet this goal. We recently published a separate blog that highlighted the ongoing erosion of trust between vendors and researchers that we have seen firsthand through our program. In this section, we will provide more context to illustrate the scope of this problem collected throughout this project.

Intel Corporation

An anonymous external researcher submitted several link following vulnerabilities in Intel's software that we ended up having to disclose without a patch.

We submitted the first case to them on 09/13/2023. The next day they responded to us with the following:

“We are rejecting this issue. After reviewing the information provided in this report, the Intel PSIRT team has determined that this report is out of scope of the Intel® Bug Bounty Program and therefore is not eligible for rewards. Symlinks are an Windows OS feature that are not managed by Intel Software.

For more details about symlink vulnerabilities see https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2019-1074

Best Regards,
Intel PSIRT”

After they sent this, we wrote back that same day with a detailed explanation of why this should be remediated alongside several published examples. It is also worth noting that the ZDI never requests or collects bug bounties from vendors. We didn’t receive a response back. 

Timeline:

09/13/23 – ZDI reported the vulnerability to the vendor.
09/14/23 – The vendor states they are rejecting the case as it is out of the scope of the Intel Bug Bounty Program.
09/14/23 – ZDI provided additional details on why this vulnerability should be remediated and that we intend to publish the case as a zero-day advisory on 09/21/23. -- Mitigation: Given the nature of the vulnerability, the only salient mitigation strategy is to restrict interaction with the application.
09/21/23 - No response from Vendor. ZDI publishes zero-day advisory.

Two weeks later, the second case followed the timeline below:

10/03/23 – ZDI reported the vulnerability to the vendor.
10/04/23 – Vendor acknowledges the report and said they are reviewing the case.
11/27/23 – The vendor states they are rejecting the case because it is a duplicate.
11/28/23 – The vendor sends an additional email that states " Symlinks are an Windows OS feature that are not managed by Intel Software”.
12/05/23 – ZDI again provided additional details on why this vulnerability should be remediated and that we intend to publish the case as a zero-day advisory on 12/12/23.
12/06/23 – The vendor requests when and where ZDI plans to disclose the vulnerability.
12/12/23 – ZDI publishes zero-day advisory.

These two cases with Intel emphasize a serious disconnect and apparent lack of commitment to understanding and addressing critical issues in their software.

PaperCut

If you are not familiar with PaperCut, their software is deployed to manage printing in various sectors including academia, healthcare, and government. Their website strongly emphasizes security, mentioning it several times on their website’s landing page. To their credit, they have been proactive in patching all the vulnerabilities we have reported to them thus far.

However, we have encountered alarming issues with PaperCut's handling of vulnerability disclosures. Despite our efforts to provide comprehensive evidence and detailed explanations during calls and email exchanges, PaperCut has chosen to downplay the severity and number of vulnerabilities in its publications.

As shown in the following screenshot, they have chosen to condense and categorize four vulnerabilities that include various vulnerability types with different impacts into two CVEs. These CVEs were given the same incorrect CVSS score and assigned to our cases based on whether triggering the bug will create or delete files on the system. This short-sighted and negligent approach leaves the public blind to the real impact of the reported vulnerabilities.

It is worth noting that the advisory also mentions that “This vulnerability only applies to PaperCut NG/MF Windows servers with the PaperCut Web Print Server service enabled.” In our testing this service is enabled by default, so we were immediately confused as to why they mentioned this as if it was not enabled by default. When scrolling to the bottom of the page we find that they have included the following mitigation guidance:

In another case from the year prior, the verbiage in the advisory shows they understand that the attacker only requires low privileged code execution to escalate, and yet they still mark the CVSS as PR:H:

The concern is that vendors are minimizing critical issues and not adequately warning users about the associated risks. Unfortunately, vendors are doing this to maintain their image and circumvent legal reporting requirements. This practice undermines the intended purpose of vulnerability reporting while misleading users.

Below are the associated cases that we sent to Papercut that are mentioned in the above advisories:

ZDI-CAN-23859: PaperCut NG Directory Traversal Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-24042: PaperCut NG Link Following Local Denial-of-Service Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H (6.1)

ZDI-CAN-23757: PaperCut NG web-print-hot-folder Link Following Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-20972: PaperCut NG pc-web-print Link Following Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (7.8)

ZDI-CAN-21500: PaperCut NG Uncontrolled Search Path Element Local Privilege Escalation Vulnerability
CVSS 3: AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H (7.0)

Discoveries

As a result of the work shown in this blog series, we have discovered and disclosed the following vulnerabilities that have now been patched:

CVE-2024-3037, PaperCut NG web-print-hot-folder Link Following Local Privilege Escalation Vulnerability
CVE-2024-4454, WithSecure Elements Endpoint Protection Link Following Local Privilege Escalation Vulnerability
CVE-2024-2003, ESET Smart Security Premium Link Following Local Privilege Escalation Vulnerability
CVE-2024-0353, ESET Smart Security Premium ekrn Link Following Local Privilege Escalation Vulnerability
CVE-2024-3037, PaperCut NG pc-web-print Link Following Local Privilege Escalation Vulnerability

The 14 vulnerabilities below are being released as zero-day vulnerabilities because they remain unpatched.

ZDI-CAN-22238: (0day) VIPRE Advanced Security SBAMSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22260: (0day) AVG AntiVirus Free AVGSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22272: (0day) Avast Free Antivirus AvastSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22803: (0day) AVG AntiVirus Free Link Following Denial-of-Service Vulnerability
ZDI-CAN-22806: (0day) Avast Free Antivirus Link Following Denial-of-Service Vulnerability
ZDI-CAN-22942: (0day) AVG AntiVirus Free icarus Arbitrary File Creation Denial of Service Vulnerability
ZDI-CAN-22960: (0day) AVG AntiVirus Free AVGSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-22963: (0day) Avast Free Antivirus AvastSvc Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23005: (0day) F-Secure Total Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23375: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23402: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23413: (0day) Panda Security Dome Link Following Local Privilege Escalation Vulnerability
ZDI-CAN-23428: (0day) Panda Security Dome VPN DLL Hijacking Local Privilege Escalation Vulnerability
ZDI-CAN-23429: (0day) Panda Security Dome VPN Incorrect Permission Assignment Local Privilege Escalation Vulnerability

Conclusion

As mentioned previously, we fear that there may be several other vendors whose products are currently vulnerable, but because their products are paywalled, we were not able to test them. We hope the techniques and cases presented in this blog series have inspired you to explore and identify vulnerabilities that you can submit to the ZDI program. You can find us on Twitter at @Izobashi and @NZubrisky and the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches