Activity Feed

Technical Analysis

This vulnerability exists in the Windows Update Orchestrator service. A scheduling API call, ScheduleWork does not validate the caller’s permissions, but will schedule a task to be run as SYSTEM. It is present on all version of Windows 10 and Windows Server Core.
One protection that exists is that the binary scheduled for launch must be signed by Microsoft. Unfortunately, it appears you can bypass this restriction by passing an unsigned binary into the cmd.exe signed Windows binary as a parameter. The only other difficulty is that an attacker cannot schedule the execution, but the schedule is determined by the service, and will take place at a time when the scheduler believes the computer will be idle.
Mitigations to this might include checking all scheduled jobs for any files not in the system32 directory. The specific registry key for the jobs is located here:

More information and PoC code located here:

  • Attacker Value
    Very Low
  • Exploitability
Technical Analysis

This is reflected (vs. stored) XSS under certain circumstances, so I’m not sure how useful this is outside, say, phishing for creds – critical rating aside. Happy to be shown otherwise.

  • Attacker Value
    Very High
  • Exploitability
Technical Analysis

This appears to be enterprise asset management software, which would be common in, well, enterprise environments. This vulnerability is authenticated, though, so you will need to obtain creds. After that, Java deserialization RCE is typically a well-supported attack.

Technical Analysis

It’s a pretty nasty bug that there is now weaponized POC code, and Is now available in #mimikatz. So we are expecting some impressive attacks very soon. 😎

For this particular vulnerability there are three big things I want to emphasize:

1️⃣ The vuln requires that an attacker already has access to a network. However, once in, this is an attack that can be done very quickly.

2️⃣ MS is holding fast on only patching Window Server 2008 R2 and up. It is not 100% confirmed, but there is a good chance that earlier EOL versions of servers could be affected, that could represent a higher risk to legacy systems and applications

3️⃣ What’s worse is that there is not a full fix available. The patch enables the DCs to protect devices, but a second patch currently slated for Q1 2021 enforces secure Remote Procedure Call (RPC) with Netlogon to fully address this bug.


@VoidSec Ah, that’s exactly what I was wondering! I’m really sorry your client was compromised, and thank you for reporting this as exploited in the wild.


Hi @ccondon-r7 I have one clients that were further compromised using this vulnerability (attackers already had a foothold into his network and used this vulnerability to gain Domain Admin and push a ransomware). As I’m not part of the IR team I’m still waiting for them to gather more details on the attack.


Hey @VoidSec! Thanks for the assessment! I noticed you reported this as being exploited in the wild—I have absolutely no doubt that’s true, but I haven’t seen any confirmed reports of active exploitation (only public exploits being available). Have you seen differently? Wondering if I need to tweak my monitoring source list :)

Technical Analysis

Unauthenticated attacker, able to directly connect to a Domain Controller over NRPC will be able to reset the Domain Controller’s account password to an empty string, thus enabling the attackers to further escalate their privileges to Domain Admin.

The exploit will be successful only if the Domain Controller uses the password stored in Active Directory to validate the login attempt, rather than the one stored locally as, when changing a password in this way, it is only changed in the AD. The targeted system itself will still locally store its original password.
Target computer will then not be able to authenticate to the domain anymore, and it can only be re-synchronized through manual action.
In test lab a successful attack broke the following functionalities when targeting a Domain Controller: DNS functionality and/or communication with replication Domain Controllers.

Checker and Exploit code
Original research and white-paper: Secura – Tom Tervoort

Technical Analysis

BIG-IP platforms with Cavium Nitrox SSL hardware acceleration cards, a virtual server configured with a Client SSL profile, and using Anonymous Diffie-Hellman (ADH) or Ephemeral Diffie-Hellman (DHE) key exchange and Single DH use option not enabled in the options list may be vulnerable to crafted SSL/Transport Layer Security (TLS) handshakes that may result with a pre-master secret (PMS) that starts in a 0 byte and may lead to a recovery of plaintext messages as BIG-IP TLS/SSL ADH/DHE sends different error messages acting as an oracle. Differences in processing time when the PMS starts with 0 byte coupled with very precise timing measurement observation may also expose this vulnerability.

Thats a lot to take in …
A recent research study identified a timing attack against TLS that could be used to recover a shared secret that could then be used to recover plaintext of previously captured data.

In order to be successful outside of a testing environment, an attacker would need to intercept encrypted traffic and then send specially crafted TLS packets to a vulnerable server in the hopes of recovering enough data to decrypt the previously intercepted traffic.


This vulnerability affects BIG-IP systems with virtual servers associated with a Client SSL profile under the following conditions:

  • You are using ADH or DHE key exchange in the Client SSL profile.

    • Note: DHE is enabled by default in the DEFAULT cipher suite. ADH is not available in the DEFAULT cipher suite.
  • You have not enabled the Single Diffie-Hellman use option—or Single DH use option—in the Client SSL profile.

    • Note: The Single DH use option is not enabled by default in the Client SSL profile options list.
  • Your BIG-IP platform has a Cavium Nitrox SSL hardware acceleration card installed. Platforms with this installed include:

    • BIG-IP i11400-DS, i11600-DS, i11800-DS
    • BIG-IP 1600, 3600, 3900, 5000, 6900, 7000, 8900, 10000, 11000, 12000
    • VIPRION 2100, 2150, 2250, 4100, 4200, 4300


F5 have released a set of mitigations that will prevent this attack on vulnerable server until they can be patched.

  • Log in to the Configuration utility.
  • Go to Local Traffic > Profiles > SSL > Client.
  • Select the Client SSL profile.
  • In the Configuration list, select Advanced.
  • In the Options section, in the list, select Options List.
  • In the Options List section, under Available Options, select Single DH use, and then select Enable.
  • The Single DH Use option displays under Enabled Options.
  • In Ciphers, in the text box, enter a cipher string that disables ADH or DHE, such as the following example:
  • In Unclean Shutdown, select Enabled.
  • At the bottom of the page, select Update.
Technical Analysis

This is still a provisional assessment pending more research.

A high severity issue has been discovered in Citrix StoreFront that, if exploited, would allow an attacker who is authenticated on the same Microsoft Active Directory domain as a Citrix StoreFront server to read arbitrary files from that server.

This CVE is for Citrix StoreFront that allows an authenticated user to gain arbitrary file read on to the StoreFront server. This could lead to further compromise depending on the ability to exploit data recovered from the server.

The official statement from Citrix can be found here.

Updates are availaible

  • Citrix StoreFront 1912 CU1 (1912.0.1000) and later versions of Citrix StoreFront 1912 LTSR
  • Citrix StoreFront 3.0 for 7.6 LTSR CU8 Hotfix (3.0.8001) and later versions of StoreFront 3.0 for 7.6 LTSR
  • Citrix StoreFront 3.12 for 7.15 LTSR CU5 Hotfix (3.12.5001) and later versions of StoreFront 3.12 for 7.15 LTSR

The advisory states that attackers must be authenticated in the same Microsoft Active Directory domain as the StoreFront server, if not this vulnerability is not exploitable.
This significantly impacts the ability for an attacker to exploit this vulnerability. An attacker would have to be:

  • An insider threat with technical knowledge
  • An attacker that already has authenticated access to the domain