Randori Attack Team

Trusted Adversary @RandoriSecurity | Exploit Development | Offensive Operations | #InfoSec tweets only | Managed by @syndrowm @pwnpnw @aaronportnoy

[Randori Attack Team @RandoriAttack]

We've been able to trigger CVE-2023-21554 AKA #QueueJumper, a recently patched RCE in Microsoft’s Message Queueing Service reported by @_CPResearch_. We can confirm it appears exploitable. IOCs and more: https://t.co/NxMiZIAb9P

[chompie @chompie1337]

In collaboration with @FabiusArtrel and @aaronportnoy we conducted a post mortem of the QueueJumper MSMQ RCE patch. We do an in depth RCA, identify variants, create exploit primitives, evaluate exploitability, and make some interesting new discoveries!
https://t.co/2BLq5W1d06

[Randori Attack Team @RandoriAttack]

OpenSSL released details for CVE-2022-3602 & CVE-2022-3786. Due to the mitigating factors outlined in our post we do not believe these will be exploited for remote code execution in real-world scenarios: https://t.co/NMoD0D3sFW

[Randori Attack Team @RandoriAttack]

We have validated Rapid7’s analysis on CVE-2022-26134, an RCE in Atlassian Confluence. Randori recommends assuming compromise and investigating accordingly. Vendor guidance is available here: https://t.co/FpLOpRTUxh

[Jacob Baines @Junior_Baines]

Our technical analysis and curl based PoC for Confluence CVE-2022-26134 can be found here: https://t.co/LUc4286Cj4

[Randori Attack Team @RandoriAttack]

The Randori Attack Team developed a working exploit for #f5 BIG-IP CVE-2022-1388. To help the #infosec community assess their risk, we published our technical analysis and a bash one-liner that organizations can run to test exploitability. Details here: https://t.co/4ovFJhUvuz

[Randori Attack Team @RandoriAttack]

CVE-2022-22965 has been assigned to the #SpringShell vulnerability. Spring framework 5.3.18 and 5.2.20 have been released to address the issue: https://t.co/bKIGDfFdp4

[Randori Attack Team @RandoriAttack]

@springframework Clarification on the above: a 400 code is not the *only* positive indicator of susceptibility--just a definitive one.

[Randori Attack Team @RandoriAttack]

The following non-malicious request can be used to test susceptibility to the @springframework 0day RCE. An HTTP 400 return code indicates vulnerability.

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

#SpringShell #Spring4Shell #infosec

[Randori Attack Team @RandoriAttack]

New high severity DoS in OpenSSL just released: https://t.co/3ZoLlRIlQB CVE-2022-0778 was reported by @taviso and appears to affect systems that parse user-supplied certificates.

[Randori Attack Team @RandoriAttack]

@_mattata Cliff notes below #log4j

[Randori Attack Team @RandoriAttack]

Not able to attend our webinar on #Log4j with @GreyNoiseIO? Click to watch the recording and get expert insights into researching and remediating Log4Shell, with @HexadeciMoose @aaronportnoy @Andrew___Morris, and Remi.
https://t.co/xzQb9EymX9

[Randori Attack Team @RandoriAttack]

Thanks to @mubix doing great work dispelling myths and misinformation around #log4j
https://t.co/fvtv200zAL

[Rob Fuller @mubix]

10 #Log4Shell Facts vs Fiction: a 🧵
1. 1.x is NOT vuln to this RCE. While it doesn't have another RCE, it requires access to send serialized data to a listener ON the log server. This is much MUCH harder to exploit and kind of rare for a Log4j server to be running.

[Randori Attack Team @RandoriAttack]

Heads up, expect to see a growing diversity of payloads as this evolves. Patching & Default-Deny still your best strategies.

[Greg Linares (Laughing Mantis) @Laughing_Mantis]

#log4J info stealing method:

Just saw an info stealer payload that uses System.getenv(); to grab ALL variables and then send them back to the attacker.

That's all it does.

This means attackers do not have to know what env variables to guess in order to steal them.

[Randori Attack Team @RandoriAttack]

FYI: Join @Andrew___Morris @aaronportnoy @HexadeciMoose and @_mattata at 3pm EST for a live #log4j discussion hosted by @RandoriSecurity and @GreynoiseIO https://t.co/tsS2Cd2Jtf

[Randori Attack Team @RandoriAttack]

@GlennPegden We gained remote code execution on the Jamf Pro system, not just a callback.

[Randori Attack Team @RandoriAttack]

The Randori Attack Team can confirm the exploitability of unpatched Jamf Pro on-prem via "Log4Shell". Due to the severity of impact, we recommend organizations patch immediately. See: https://t.co/GXE717yPFr

[Randori Attack Team @RandoriAttack]

If impacted: 1. assume compromise and review logs for signs of malicious activity. 2. Configure firewalls to prevent outbound connections. 3. Look for updates from VMware on release of patches. 4. Read updated Log4Shell blog and follow @RandoriAttack for updates. 3/3

[Randori Attack Team @RandoriAttack]

The Randori Attack Team can confirm exploitability of VMWare products in live environments (VMSA-2021-0028) via Log4j (CVE-2021-44228) aka "Log4Shell". This is a critical vulnerability. Follow @RandoriAttack for updates: https://t.co/3V12TcuK27 1/3

[Randori Attack Team @RandoriAttack]

We have validated exploitability with a working exploit, and anticipate widespread exploitation by threat actors imminently. Randori has been in contact with the VMWare team to assist their development of mitigations. 2/3

[Randori Attack Team @RandoriAttack]

We have been monitoring activity and neither Palo Alto Networks nor Randori’s threat intelligence sources have identified attempted exploitation. We hope to give defenders extra time through the end of the year to apply mitigations.

[Randori Attack Team @RandoriAttack]

We have been collaborating with Palo Alto on CVE-2021-3064 and have jointly decided to delay release of technical details as many customers have yet to apply protections due to the COVID-19 pandemic.